Come si segue il principio della responsabilità unica nelle classi responsabili del comportamento?

Question

Come si segue il principio della responsabilità unica nelle classi responsabili del comportamento?

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

4

Ho molte classi nella mia applicazione responsabili di viste comportamentali, controller, modelli, rete - spesso lo stato di una classe o di un sistema dipende da un'altra e sto trovando le classi che sono principalmente responsabili del comportamento di un sistema diventano inevitabilmente dipendenti o dipendenti di altri sistemi o classi. Ho provato a passare le interfacce delle dipendenze dal costruttore del sistema fino alla classe, dipende da esso e registrando gli eventi su di esso, ma questo diventa estremamente complesso e folle e viola almeno OCP e SRP.

Sto pensando di creare un sistema di eventi a cui tutte le classi di invio e ascolto degli eventi sarebbero accoppiate, fornendo uno strato di riferimento per le classi che richiedono l'interazione con classi di altri sistemi, tuttavia nel peggiore dei casi le classi comportamentali potrebbero essere responsabili comportamento di una classe, gestione degli eventi e degli eventi di dispacciamento, in modo tale da violare anche l'SRP, anche se sono abbastanza sicuro che seguirebbe l'OCP.

C'è una soluzione migliore là fuori? Sto applicando correttamente questi principi? Sono molto titubante nell'usare un sistema di eventi in quanto richiede che la maggior parte delle classi sia strettamente accoppiata ad esso.

c# single-responsibility

posta fordeka 18.07.2012 - 15:49

fonte

2 risposte

1

Se per 'responsabilità' identifichiamo 'ragione per cambiare' dipende dalla granularità dell'astrazione. Portandolo a un livello ridicolo, si potrebbe considerare che, poiché ogni metodo ha la propria responsabilità, dovrebbe esserci sempre un solo metodo per classe, ma è solo una follia. Penso che tu stia nella giusta direzione con il tuo approccio all'interfaccia, ma invece di iniettare le dipendenze nei costruttori potresti vedere se il modello DI / IoC o il modello Locator del servizio funzionano nello scenario.

risposta data 18.07.2012 - 16:22

fonte

Leggi altre domande sui tag c# single-responsibility

Implementazione del sistema di cache nell'applicazione Web Java [chiusa] Progettazione di un processo ETL basato sul contenuto con .NET e SFDC

score 0 · Accepted Answer

Questa è una domanda difficile a cui rispondere. Un esempio specifico del problema che stai affrontando potrebbe aiutare a fornire una guida migliore. Sembra che tu non stia dividendo correttamente le responsabilità delle tue classi in modo che una data classe non abbia troppe dipendenze. Come regola generale, cerco di evitare che una singola classe abbia più di 3-4 dipendenze. Se hai classi che hanno bisogno di una mezza dozzina di dipendenze o più, proverei a suddividere quella classe.

Sono d'accordo con te sul fatto che dovresti evitare gli eventing pattern a meno che tu non abbia una buona ragione per usarli. L'uso di eventing per aggirare i problemi di accoppiamento e SRP non mi sembra un buon approccio.