Design patterns overview
Table of Contents
Intro
Foreword
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".
Intention
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.
Contribution
Please feel free to do any corrections, amendments or suggestions. Keep clear, please.
Overview
Python3 only
It is a contemporary version and seems it is used to become the one very soon.
Methodology
Brief survey
Several examples
Test suite
Structure
. ├── patterns │ ├── behavioral │ │ └── README.org │ ├── creational │ │ ├── abstract_factory │ │ │ ├── pet_shop.py │ │ │ ├── README.org │ │ │ └── test_abstract_factory.py │ │ ├── builder │ │ ├── factory │ │ │ ├── pet_factory.py │ │ │ ├── README.org │ │ │ ├── sophisticated_pet_factory.py │ │ │ ├── test_pet_factory.py │ │ │ ├── test_sophisticated_pet_factory.py │ │ │ ├── test_weapon_factory.py │ │ │ └── weapon_factory.py │ │ ├── factory_method │ │ ├── prototype │ │ ├── README.org │ │ └── singleton │ ├── README.org │ └── structural │ └── README.org └── README.org 10 directories, 15 files
Corollary
blog comments powered by Disqus