Is this true? I know that each method is unique and a special combination of the above is probably require. Generally speaking do most methods follow a pattern?
No, la maggior parte dei metodi non segue lo schema che hai descritto. Sarebbe più esatto dire che ci sono molti modelli diversi, più piccoli, e molti metodi seguono uno o più di questi modelli.
Ad esempio, input sanitization potrebbe essere considerato un pattern, e la maggior parte dei metodi, in effetti, tenterebbe di controllare e alla fine normalizzare i valori dagli argomenti prima di utilizzarli. A meno che non lo facciano, a volte non lo fanno per una buona ragione.
Immagina un metodo che memorizza il nome e il cognome di una persona in un database relazionale. Il metodo deve verificare la lunghezza dei nomi prima di eseguire la query insert SQL?
-
A volte sì. Fare una query che farà necessariamente fallire non è una buona idea, perché sprecherà le risorse del database, sprecherà la larghezza di banda della rete e, nel peggiore dei casi, renderà possibile a un utente malintenzionato di eseguire un attacco DOS sul database stesso.
-
A volte no. Se stai scrivendo una piccola applicazione che utilizza NoSQL per archiviare i dati localmente (sul computer del cliente), potrebbe essere interessante mantenere la regola della lunghezza massima in un unico posto, il database stesso, invece di duplicare la logica.
Considerando lo schema di cui stavi parlando nella tua domanda, molti metodi non lo seguono affatto . Ad esempio, prendi un metodo filter che semplicemente cammina attraverso una sequenza e restituisce solo gli elementi che corrispondono a un predicato. Hai un ciclo, ma nessuna variabile locale, forse nessuna gestione delle eccezioni, e ovviamente nessuna istruzione return alla fine, poiché i risultati erano yield -stornati progressivamente all'interno del ciclo stesso.
Questo significa che il tuo pattern è semplicemente troppo complesso per essere utile. Modelli più semplici, tuttavia, potrebbero funzionare. Alcuni, come la convalida dell'input, non cambiano la natura del metodo. Altri, come "vai a prendere il valore da un campo e restituiscilo così com'è" sono indicativi di un tipo specifico di un metodo - in questo caso, un getter .
Is there a better way of writing out the above list, in a more formal way?
No e non ne hai bisogno.
L'obiettivo di un pattern è essere in grado di scambiare facilmente le tue idee con le tue coppie. Quando utilizzi una fabbrica astratta , non è necessario inizia a disegnare diagrammi complicati agli altri membri della tua squadra: semplicemente dici loro che stai usando una fabbrica astratta (idealmente attraverso i nomi delle tue classi), e sono (si spera) sapendo di cosa stai parlando e cosa significa in termini di organizzazione delle classi e del loro utilizzo.
Ciò funzionerebbe per piccoli "schemi" che ho elencato sopra. Una semplice parola getter dice molto ad un altro sviluppatore su un metodo specifico: se vedo un metodo Java chiamato getPrice , posso indovinare il suo contenuto. Allo stesso modo, dire a qualcuno che devi disinfettare gli input nel tuo metodo è più facile che spiegare che devi avere un sacco di condizioni che controllano i casi limite come la lunghezza delle stringhe, i valori null , il valori numerici fuori dall'intervallo e altre cose sgradevoli prima di poter utilizzare gli argomenti all'interno del metodo.