Parametro metodo di gruppo o parametro individuale?

Il capitolo 3 del il libro dei codici puliti contiene una sezione sulle funzioni. Indica che il numero ideale di argomenti è Zero, quindi accanto all'ideale c'è Uno. Due se proprio devi. Tre dovrebbero essere evitati e qualsiasi altra cosa dovrebbe richiedere una giustificazione speciale. Questo potrebbe sembrare simile alle risposte fornite da rupjones e Péter Török , tuttavia c'è molto di più che scegliere semplicemente un numero arbitrario di parametri del metodo da affrontare.

Come menziona David Wallace nella sua risposta , la leggibilità e la manutenzione sono le tue considerazioni principali. Ogni parametro che aggiungi ad un metodo aumenta il suo livello di difficoltà relativa in termini di capacità del lettore di capire cosa sta succedendo nel metodo. Quindi, mentre una nuova classe può essere giustificata, il numero di parametri non dovrebbe essere la ragione per cui si definisce. Ogni classe che crei è un nuovo file e entità da mantenere, e sebbene spesso questa sia l'opzione migliore se aiuta a mantenere il tuo codice pulito e facile da riutilizzare e modificare, questo deve essere bilanciato con la complessità del metodo e del suo utilizzo della classe stessa.

Ci sono anche altre considerazioni. Le tue classi dovrebbero essere solo responsabili di una cosa concettuale . Se i parametri del metodo sono solo vagamente correlati, una classe potrebbe non essere giustificata. L'elenco dei parametri potrebbe anche suggerire che potresti aver bisogno di due classi, o un composito o qualche altra combinazione.

Come per le classi, dovresti anche considerare che i tuoi metodi dovrebbero fare solo una cosa. Se hai molti argomenti di metodo, o anche se usi un gran numero di parametri in una classe, forse stai cercando di fare troppe cose individuali all'interno in un unico metodo. Potresti essere in grado di suddividere il tuo metodo in un insieme di metodi più piccoli, e così facendo riduci la confusione dei parametri e riduci la complessità dei tuoi metodi.

Aspettando che la lista dei parametri cresca prima che il refactoring possa spesso significare che hai lasciato un problema da affrontare in seguito. Spesso è meglio rispondere a tali preoccupazioni non appena appaiono, per evitare di dover gestire in futuro refettori potenzialmente difficili. Ovviamente, se hai una buona copertura di test, allora questo non dovrebbe essere troppo difficile, tuttavia questo non dovrebbe significare che dovresti permetterti di diventare troppo compiacente per affrontare potenziali problemi nel tuo codice man mano che diventano noti a te.

Così sicuro, non ci sono regole reali o veloci su questo, ma troverai se mantieni i tuoi metodi piccoli, e poi prova a trovare un modo per renderli più piccoli e senza ripetizioni, che molti di questi problemi fare con il numero di parametri o classi - mentre non meno rilevante - probabilmente apparirà meno spesso.

Non c'è una regola chiara a questo, dipende da molte cose. Una regola empirica è che se il metodo ha più di 3-5 parametri, è consigliabile raggrupparli. Il mio primo approccio in questo caso sarebbe sempre l'utilizzo di oggetti parametro. Vorrei utilizzare una mappa valore-chiave solo come ultima risorsa, quando esiste un numero enorme e / o variabile di parametri i cui tipi non sono noti al momento della compilazione.

Chiediti quale approccio ti darà il codice che è il più leggibile e il più facile da mantenere. Codice di conseguenza.

Il mio tipico approccio a questo, come @ peter-torok, è di raggruppare i parametri se c'è più di 3 (o qualche valore basso) con una classe. Mi piace pensare che se è più di questo, probabilmente c'è un'astrazione importante mancante nel tuo dominio, nel qual caso una classe è giustificata.

Secondo Code Complete, questo dipende dal livello di astrazione concettuale su cui stai programmando. L'imperativo tecnico principale del software è la gestione della complessità, quindi assicurati di non mescolare le astrazioni.

Ad esempio,

public class Vechicle {
    private int id;
    private Door door;
    private Window window;
    private Trunk trunk;

    public void addDoorAndWindow(Door door, Window window) {
      // passing a vechicle object is inappropriate here, 
      // you shouldn't access the parameters with vechicle.getDoor() or vechicle.getWindow()
    } 

    public void collide(Vechicle vechicle) {
      // passing the id is inappropriate is here
      // if you need it, get it with vechicle.getId()
    }
}

Fai la domanda, ha senso passare un metodo Vechicle a e addDoorAndWindow . No, stai aggiungendo door e window e non a vechicle . Ha senso passare un metodo id a collide . No, non stai colmando con id , stai scontrando con vehicle .

Se ottieni troppi parametri individuali e sono correlati, prova a introdurre un Oggetto Parametro.