Perché l'uso delle congiunzioni nei nomi di metodo è una convenzione di denominazione errata? [chiuso]

Probabilmente lo fanno a causa di conflitti di denominazione. Suppongo che non puoi avere due metodi chiamati getEntity , uno che probabilmente genera un'eccezione e uno che restituisce null . Pertanto, devi nominarli di conseguenza.

Io, per esempio, non amo la pratica di avere molti modi diversi di chiamare lo stesso metodo a meno che non stia eseguendo alcune modifiche che solo quella particolare classe può eseguire.

In altre parole, se getValueOrNull chiama semplicemente getValueOrException , acquisendo l'eccezione e, in tal caso, restituendo null , ciò può essere eseguito dal chiamante. Ingombra la classe con metodi che non apportano alcun contributo utile. Piuttosto preferirei getValue , e so che getta l'eccezione. Meglio ancora, preferirei sapere che tutti i metodi get generano potenzialmente eccezioni, e nessuno di loro restituisce null invece che il comportamento è uniforme in tutto il mio progetto, o inversamente, tutti potenzialmente restituiscono null , e sanno che il chiamante devi lanciare un'eccezione se lo desideri.

Tuttavia, è anche vero che non sei il responsabile. Il mio consiglio è di portarlo su, ma non preoccuparti delle cose meschine. In definitiva, la responsabilità di tali convenzioni di denominazione ricade sulle loro spalle, indipendentemente dal fatto che seguano o meno il tuo consiglio, e poiché sono i loro asini sulla linea, credo sia loro la prerogativa di dire di no, a mio modesto parere.

Anche se l'uso delle congiunzioni spesso indica una violazione dell'SRP, in questo caso sta solo indicando il valore di ritorno del tipo di dati algebrici di un povero che può essere uno dei due valori, o null o un "successo" valore.

Stanno usando un tipo di Notazione ungherese per compensare le debolezze nel sistema dei tipi, in particolare la mancanza di tipi nullable. In altre parole, non è possibile specificare nell'annotazione @return che la funzione non restituirà mai null e, viceversa, non è possibile specificare nell'annotazione @return che la funzione possa restituire null .

Inoltre, credo che le annotazioni @throws non siano obbligatorie in php, quindi l'assenza dell'annotazione non indica l'assenza di un'eccezione, sebbene ciò sia risolto meglio rendendo l'annotazione obbligatoria nella tua guida di stile.

Considerate le limitazioni della lingua che state utilizzando, non è uno stile del tutto irragionevole.

Nel mio codice a volte creo coppie di metodi con nomi come getEntity () e getEntityOrNull (). Il nome rende chiaro il comportamento previsto. Se getEntity () non trova alcuna entità, viene generata un'eccezione. getEntityOrNull () restituirà un valore null.

In questo modo, il codice chiamante diventa un po 'più chiaro. Se il codice chiamante deve avere un'entità allora getEntity farà il trucco. Se l'entità è una sorta di cosa opzionale, allora getEntityOrNull è il metodo di scelta.

La stessa cosa potrebbe essere raggiunta con un singolo metodo, ma ciò sposta il peso del programma chiamante. Hai sempre bisogno di testare un null o hai bisogno di un blocco try / catch. In entrambi i casi è il codice aggiuntivo che deve essere duplicato ogni volta che viene chiamato il metodo.

Se i tuoi architetti non utilizzano questi tipi di coppie di metodi allora sì, metterei in dubbio la necessità del suffisso.

Non ho mai visto un metodo setValueOrException. Non riesco a pensare a un buon caso d'uso comune per questo.

Potresti considerare di chiedere agli architetti perché. Quelli che conosco sono sempre lieti di spiegare le loro decisioni. Spesso in grande (e talvolta atroce) dettaglio.

I tuoi due argomenti sono validi. Ma se sono loro i responsabili della decisione sulla convenzione di denominazione, cerca di non sentirti troppo male perché è qualcosa con cui non sei d'accordo.

Mentre ci sei, dovresti convincerli a non usare le parti "get" e "set" a meno che quei metodi non facciano effettivamente impostare o ottenere direttamente una variabile membro.