Controlling complexity is the essence of computer programming.

Brian Kernighan

All problems in computer science can be solved by another level of indirection (abstraction).

David Wheeler

The term Design Patterns can confuse you at first, or it can seem like something incredibly difficult. In fact it is nothing more than convenient ways of identifying, labelling and coding general solutions to recurring design problems.

So design patterns are nothing more than commonly occurring patterns in design that are repeatable and generalist enough to be written down and named as software design constructs that all can commonly identify and apply. Note however that a design pattern refers to the logical structure of the code, what it does and how it addresses the issues, not on direct code portability across projects, but in the portability of the way design issues can be addressed.

Imagine yourself working in a project team and someone just wrote a class and is trying to explain to you that only one instance is allowed. Instead the person could simply say "The class I just wrote is a Singleton".


Design patterns were first introduced by GoF (Gang of Four), where they mentioned them as being solutions to given problems. If you would like to know more, GoF refers to the four authors of the book, Design Patterns: Elements of Reusable Object-Oriented Software. The book's authors are Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword by Grady Booch. This book covers software engineering solutions to the commonly occurring problems in software design. There were 23 design patterns first identified, and the first implementation was done with respect to the Java program language. Design patterns are discoveries and not an invention in themselves.

Stem principles

The open/close principle

states that classes or objects and methods should be open for extension but closed for modifications.

The inversion of control principle

states that high-level modules shouldn't be dependent on low-level modules; they should both be dependent on abstractions. Details should depend on abstractions and not the other way round.

The interface segregation principle

clients should not be forced to depend on interfaces they don't use.

The single responsibility principle

states, a class should have only one reason to change.

The substitution principle

states that derived classes must be able to completely substitute the base classes.

Advantages of design patterns

  • They are reusable across multiple projects
  • The architectural level of problems can be solved
  • They are time-tested and well-proven, which is the experience of developers and architects
  • They have reliability and dependence

Target audience

Anybody who are curious in studying and simultaneously appreciate a clarity.


Please feel free to do any corrections, amendments or suggestions. Keep clear, please.


Python3 only

It is a contemporary version and seems it is used to become the one very soon.


Brief survey

Several examples

Test suite


├── patterns
│   ├── behavioral
│   │   └──
│   ├── creational
│   │   ├── abstract_factory
│   │   │   ├──
│   │   │   ├──
│   │   │   └──
│   │   ├── builder
│   │   ├── factory
│   │   │   ├──
│   │   │   ├──
│   │   │   ├──
│   │   │   ├──
│   │   │   ├──
│   │   │   ├──
│   │   │   └──
│   │   ├── factory_method
│   │   ├── prototype
│   │   ├──
│   │   └── singleton
│   ├──
│   └── structural
│       └──

10 directories, 15 files


blog comments powered by Disqus


09 March 2017


literate programming emacs Python3