Identificatore vs oggetto dominio come parametro del metodo

Question

Identificatore vs oggetto dominio come parametro del metodo

#1 da (6 voti)
#2 da (3 voti)

8

Esistono argomenti oggettivi a favore o contro l'uso di oggetti rispetto all'ID univoco come parametri metodo / funzione? (e membri di altri oggetti?). Specialmente nel contesto delle lingue tipizzate staticamente (C # / Java / Scala)

Pro dell'oggetto stesso:

Altre chiamate typesafe. Con gli ID c'è il rischio di un errato ordinamento degli argomenti. Questo può essere mitigato mantenendo una classe "mini" per ogni classe che memorizza solo l'ID di quella classe.
Ottieni una volta dalla persistenza, non è necessario riprovare
Con ID, se il tipo di ID cambia, dì int - > a lungo, quindi richiederebbe modifiche su tutta la linea con possibilità di errori .. (courtey: link )

I vantaggi dell'utilizzo dell'ID:

Il più delle volte non c'è bisogno di un oggetto reale, solo uniqueid lo farebbe, quindi avere l'ID risparmia tempo per ottenerlo dalla persistenza.

Una miscela di queste tecniche, per quanto posso vedere, avrebbe solo contro entrambi e nessuno dei due.

Dato che questo è un problema concretamente definito, spero che ci siano risposte obiettive e non- "Penso" o "Mi piace" tipi ...: -).

EDIT: contesto sul suggerimento di un commentatore- L'unica restrizione è una lingua tipizzata in modo statico. L'applicazione è un'applicazione generica, sebbene sia felice di ottenere risposte basate su scenari di utilizzo specifici.

EDIT: un altro contesto. Dì che ho un sistema di gestione dei libri. Il mio modello è:

Book: { id: Int, isbn: String, donatedBy: Member, borrowedBy: Member }
Member: {id: Int, name: String}

Table- wishlist: { isbn: String, memberId: Int}
Table- borrows:  { id: Int, memberId: Int}  

Method: 
isInWishList( book: Book, member: Member ) vs isInWishList( bookId: Int,  memberId: Int)

handleBorrowRequest( memberId: Int, book: Book ){ 
   //the login system doesn't actually get the entire member structure, only the member id. I don't need the full member yet. can run a query to verify that the memberId has less than max allowed books for borrowing. 
}

Perché dovrei mantenere solo id e non il membro completo? Dì quando ricevo informazioni sul libro, raramente ho bisogno di sapere chi ha donato o preso in prestito. Ottenere le informazioni complete per popolare i campi donati e presi in prestito dai campi è eccessivo.

Ovviamente, questi sono solo i miei punti. Sono sicuro che mi mancano le cose, quindi volevo sapere quali sono i punti a favore / contro.

coding-style methods parameters

posta 0fnt 28.05.2015 - 04:52

fonte

2 risposte

3

Per questo tipo di domande, delegato a qualsiasi soluzione comunichi al meglio il mio intento di programmatore e rende più facile il lavoro di "Future Greg".

L'utilizzo dell'oggetto come argomenti rende più semplice ottenere la chiamata al metodo giusto tra 6 mesi e ho dimenticato i dettagli grintosi di questa applicazione. Per costruire sul tuo "è questo libro nell'esempio della wishlist di questa persona", supponiamo che il metodo isInWishList in realtà debba solo confrontare gli ID interi di libri e membri. In realtà, questo metodo richiede solo due pezzi di dati per poterlo fare. Ora facciamo un passo indietro da questo metodo e guardiamo l'intero sistema software. Dubito che sia necessario un ID libro e un ID membro per poter funzionare. Estrarrrai comunque il libro completo e i membri dal database prima ancora di chiamare isInWishList perché è probabile che dovrai fare qualcosa di più che chiamare semplicemente questo metodo. Forse lo fai, ma la maggior parte delle volte dovrai fare di più.

