Quando una colla o una classe di gestione fa troppo?

Question

Quando una colla o una classe di gestione fa troppo?

#1 da (15 voti)

10

Sono propenso a creare classi centralizzate che gestiscono le altre classi nei miei progetti. Non memorizza tutto da solo, ma la maggior parte delle richieste di dati andrebbero prima al "gestore". Mentre osservavo una risposta a questa domanda ho notato il termine "God Object". Wikipedia lo elenca come antipattern, comprensibilmente.

Dov'è la linea tra una classe di colla legittima, o un modulo, che trasmette dati e messaggi da un posto all'altro e una classe che sta facendo troppo?

anti-patterns design design-patterns

posta jprete 19.03.2011 - 05:42

fonte

1 risposta

Leggi altre domande sui tag anti-patterns design design-patterns

Simbolo diagramma classe UML per una funzione di primo livello Numero di classi in uno spazio dei nomi - Codice olfattivo?

score 15 · Accepted Answer

Molte persone dicono cose come "una classe non dovrebbe mai essere più grande della tua testa".

Tuttavia, ho appena partecipato a una discussione con alcuni grandi programmatori di livello mondiale su questo argomento. Ne ho parlato con uno dei ragazzi dei Naked Objects. Per quanto possiamo dire, a volte, questo accade e non c'è molto modo per aggirarlo.

Normalmente, però, l'unica classe in cui ciò accade è un oggetto dominio che rappresenta l'elemento fondamentale del tuo dominio: un account per il banking, una vendita per il retail, ecc. Se lo trovi accade anche ad altre classi , probabilmente vorresti considerare la responsabilità di quella classe. Ecco i miei consigli:

Se si chiama "Manager", "Helper" o "Service", è probabile che sia troppo grande. Una volta che hai effettivamente capito quale dovrebbe essere la responsabilità di una classe, troverai più facile delegare le altre responsabilità.
Se si chiama "Controller", dovrebbe essere responsabile del controllo dell'interazione tra un gruppo di altre classi ... e nient'altro.
Se passa dati e messaggi tra diversi nodi fisici allora uno dovrebbe occuparsi della conversione di un messaggio specifico in un modulo serializzato, o gestisce il meccanismo di trasferimento. Ad esempio, potresti avere una classe che converte una transazione bancaria in XML e un'altra classe che invia tale XML su HTTP.
Se passa eventi tra diversi moduli in un'applicazione, dovrebbe essere responsabile di comunicare agli ascoltatori quando viene generato un evento e nient'altro.

Come regola generale, se è troppo grande, vedi se è possibile delegare responsabilità a un'altra classe, e se non è possibile, è probabilmente OK.