As I've mentioned before. I think all software work is design work. I also have a relatively context-insensitive definition of code quality.
The code qualities to which I (and many) subscribe can apply at any level of design.
If you're writing a method, you can ask yourself any of the following...
- "How strongly-related are these instructions?"
- "How will I know when this is done?"
- "How easily will it be for my future-self to comprehend this?"
The same qualities translate into class-level design as different questions...
- "How strongly-related are the members of this class?"
- "How will I know that this class works as intended?"
- "How easily can I understand how this class fits into the larger design?"
The same principles apply all the way up to the very largest scale of software design and all the way down to the lowest-level detail.
This is one of the things that is great about these code qualities. They are general rules that are aligned with effects.
Cohesion matters because it defends against a certain kind of coupling, makes testing easier, and makes code easier to understand. It matters the same amount and for the same reasons at any scale.
There's something aesthetically pleasing about that.
