Programming/Principles
Principles
Easier to change (ETC)
Good Design Is Easier to Change Than Bad Design.
A thing is well designed if it adapts to the people who use it. For code, that means it must adapt by changing. So we believe in the ETC principle: Easier to Change. ETC. That's it.
As far as we can tell, every design principle out there is a special case of ETC.
Why is decoupling good? Because by isolating concerns we make each easier to change. ETC.
Why is the single responsibility principle useful? Because a change in requirements is mirrored by a change in just one module. ETC.
Why is naming important? Because good names make code easier to read, and you have to read it to change it. ETC!
ETC Is a Value, Not a Rule.
Values are things that help you make decisions: should I do this, or that? When it comes to thinking about software, ETC is a guide, helping you choose between paths. Just like all your other values, it should be floating just behind your conscious thought, subtly nudging you in the right direction. [TH20]
Meyer's Five Rules
Linguistic Modular Units principle
Modules must correspond to syntactic units in the language used.
Self-Documentation principle
The designer of a module should strive to make all information about the module part of the module itself.
Uniform Access principle
All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.
Open-Closed principle
Modules should be both open and closed.
Bibliography
- [M97] Bertrand Meyer. Object-Oriented Software Construction, second edition. Prentice Hall, 1997.
- [TH20] David Thomas, Andrew Hunt. The Pragmatic Programmer, 20th Anniversary Edition. Addison–Wesley, 2020.
