PieroCampanelli.info

In the last post I wrote that “Design principles are quite generic and abstract that rarely help concretely a developer during the process of software design”. In this post I report a list of Software Design principles that I have mined from several books, papers.

Source: [Gamma et all, “Design Patterns: Elements of Reusable Object-Oriented Software”, Addison-Wesley, 1995]

• Program an Interface not an Implementation
• Favor Composition Versus Inheritance
• Find what varies and encapsulate it

Source: [R. Martin, “Agile Software Development, Principles, Patterns, and Practices”, Prentice-Hall, 2002]

• Dependency-Inversion Principle
• Liskov Substitution Principle
• Open-Closed Principle
• Interface-Segregation Principle
• Reuse/Release Equivalency Principle
• Common Closure Principle
• Common Reuse Principle
• Acyclic Dependencies Principle
• Stable Dependencies Principle
• Stable Abstraction Principle

Source: [Larman, “Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development”, Prentice-Hall, 2004]

• Design principles are codified in the GRASP Pattern
• GRASP (Pattern of General Principles in Assigning Responsabilities)
• Assign a responsibility to the information expert
• Assign a responsability so that coupling remains low
• Assign a responsability so that cohesion remains high
• Assign responsabilities using polymorphic operations
• Assign a highly cohesive set of responsabilities to an artificial class that does not represent anything in the problem domain (when you want to maintain low coupling and high cohesion)
• Don’t talk to strangers (Law of Demeter)

Source: [Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules”, Commununication of ACM, 1972]

• Information Hiding
• Modularity

Source: [Hunt, Thomas, “The Pragmatic Programmer: From Journeyman to Master”, Addison-Wesley, 1999]

• DRY – Don’t Repeat yourself
• Make it easy to reuse
• Design for Orthogonality
• Eliminate effects between unrelated things
• Program close to the problem domain
• Minimize Coupling between Modules
• Design Using Services
• Always Design for Concurrency
• Abstractions Live Longer than details

Source: [Lieberherr,Holland, “Assuring Good Style for Object-Oriented Programs”, IEEE Software, September 1989]

• Law of Demeter

Source: [Raymond, “Art of Unix Programming”, Addison-Wesley, 2003]

• Rule of Modularity: Write simple parts connected by clean interfaces
• Rule of Clarity: Clarity is better than cleverness.
• Rule of Composition: Design programs to be connected to other programs.
• Rule of Separation: Separate policy from mechanism; separate interfaces from engines
• Rule of Simplicity: Design for simplicity; add complexity only where you must
• Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do
• Rule of Transparency: Design for visibility to make inspection and debugging easier
• Rule of Robustness: Robustness is the child of transparency and simplicity
• Rule of Representation: Fold knowledge into data so program logic can be stupid and robust
• Rule of Least Surprise: In interface design, always do the least surprising thing
• Rule of Silence: When a program has nothing surprising to say, it should say nothing
• Rule of Repair: When you must fail, fail noisily and as soon as possible
• Rule of Economy: Programmer time is expensive; conserve it in preference to machine time
• Rule of Generation: Avoid hand-hacking; write programs to write programs when you can
• Rule of Optimization: Prototype before polishing. Get it working before you optimize it
• Rule of Diversity: Distrust all claims for “one true way”
• Rule of Extensibility: Design for the future, because it will be here sooner than you think

Source: [Coplein, “Multi-paradigm Design for C++”, Addison-Wesley, 1998]

• Commonality/Variability Analysis

Source: [Lidwell et all., “Universal Design Principles”, Rockport, 2003]

I report only a subset of principles that according to me apply directly to software design:

• 80/20 Rule
• Consistency
• Cost-Benefit
• Layering
• Modularity
• Ockam’s Razor

Source: [Meyer, “Object Oriented Software Construction”, Prentice-Hall, 1997]

• Modularity
• Direct Mapping
• Few Interfaces
• Small Interfaces
• Explicit Interfaces
• Information Hiding
• Linguistic Modular Units
• Self-Documentation Principle
• Uniform-Access Principle
• Open-Closed Principle
• Single-Choice Principle

Source: [Wirs-Brock, McKean, “Object Design”, Pearson Education, 2003]

• Design for flexibility and Extension (abstraction, classification, composition, inheritance and parametrization)
• Design for reliability (consistent exception-handling policies)
• Predictable, Consistent and Comprehensible design (there is no recipe here)

Source: [Martin Fowler, Kent Beck, John Brant, Refactoring: improving the design of existing code, Addison-Wesley, 1999]

In this book the idea of code smell was introduced. Code smells can be figure out as guidelines when you design software

• Duplicated Code
• Long Method
• Large Class
• Long Parameter List
• Divergent Change
• Shotgun Surgery
• Data Clumps
• Primitive Obsession
• Switch Statement
• Parallel Inheritance Hierarchy
• Lazy Class
• Eliminate unuseful classes
• Speculative Generality
• Temporary Field
• Message Chains
• Middle Man
• Inappropriate Intimacy
• Alternative Classes with different interfaces
• Incomplete Library Class
• Data Class
• Refused Bequest
• Comments