Classi orientate agli oggetti e singola responsabilità [duplicato]

Principio di responsabilità singola significa che una classe dovrebbe avere un'unica "responsabilità". Questo non significa tuttavia una "azione" o un "attributo".

Se dovessi scrivere un elenco di ciò che un mostro in un gioco potrebbe aver bisogno di fare, potrei trovare un elenco come questo:

• I mostri hanno attributi come la salute e il potere di attacco. Questi attributi possono cambiare quando il mostro subisce danni, o forse può prendere un'arma diversa.
• I mostri hanno un'intelligenza artificiale che governa le sue azioni e differenzia piccoli mostri stupidi con mostri più robusti e intelligenti.
• I mostri devono essere visualizzati sullo schermo in qualche modo.

Ci sono molteplici responsabilità qui. Chiaramente, "avere salute" e "avere potere d'attacco" non sono responsabilità diverse: sono entrambi attributi che definiscono cos'è un mostro e quanto sia duro rispetto ad altri mostri.

L'intelligenza artificiale potrebbe essere una responsabilità diversa. Forse un gioco ha 200 tipi di mostri e 10 diverse IA. Diversi tipi di mostri potrebbero essere raggruppati e agire in modo simile: l'IA non ha bisogno di essere ricodificata ogni volta, può essere condivisa. In che modo il mostro agisce potrebbe essere una responsabilità dell'IA, non il mostro stesso! Ad esempio, nella serie di giochi di Diablo, i Fallen (codardi codardi) agiscono praticamente allo stesso modo nonostante abbiano un aspetto leggermente diverso e diversa costituzione.

La visualizzazione di un mostro sullo schermo è una grande applicazione per un oggetto adattatore che ha una sua singola responsabilità: capire, per un dato mostro; dove si trova, in che stato si trova (agitando la sua arma, correndo, in piedi) e in generale come dovrebbe apparire sullo schermo.

In questo esempio potremmo avere un oggetto principale del mostro che descrive lo stato attuale del mostro, un AI innestabile che governa le sue azioni, e un oggetto adattatore che conosce lo stato visivo attuale del mostro e può produrre il suo stato grafico sul sottosistema grafico per la visualizzazione sullo schermo.

Si noti che questa analisi non riconduce al livello di singole funzioni o metodi. L'ho analizzato ad un livello più alto di quello: impantanarsi nei passaggi dell'implementazione è una cattiva idea quando si definiscono le responsabilità dell'oggetto. Una volta definite tali responsabilità e passate ai dettagli di implementazione di basso livello, ovviamente è necessario scrivere gli attributi e le funzioni per supportare tali responsabilità.

Devi considerare come usiamo la parola responsabilità. Se sei responsabile per un bambino, questa è una singola responsabilità. Sappiamo tutti che ci sono molte attività che dovrai eseguire per mantenere questa responsabilità.

Quindi per il tuo esempio di una classe di mostri. Avresti solo funzionalità e dati che riguardano il mostro. Un mostro ha salute e una volta che il mostro muore, il valore di salute è scomparso dal singolo mostro, ma potrebbe essere registrato in qualche storia. Se metti la storia nella classe dei mostri, la perdi. Se il mostro portava un bastone, quello sarebbe un oggetto separato che era posseduto dal Mostro, ma alla morte del mostro, il club sarebbe ora senza un proprietario in un posto in cui un altro oggetto potesse ottenere il possesso. Non c'è una legge che dice che devi fare questo, ma se quello era qualcosa che volevi accadesse nel tuo gioco, dovresti trovare un modo per mantenere oggetti posseduti dalle persone ma possono essere ancora disponibili quando il possesso è perso. Il mostro non può portarlo con sé.

Quindi prova a pensare nella prospettiva di quali comportamenti vuoi. Se trovi che stai apportando modifiche al mostro perché vuoi cambiare il club, ti stai sottraendo alle responsabilità della classe Monster che gestisce un personaggio mostro.