Suggerimenti per la denominazione dei metodi richiesti [chiuso]

Question

Suggerimenti per la denominazione dei metodi richiesti [chiuso]

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

-3

La mia domanda sarà su come pensi che sarebbe opportuno nominare alcuni metodi in un'interfaccia fluente. Fammi provare a dimostrare il problema.

Considera questo albero delle relazioni:

Unapersonapuòaverecaniegattieuncanepuòaveredelleossa.Piuttostosemplice.

Quellochestocercandodifareècreareun'interfacciafluentespecificaperildominioperdeterminarequalidellerelazionidicuil'utentehabisogno.Èingradodigestirequalsiasiprofonditàdirelazioni.

Hoprogettatol'operazioneinmodosimile(Stacostruendol'alberoassoicaiton,dacuipossodeterminare,cosavuolel'utente):

Come codice (potrebbe essere più leggibile):

personAssoc = person.associate().withCats().and().withDogs().withBones().up().done();

Ma sto cercando di rendere questa parte il più intuitiva possibile, quindi non voglio che i nomi dei metodi a abbiano senso uno dopo l'altro e essere il più vicino possibile alla lingua parlata . Le mie maggiori preoccupazioni sono i seguenti 3 metodi:

and() nella mia lingua preferita and è una parola chiave riservata, quindi non posso usarla. Ho cercato sinonimi ( together() , including() , also() ) ma non sembrano / sembrano giusti ( and significa che aggiungeremo più figli all'associazione genitore).
up() ovviamente sta infrangendo qualsiasi tipo di flusso. Con questo nome di metodo, l'intera faccenda è diventata molto più lontana dalla lingua parlata, di quanto volessi ( up significa, non siamo necessari per aggiungere più relazioni al genitore, ma abbiamo finito con quello attuale . Nel codice è uguale a and ).
done() viene chiamato una sola volta, al termine delle chiamate al metodo, ma non si adatta ancora all'immagine ( done significa che, letteralmente, non aggiungeremo più associazioni ).

Quello che sto cercando sono altri nomi migliori per i precedenti 3, che:

Che rendono l'utilizzo dell'interfaccia fluente più vicino alla lingua parlata.
Per and un nome, che è il più lontano possibile da qualsiasi parola chiave della lingua.

Se leggi tutto questo, sentiti libero di lasciarti sfuggire qualche idea, potrebbe aiutarmi molto! Grazie per qualsiasi suggerimento.

methods naming

posta Balázs Édes 12.04.2014 - 20:30

fonte

3 risposte

2

bene, "con" è un nome scomodo ... "ha" è molto meglio. Has e Is sono termini molto ben stabiliti, così come Get. Dovresti usare questi termini perché rendi più facile la scoperta - le persone hanno familiarità con GetParent per esempio come restituire un oggetto genitore. Questo lo rende un buon termine da usare.

'E' sembra essere "genitore di ritorno", ma nella tua convenzione di denominazione, potrebbe essere meglio descritto come "proprietario", quindi getOwner() o whoseOwner() potrebbero adattarsi meglio.

Allora hai

person.associate().hasCats().whoseOwner().hasDogs().hasBones().whoseOwner().disassociate()

disassociare sembra l'opposto del socio - ma entrambi sono termini artificiali, potrebbe essere preferibile scegliere qualcosa di meno "in armonia" con l'albero e usare un termine che dice "avvia elaborazione" o simile, quindi conosci la sua parte dell'impianto idraulico

risposta data 12.04.2014 - 20:51

fonte

1

il tuo metodo proposto non mi sembra manutenibile

è molto più semplice dare a Person un metodo addCat e addDog che fa proprio questo

Dog dog = new Dog();
dog.addBone();
person.addDog(dog);

in questo modo puoi anche creare il cane con le sue ossa da qualche altra parte senza passare per la fabbrica di ossa.

risposta data 12.04.2014 - 20:49

fonte

Leggi altre domande sui tag methods naming

Perché utilizzare mai l'eccezione throw (in C #) tranne per lo sviluppo della libreria di classi? [duplicare] Motore fisico con posizioni a virgola fissa [chiuso]

score 3 · Accepted Answer

Ci sono due problemi qui: una buona denominazione e l'abuso di interfacce fluenti.

Una buona API ha due lavori: deve essere semplice scrivere codice usando questa API, e la funzione del codice risultante dovrebbe essere ovvia per un lettore. Mentre le interfacce fluenti eccellono nell'ultima questione, le lingue che cercano di essere eccessivamente simili all'inglese falliscono il precedente requisito. Qualsiasi API è una lingua che deve essere appresa, quindi dovrebbe essere il più sorprendente possibile affinché un utente possa apprendere rapidamente.

Pertanto ti suggerisco di utilizzare un'API fluente, ma attenuata per gestire solo un livello di gerarchia alla volta:

Person p = makePerson()
  .with(makeDog().with(makeBone()))
  .with(makeCat())
  .finish();

dove PersonBuilder#with è sovraccarico per gestire argomenti di tipi Dog , DogBuilder , Cat e CatBuilder ecc.

Se devi assolutamente utilizzare un singolo livello, vorrei suggerire end , finish o back anziché and . L'uso di indentazioni appropriate potrebbe anche aiutare a rendere il codice più chiaro:

person.associate()
  .withDog()
     .withBone()
     .end()
  .end()
  .withCat()
  .end()
.end()

Questo non lo rende più simile all'inglese, ma segue regole chiare (qualsiasi with è specchiato da un end ) e sembra familiare a qualsiasi programmatore (e specialmente a chiunque abbia visto Ruby).