In primo luogo, è importante fare una differenza tra principio di responsabilità singola (SRP, relativo al codice pulito) e separazione dei dubbi (SOC , relativo all'ingegneria in generale) .
Analizza il tuo design
Il Entity-Component-System ha lo scopo di evitare una rigida gerarchia di classi in fase di compilazione utilizzando una struttura di dati flessibile basata su un tipo di entità Entity arricchito dalla composizione in fase di esecuzione con componenti .
Capisco che:
- il tuo
HumanEntityFactory crea% umanoEntities di diverso tipo, ogni tipo essendo caratterizzato da un diverso set di default Components .
- per mantenere flessibile il sistema, definisci in fase di esecuzione i componenti standard da utilizzare per ogni tipo di utente (ad esempio
addHumanType("Warrior", { new Sword(), new WarriorRenderer() }) )
- allora un nuovo essere umano viene istanziato dalla fabbrica con il metodo
createHuman() (ad esempio createHuman("Warrior") , createHuman("Magician") e così via). Suppongo che i componenti standard siano clonati, nel caso in cui abbiano uno stato (ad esempio defensivePower , offensivePower , depreciation ).
Responsabilità singola
Il nome di questo principio è in qualche modo fuorviante. Diamo un'occhiata alle spiegazioni di RCMartin: SRP riguarda i motivi per cambiare, che sono in generale relative alle responsabilità delle persone .
Quali sono le possibili modifiche che potrebbero richiedere un cambio di fabbrica?
- modifica dell'interfaccia Entity. Questo è naturale perché consideriamo le Entità.
- modifica la logica di creazione del componente. Ad esempio, qualcuno potrebbe cambiare il modo in cui i componenti vengono creati, passando dalla clonazione alla fabbrica.
- modifica del modo in cui i tipi di esseri umani sono gestiti, insieme ai loro "modelli" di componenti.
Vedo qui 3 diverse ragioni per il cambiamento, quindi no, non è conforme all'SRP.
Si noti che avere più "template", cioè più tipi di umani, non richiederà alcuna modifica alla classe factory. Quindi questo non è rilevante per SRP.
Separazione dei dubbi
Il separazione delle preoccupazioni riguarda la modularità e il disaccoppiamento. La tua classe di fabbrica sembra rispondere a due distinte preoccupazioni:
- In primo luogo, gestisce i tipi umani (tramite il metodo
addHumanType() e la proprietà humanEntityTypeComponents ).
- Quindi crea una nuova Entità in base alla configurazione
La prima preoccupazione, è qualcosa che è correlato alla configurazione. Certamente lo fai durante l'inizializzazione e probabilmente è la conseguenza del caricamento di alcuni file di configurazione. La seconda preoccupazione non è correlata.
Quindi questo design non rispetta nemmeno la separazione delle preoccupazioni.
Modalità avanzate
La prima cosa sarebbe avere una classe che gestisca la configurazione delle entità umane.
La seconda cosa sarebbe avere una classe generatrice, che generi un elenco di componenti per un determinato tipo, in base alla configurazione.
La fabbrica di entità potrebbe quindi essere istanziata iniettando la configurazione e il generatore,