Le classi possono violare la Single Responsibility se delegano attività interne?

Question

Le classi possono violare la Single Responsibility se delegano attività interne?

#1 da (1 voti)
#2 da (1 voti)

4

Ho due classi Output e Timeline , nessuna delle quali viola SR, ma le due sono collegate tra loro. Quindi quello che mi piacerebbe fare è avere una classe chiamata Elco (c'è una ragione dietro al nome) che li ha entrambi come sottoclassi. Per vari motivi (questa è solo una versione semplificata) è importante che io non violi il LoD (Law of Demeter). Il problema è che tecnicamente Elco ha ora due responsabilità. Delega queste due responsabilità a due classi, ognuna delle quali ha una sola responsabilità. Non è ok? Perché? Qual è la soluzione migliore?

design programming-practices java design-patterns

posta sinθ 06.08.2013 - 01:18

fonte

2 risposte

Leggi altre domande sui tag design programming-practices java design-patterns

Design di dipendenza multi oggetti di destra Evidenza di design errato: funzionalità di aggiornamento A interrompe / interferisce con la funzione esistente B

score 1 · Answer 1

Tecnicamente parlando, è un po 'difficile dire se stai infrangendo la legge di Demeter o meno senza effettivamente guardare alla tua implementazione.

In base al principio, finché l'oggetto di Elco chiama direttamente i metodi di Output e Timeline e non i metodi di altri oggetti ottenuti da Output e Timeline , tu stanno bene.

Il problema, tuttavia, è che tu sei codifica per un'implementazione e non per l'astrazione es Nel tuo codice avrai condizioni come:

if(someCondition)
   call Timeline methods

else 
   call Output methods

Un approccio migliore a questo problema potrebbe essere quello di definire un'interfaccia implementata sia dalla Timeline che dall'output. In questo modo, la classe Elco deve solo conoscere quell'interfaccia e non le classi di implementazione. Il tuo codice sarà quindi:

methodCaller(CommonInterface f) {

      f.interfaceMethod()

}

Ciascuna classe fornirà quindi le proprie implementazioni al metodo interfaceMethod . Questo disaccoppierà il codice dalla sua implementazione, in modo che in futuro tu possa estendere tutte le implementazioni di CommonInterface come vuoi, senza modificare il codice precedente.

score 1 · Answer 2

Per rispondere alla domanda nel titolo: una classe che si limita a delegare ad altre classi può violare il principio di responsabilità singola, ma non lo fa necessariamente.

Per sapere se la tua classe Elco viola l'SRP, avremmo bisogno di saperne di più sul suo design e sul motivo per cui lo hai creato.
Un dead give-away per aver violato l'SRP (e secondo me, anche LoD) è se hai difficoltà a pensare ai nomi dei metodi Elco che non rivelano che è solo un sottile wrapper forwarding ad un nome simile metodo in Output o Timeline . Tali nomi possono essere accettabili per una piccola percentuale dei metodi, ma dovrebbero sollevare una bandiera rossa se ciò accade per un numero significativo di essi.
D'altra parte, se Elco fornisce un servizio concettualmente di livello superiore che può essere descritto in termini di operazioni su Output e Timeline , allora Elco non viola l'SRP e può essere visto come un'istanza del modello di progettazione della facciata.