Detto questo, non si realizzerà realisticamente una penalizzazione delle prestazioni recuperando e mappando completamente gli oggetti dal database. In teoria, avrai bisogno di meno chiamate al database, ma in pratica troverai che questo semplicemente non è vero. Se si passano questi ID come parametri nella stringa di query al server, allora sì, basta recuperare la lista dei desideri dal database. Ma questa è una visione molto ristretta della tua intera applicazione. Ci saranno degli scenari quando eseguirai altre operazioni oltre a controllare una lista dei desideri --- per esempio, aggiungendo un libro a una lista dei desideri. Non vuoi aggiungere elementi duplicati.

Scegli la soluzione più semplice per un nuovo programmatore o il tuo Future Self da capire, che consiste nel passare gli oggetti Book e Member in. Solo dopo aver trovato un rendimento effettivo problema dovresti preoccuparti solo di passare gli Id.

Oppure, potremmo ricordare che i linguaggi tipizzati in modo statico come Java offrono l'overloading del metodo, così puoi avere la tua torta e mangiarla anche tu:

public boolean isInWishList(int bookId, int memberId) {
    // ...
}

public boolean isInWishList(Book book, Member member) {
    return isInWishList(book.getId(), member.getId());
}

La vera risposta a questa domanda è scrivere entrambi i metodi, chiamare la versione solo per interi dalla versione strongmente tipizzata e Bob è tuo zio.

risposta data 28.05.2015 - 21:18

fonte

Leggi altre domande sui tag coding-style methods parameters

Comunicazione tra componenti disaccoppiati tramite eventi I tipi di docblock sono ridondanti quando si utilizza una digitazione rigorosa

score 6 · Accepted Answer

A seconda dell'ambiente e del contesto problematico, la necessità di andare nel database può essere mitigata e come risultato (IMO) l'argomento per l'utilizzo di solo ID viene perso.

Ad esempio, Doctrine2 ORM di PHP ha EntityManager::getReference che produce un proxy caricato pigramente su un'entità usando l'id fornito; Non so quanti altri ORM lo facciano, ma corrisponde all'incirca alla nozione di una "mini-classe" che menzioni. Per la maggior parte delle intenzioni, questa è un'entità completamente idratata, quindi puoi passarla e usarla come qualsiasi altra.

L'unico caso in cui non lo è è quando viene fornito un ID non valido, e in tal caso si vorrebbe comunque andare al database per convalidare; inoltre, per ridurre il costo di acquisizione delle entità, la maggior parte delle funzionalità di memorizzazione nella cache dell'ORM (primo e secondo livello) è disponibile in qualche modo.

Una volta che riduciamo il bisogno e il costo di andare al database, siamo rimasti in gran parte con i pro di usare l'entità come parametro:

Digita sicurezza.
Minore conoscenza richiesta dal chiamante. Uno sviluppatore a 6 mesi di distanza non può erroneamente passare nell'identità dell'entità sbagliata.
Riduzione dei costi di refactoring. Se un metodo dovesse cambiare per richiedere 2 informazioni dall'entità, non c'è alcun costo nel cambiare il chiamante per fornirlo, presumendo che il chiamante abbia avuto l'entità completamente idratata per cominciare.
Minor convalida richiesta per metodo. Molti metodi possono presupporre che l'entità che hanno fornito esista nel database (perché proviene dall'ORM), quindi non è più necessario convalidare l'id.
(Potenzialmente) meno chiamate al database. Se stai passando id a 3 metodi, e ognuno deve convalidarlo o recuperare più dati sull'entità, è 3 volte più chiamate al database di 1 metodo di recupero l'entità e 2 che operano su di esso.

Ovviamente, ci sono casi in cui si potrebbe voler passare solo un id: ad esempio quando si attraversa un limite di contesto limitato (nel linguaggio del dominio parlato). Se consideriamo due contesti limitati con differenti nozioni su ciò che costituisce un account (es. Finanza vs relazioni con i clienti), allora non possiamo passare l'account di contesto A al contesto B. Invece, un ID account (nella lingua del dominio) può essere passato attraverso.