1)
In fact if two responsibilities are always expected to change at the same time you arguably should not separate them into different classes as this would lead, to quote Martin, to a "smell of Needless Complexity". The same is the case for responsibilities that never change - the behavior is invariant, and there is no need to split it.
Presumo che anche se ci si aspetta che le responsabilità non correlate cambino per lo stesso motivo (o se non cambino mai), non dovremmo comunque inserirle nella stessa classe, poiché ciò violerebbe ancora il principio di alta coesione?
2) Ho trovato due definizioni abbastanza diverse per SRP:
Single Responsibility Principle says that a subsystem, module, class, or even a function, should not have more than one reason to change.
e
There should never be more than one reason for a class to change
La seconda definizione non stringe SRP a un livello di classe? In tal caso, la prima citazione non è errata sostenendo che SRP può anche essere applicato a livello di sottosistema, modulo e funzione?
grazie