Design Principles and Design Patterns

As a project manager who does not have a programming background, I find it essential to understand as much as possible about the way developers craft solutions to business problems in their code design and implementation. The best developers I know follow a set of design principles and patterns that ensure strong, flexible, extensible, modular code.

Writing on this subject at his website, Robert C. Martin identifies a set of design principles and design patterns that all software development project managers should understand
(see )

Here they are in summary:

Principles of Object Oriented Class Design
  1. The Open Closed Principle (OCP) - A module should be open for extension but closed for modification. The correct use of this principle and its related techniques allow developers to add new features to existing code without changing the existing code and by only adding new code. It is always better that changes not propogate into existing code that already works. If you don't have to change working code, you aren't likely to break it.
  2. The Liskov Substitution Principle (LSP) - Subclasses should be substitutable for their base classes.
  3. The Dependency Inversion Principle (DIP) - Depend upon abstraction. Do not depend upon concretions. Dependency inversion is the strategy of depending upon interfaces or abstract functions and classes rather than upon concrete functions and classes. Every dependency in the design should target an interface, or an abstract class. No dependency should target a concrete class. Concrete things change alot; abstract things change much less frequently.
  4. The Interface Segregation Principle (ISP) - Many client-specific interfaces are better than one general purpose interface. If you have a class that has several clients, rather than loading the class with all the methods that the clients need, create specific interfaces for each client and multiply inherit them into the class.

Principles of Package Architecture (aka, Package Cohesion Principles)

  1. The Release Reuse Equivalency Principle (REP) - The granule of reuse is the granule of release.
  2. The Common Closure Principle (CCP) - Classes that change together belong together.
  3. The Common Reuse Principle (CRP) - Classes that aren't reused together should not be grouped together.
  4. The Acyclic Dependencies Principle (ADP) - The dependencies between packages must not form cycles.
  5. The Stable Dependencies Principle (SDP) - Depend in the direction of stability.
  6. The Stable Abstractions Principle (SAP) - Stable packages should be abstract packages.

Patterns of Object Oriented Architecture

When following the principles described above to create object oriented architectures, one finds that one repeats the same structures over and over again. These repeating structures of design and architecture are known as design patterns. The essential definition of a design pattern is a well-worn and known good solution to a common problem. Design patterns are not new. Rather, they are old techniques that have shown their usefulness over a period of many years.

  1. Abstract Server
  2. Adapter
  3. Observer
  4. Bridge
  5. Abstract Factory


Popular posts from this blog

Severity, Priority, Impact and Likelihood - Managing Defects and Risks

Enterprise Agile Framework: The Entrepreneurial Operating System (EOS)

Chatbot Code of Ethics