Design Patterns
Design Patterns
Design Patterns
A design pattern, in terms of software engineering, is a solution to a commonly recurring problem. These
solutions are generic and reusable. They are not a one size fits all solution, which is why there are different
patterns. Designers and Developers will need to adopt a best fit approach to determine which patterns would
work in a given scenario.
Application design patterns can be divided into 3 main categories: 1) Application Design Patters, 2) System
Design Patterns and 3) Code Design Patterns.
Design patterns are popular amongst developers because of their robustness and the fact that they are
substantiated through regular and repeated use across the software development industry. They help
facilitate development of cohesive modules in a software solution, modules that have limited coupling. In
addition, they also identify and separate the variability that exists in system requirements (if any) and
therefore make the system easier to understand and explain.
1. MVC (Model, View, Controller), which is commonly used with Django web Development. Personal
experience of this pattern is limited to the Django Assignment as part of this Unit of work.
2. Domain Model, where each object represents a ‘thing’ that is meaningful. This thing is built up from
connected objects that each have a narrower focus than the previous one.
3. Front Controller, where a controller handles any and all website requests.
1. Broker, a server publishes (registers) its capabilities with a broker and the broker redirects client
requests to the correct server based on the brokers registry.
2. Strangler, commonly used for migration between systems. This uses a proxy to point to the old
service whilst the new service is being setup. Once done, the proxy points to the new service and
once migration is successful, both the old service and the proxy itself can be removed.
3. Microservices, used for highly scalable systems that are distributed and interdependent of one
another. Amazon offers a huge market of Microservices on their AWS product, from S3 to Lambda to
Security.
4. SAGA, this pattern is used when data consistency is paramount in a system should that system not
have good coupling. If a single operation in a given sequence fails it can be rolled back easily.
1. Singleton, used where a class will have one instance, usually shared amongst different objects. The
prime example of this is a log file.
2. Factory, a class that builds complex objects.
3. Adapter, provides interfaces that help clients use objects that are incompatible under other
circumstances.
4. Façade, hides complex structures behind a simpler, cleaner interface for clients to use.
5. Decorator, wraps around methods, providing additional functionality.
6. Dependency Injection, generally used in testing applications and software solutions. Allows objects to
retrieve an instance of the object it requires the use of.
7. Chain of responsibility, passes requests down a chain of handlers for a given request.
8. Iterator, traverses collections.
Personal experience of design patterns is exceptionally limited. MVC and Microservices are the only ones I
recognise, primarily through this Unit. Am, utterly unfamiliar with the other patterns.
In regards to using specific patterns in my own architectures and/or code. In all honesty I cannot answer that
question. I fail to comprehend the basics of design patterns and have absolutely zero knowledge of what they
are, how they work and when/where to apply them. Provided documentation, examples and videos are no
help.