Principles on designing software
De Nosolosoftwarewiki
Contenido |
The rule of thumb: managing complexity
Write your software for others to read.
David Parnas published On the criteria to be used in decomposing a system into modules in December 1972. The paper discusses why is a good idea to use a "hiding complexity" strategy instead of "secuencial approach" estrategy to build software. Although the paper is from 1972 -previously to Object Orientation Programming going mainstream- it is still worth reading it. The seminal idea is to put together chunks of code which have high probability of change and one single purpose, as it's easier to understand. That rule applies at all levels of design: variables, methods, class, packages, etc.
- Applied lesson: thinking an application as an always evolving thing -and taking into account that 80% of time is maintainance-, the best idea is to write software for others to read and hide complexity at every step.
The big three: cohesion, coupling and abstraction
Cohesion
Things that belong together should be kept together.
- A good discussion on cohesion.
Coupling
- A good discussion on coupling.
- See also Fan-in/Fan-out concept, which is a primitive idea from electronics design applied to software design.
Abstraction
Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. -- Eric S. Raymon, The Art of UNIX programming
- A good discussion on abstraction.
The basic idea of OO is that you are able to create your own custom data (Abstract Data Types) to better structure your program. Thinking of classes as data types has helped me to code better.
SOLID: redefining the clasics at the end of century
This acronym has grown inside agilism circles coined by Bob Martin.
SOLID stands for:
- S - Single Responsibility Principle
- O - Open/Closed Principle
- L - Liskov Substitution Principle
- I - Interface Segregation Principle
- D - Dependency inversion Principle
Notes
- Interesting reflections by Kent Beck on ordinary VS revolutionary design, as a discussion on Open/Closed Principle.
Other related concepts
- Write your code in the domain language of the problem to solve
- DRY: don't repeat yourself
