Quindi, la cosa su tutti questi principi è che non sono solo lì in modo che il codice abbia un certo fascino estetico - hanno uno scopo pratico. In particolare, si preoccupano di rendere il codice gestibile e di poter cambiare, estendere o sostituire parti di esso senza troppi problemi. Ora, l'SRP riguarda il fatto che le tue classi "fanno una cosa", perché se fanno più di "una cosa", il codice che fa queste diverse cose molto probabilmente si accoppierà in modi sottili e, di conseguenza, diventerà resistente al cambiamento - nel senso che sarà difficile cambiare queste parti separatamente. Il che significa che non si può veramente dire quali siano le responsabilità separate solo osservando quali classi e comportamenti si debbano implementare (nella migliore delle ipotesi si possono fare ipotesi plausibili, ma ciò richiede esperienza).
Invece, devi cercare di capire che cosa è più probabile che cambi e in che modo - e molto probabilmente non riuscirai a farlo correttamente al primo tentativo, anche se hai esperienza. Il tuo codice è un modello software (una rappresentazione) di questo concetto logico che è il sistema che stai cercando di costruire (il concetto che include tutte le forze del mondo reale che possono influenzare ciò che quel sistema è, e come cambierà), e ciò che OO design sta cercando di fare è catturare quali sono le diverse parti di quel sistema, in che modo il sistema cambierà e come mettere insieme questi diversi componenti per soddisfare tutto ciò. E ci sono sempre diversi modi per modellare un tale sistema; alcuni modi funzioneranno meglio di altri nella pratica. Sei tu (o il tuo team) che deve definire cosa significa "cosa singola" o "singola responsabilità" per il sistema che stai cercando di costruire e mantenere (così come quanto lavoro non è "troppo fastidio").
Detto questo, ci sono spesso cose che cambiano a livello di metodo e di classe mentre sviluppiamo il codice, mentre stiamo cercando di capire come implementare alcune funzionalità. Quindi è bene applicare SRP e altri principi in qualche modo preventivamente a questo livello al sottoproblema che stiamo risolvendo, soprattutto perché in questo ambito possiamo predire meglio cosa vorremmo separare, o dove potremmo voler cambiare l'implementazione in un secondo momento. Allo stesso modo quando si tratta di classi strettamente correlate. Quindi, a quel livello, poiché questi sono più o meno i tipi di problemi di programmazione che tutti conosciamo, possiamo provvisoriamente parlare di SRP violati o meno, ma a livello di sistema richiede una comprensione più profonda dei requisiti e sistema stesso, come modellato. A quel livello, è anche importante non sovradimensionare il sistema in anticipo.
Ma torniamo al tuo caso particolare; in generale, sembra una buona idea separarli. Ora, potresti avere un'altra classe (come AI ) che usa gli altri - la sua responsabilità sarebbe quella di coordinare ciò che fanno le altre classi. Basta non spostare il codice da queste altre classi alla classe AI - mantieni ogni pace del codice in un posto separato e lascia che ognuno faccia il proprio lavoro. È una gerarchia di responsabilità, in un certo senso.
Infine, il fatto che tu stia facendo questo per esercitarti, allo scopo di cercare di capire i principi dell'OOP, significa, da un lato, che hai una certa libertà di esplorare, ma dall'altro, che non lo farai ricevere richieste di modifica e segnalazioni di bug da parte dei clienti che alla fine saranno il test di quanto appropriate siano state le tue scelte progettuali. Quindi cerca di compensare in qualche modo. Prendi il tuo attuale design e studialo. Quando si progettano le classi in un certo modo, è sempre un compromesso di qualche tipo: manutenibilità vs complessità, prestazioni vs chiarezza, modularità in qualche modo rispetto a una struttura rigida in altre, ecc. Cerca di capire quali parti del tuo codice sono diventate più facili da cambiare, e quali sono diventati più difficili. Prova a cambiare l'implementazione per verificare se la tua comprensione è corretta. Quindi prova a creare un design diverso e studialo. Cosa è cambiato? Che cosa hai guadagnato e cosa hai perso? Questo ti aiuterà a capire il ragionamento dietro SRP e altri principi, che è ciò che conta davvero.