To me it makes sense to think about how much state is being mutated in a given class. If you have a class with 200 different properties that are changing somewh

To me it makes sense to think about how much state is being mutated in a given class. If you have a class with 200 different properties that are changing somewhat orthogonally to each other, you probably need to think things through and separate concerns a bit. Still kind of an 'arbitrary principle' but another way of looking at things. You want to encapsulate the moving parts but you don't want to throw every moving part in a giant bag. Designating a class as having a single responsibility is an easy way to ensure that there is a minimal amount of state per class, but if the abstractions you are creating with this principle aren't logical than you are still left with a lot of moving parts someone has to think about when making modifications. All these principles mostly only work if the system is also being designed rationally. Applying principles arbitrarily to a messy codebase will not necessarily get you a good design (and probably not) but thinking about these principles when making design decisions can sometimes be useful.