"Gather together those things that change for the same reason, and separate those things that change for different reasons ... a subsystem, module, class, or even a function, should not have more than one reason to change ... separating things that change for different reasons, is one of the keys to creating designs that have an independently deployable component structure."
Recovering interrupter with occasional relapses, lover of spreadsheets, blogger, programmer, adept debugger, conjurer of analogies, and probably other things.
Recovering interrupter with occasional relapses, lover of spreadsheets, blogger, programmer, adept debugger, conjurer of analogies, and probably other things.
When I create a class in Ruby, if I'm at my best, I always try to start with the following comment before I write any code:
The purpose of this class is...
I have a high degree of confidence that that intention will persist regardless of the implementation details.
This then follows with methods, but by the time I've written out the class purpose, the methods are (in the moment) somewhat self-evident. (I still go back and document the methods)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Simple rule: Try not to break the "Single Responsibility Principle" (SRP), and most things will fall into place
SRP:
"Gather together those things that change for the same reason, and separate those things that change for different reasons ... a subsystem, module, class, or even a function, should not have more than one reason to change ... separating things that change for different reasons, is one of the keys to creating designs that have an independently deployable component structure."
Responsibilities and "one reason to change" are related but not equivalent.
"Single responsibility" is an oversimplification of cohesion.
Ultimately it's about discovering the boundaries where there is
something that is easier to recognize than it is to author (and it's the fundamental idea behind Bounded Contexts).
Gather together those things that change for the same reason is a good starting point (to avoid the shotgun surgery and divergent change code smells).
Kevlin Henney rant
The quote of "gather together..." has me realize how very much I love proverbs compared to "rules".
When I create a class in Ruby, if I'm at my best, I always try to start with the following comment before I write any code:
I have a high degree of confidence that that intention will persist regardless of the implementation details.
This then follows with methods, but by the time I've written out the class purpose, the methods are (in the moment) somewhat self-evident. (I still go back and document the methods)