, molti metodi vs liste di parametri lunghi

Question

Stiamo provando a fare le cose nel modo più chiaro e pulito possibile in una situazione di architettura a 3 livelli.

Ma la complessità del nostro sistema ci lascia confusi sul modo migliore di procedere.

Se utilizziamo molte catene di funzioni che attraversano il livello di servizio, con elenchi di parametri più piccoli, questo sembra chiaro in termini di ciò che viene fatto, tuttavia sembra che molte funzionalità vengano ripetute attraverso questi metodi.

Tuttavia, se utilizziamo meno metodi e disponiamo di ampi elenchi di parametri per modificare la funzionalità all'interno dei metodi, questo sembra sfuggire di mano.

La nostra scelta al momento è avere più funzioni in quanto è più facile da gestire rispetto alle funzioni monolitiche con molti flussi logici al loro interno. Questo ovviamente significa blocchi più piccoli di codice più gestibile.

È solo che abbiamo sentito parlare di ASCIUTTO molto, quindi sembra che ci sia qualche ripetizione nei metodi. Ma sembra più flessibile.

Answer 1

La maggior parte delle persone preferisce firme di metodo più piccole rispetto a quelle di grandi dimensioni. Rende più facile ragionare sui metodi (per non parlare di testarli!), Tuttavia non si dovrebbe usare questo per giustificare le violazioni dei principi ASCIUTTI.

Esistono motivi per cui non è possibile utilizzare firme di metodo di dimensioni ridotte e calcolare il codice replicato comune in metodi di supporto interni?

Answer 2

Presumo che i "molti metodi" facciano la stessa funzione e l'unico che varia sono i parametri.

Il mio apporach sarebbe passare i dati con alcuni oggetti, simili a come i parametri vengono passati a un GridBagLayout in un oggetto GridBagConstraints. Ad esempio, per una query di ricerca passerò un bean "Filter" con tutte le possibili condizioni, il codice nel metodo è lungo ma non complicato ("è specificata la condizione X -> aggiungi il filtro X alla query") e può essere facilmente divisa in alcune funzioni di supporto.

Answer 3

Credo davvero che per le applicazioni aziendali non ci sia niente di meglio di una buona architettura a più livelli, con una buona intenzione che rivela nomi per classi e metodi e alcuni modelli di progettazione applicati all'interno dell'intera soluzione. Seguendo questa regola, è contraddittorio avere metodi lunghi perché probabilmente infrangeranno il Principio di Responsabilità Unica, quindi non esprimeranno con il loro nome ciò che stanno realmente facendo. Se si desidera utilizzare il principio DRY, mantenere i metodi e le classi pulite, brevi e chiare e applicare alcuni modelli di progettazione per riutilizzarli nell'intera soluzione.

Mi raccomando di leggere Domain Driven Desing (Eric Evans) e Clean Code (Robert C. Martin) per vedere di più su questo tipo di "filosofia del codice" in dettaglio.

Answer 4

Questo di solito è un sintomo di applicazioni fortemente accoppiate. Per andare da A a B devi prendere quindici turni e poi tornare indietro.

Un ottimo modo per ridurre l'accoppiamento consiste nell'introdurre eventi di dominio. Per esempio, quando si crea un utente verrà generato un evento di dominio chiamato UserCreated quando viene sottoscritto dalla classe SendWelcomeEmail e NotifyAdminsOfNewUser o SendIntroductionaryOffer

Il punto è che chiunque può agire su un evento che riduce efficacemente la complessità dal momento che don Deve fortemente accoppiare il tuo codice più.

Answer 5

Penso che sia meglio fornire 2 esempi di cosa intendi. Sembra uno dei seguenti:

1. Hai un design scadente.
2. L'interazione/comportamento si diffonde attraverso molti oggetti.
3. Si sta utilizzando DI \ design pattern in modo errato.
4. Il tuo codice è in realtà procedurale e non OO.

Poiché non hai fornito alcun esempio, passerò tra poco per tutte queste opzioni.

1. Hai un design scadente.

3. Si sta utilizzando DI \ motivo di progettazione in modo errato.

Forse dovresti dividere il codice in modo diverso, forse dovresti usare DI o rivisitare come lo stai usando. Forse dovresti applicare alcuni schemi di progettazione per rendere il problema gestibile.

2. Si ha interazione/comportamento in molti oggetti. Considerare l'uso di DCI http://alexsmail.blogspot.com/2012/09/dci.html per risolvere questo problema.

4. Il codice è in realtà procedurale e non OO. Ho visto il codice wriitent in Java dal programmatore che è regolare scrivere codice procedurale. Ha molti parametri che modifica l'esecuzione del metodo. La soluzione sarà riprogettare il codice e (ri) addestrare i programmatori.