From Thalesians Wiki
< Programming
Revision as of 10:13, 11 July 2021 by Admin (talk | contribs)


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.


  • [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.