Difference between revisions of "Programming/Principles"
(Created page with "=Principles= ==Easier to change (ETC)== <blockquote> '''Good Design Is Easier to Change Than Bad Design.''' A thing is well designed if it adapts to the people who use it....") |
|||
| Line 18: | Line 18: | ||
ETC Is a Value, Not a Rule. | 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. | 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]''' | ||
</blockquote> | </blockquote> | ||
Meyer's Five Rules | ==Meyer's Five Rules== | ||
=Linguistic Modular Units principle= | ===Linguistic Modular Units principle=== | ||
<blockquote> | <blockquote> | ||
| Line 29: | Line 29: | ||
</blockquote> | </blockquote> | ||
=Self-Documentation principle= | ===Self-Documentation principle=== | ||
<blockquote> | <blockquote> | ||
| Line 35: | Line 35: | ||
</blockquote> | </blockquote> | ||
=Uniform Access principle= | ===Uniform Access principle=== | ||
<blockquote> | <blockquote> | ||
| Line 41: | Line 41: | ||
</blockquote> | </blockquote> | ||
= Open-Closed principle= | ===Open-Closed principle=== | ||
<blockquote> | <blockquote> | ||
| Line 49: | Line 49: | ||
=Bibliography= | =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. | |||
Revision as of 10:13, 11 July 2021
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.
