Posso assegnare a una singola classe più responsabilità se solo una sarà mai riutilizzabile?

Una formulazione dell'SRP è: ogni classe dovrebbe avere solo una ragione per cambiare.
La ragione di questo è che i requisiti sono quasi certi di cambiare ad un certo punto nel futuro, probabilmente il meno conveniente.

Quando si utilizza una classe per implementare due funzionalità separate, si rischia di imbattersi in una situazione, in cui i requisiti per entrambe le funzionalità cambiano e i due insiemi di requisiti e la decisione progettuale di non mantenere separata la loro implementazione non possono più essere riconciliati. Questa è l'ultima chiamata per applicare SRP e refactoring della prima classe in due (o più), prima di iniziare a piegare il codice attorno a un difetto di progettazione.

Ma seriamente, fallo subito la prima volta. Per tutto il tempo che rifiuti di speculare sul fatto che sia sicuro violare SRP in base alla tua prognosi sui cambiamenti dei requisiti futuri (che è qualcosa a cui i programmatori in realtà fanno semplicemente schifo), usalo per creare due classi. È una cosa banale da fare, che la maggior parte degli IDE farà anche per te.

La tua ipotesi che potresti sapere che le funzioni non saranno riutilizzate non è corretta. Non puoi sapere chi vorrà usare le tue lezioni o come vorranno usarle. Pertanto, dovresti sempre presumere che la tua classe verrà utilizzata da qualcun altro in futuro e attenersi ai buoni principi di progettazione.

Se non altro quando rivisita il codice tra 18 mesi sarai in grado di capire cosa stavi tentando di fare quando hai scritto il codice in primo luogo.

I test di unità possono essere considerati come riutilizzare una classe.

Pertanto SRP migliora la testabilità .