Design patterns

Table of Contents

What is the difference between design patterns and design principles?

Difference between Design patterns and Design principles

What are design patterns?

Someone has already solved your (design) problems. We need to exploit the wisdom and lessons learned by other developers who have been down the same design problem road. The best way to use patterns is to load your brain with them and then recognize places in your designs and existing applications where you can apply them. Instead of code reuse, with patterns you get experience reuse.

Design patterns give you a shared vocabulary with other developers. Once you have got the vocabulary, you can more easily communicate with other developers and inspire those who don’t know patterns to start learning them. It also elevates your thinking about architectures by letting you think at the pattern level, not the nitty-gritty object level. If you communicate in patterns, then other developers know immediately and precisely the design you are describing.

A design pattern addresses a recurring design problem that arises in specific design situations and presents a solution. Pattern is a defined, used and tested solution for a known problem. Design patterns are all about re - use. design is blue print or sketch of something so it can be defined as creation of something in mind. Moving to pattern, we can define it as guideline, or something that repeats. Now the definition of design pattern becomes creating something in mind that repeats or in other words capturing design ideas as a pattern to the problems.

Some problem patterns happen over and over again in a given context and Design Pattern provides a core of the solution in such a way that you can use the core solution every time but implementation should and may vary and the main reason behind that is we have the core solution and not the exact solution.

How to use Design Patterns?

We have all used off-the-shelf libraries and frameworks. We take them, write some code against their APIs, compile them into our programs, and benefit from a lot of code someone else has written. Libraries and frameworks go a long way towards a development model where we can just pick and choose components and plug them right in. But, they don’t help us structure our own applications in ways that are easier to understand, more maintainable and flexible. That is where Design Patterns come in.

Design Patterns do not go directly into your code, they first go into your brain. Once you’ve loaded your brain with a good working knowledge of patterns, you can then start to apply them to your new designs, and rework your old code when you find it is degrading into an inflexible mess of spaghetti code.

Reading material

  1. https://www.javadevjournal.com/category/java-design-patterns/
  2. From the refactoring website, take notes from the relations with other patterns section in each page. https://refactoring.guru/
  3. When to use and common usage: https://www.oodesign.com/
  4. https://medium.com/@robert.junklewitz/why-do-we-need-design-principles-c7a9b2a9455?source=post_page-----dbbe54206b63----1—————————-

TODO

For each pattern, identify real world scenarios. How/where is it used? Add a column in the tables to show what OO principles a given pattern is implementing.

Tags

  1. Cloud Design Patterns
  2. Core J2EE Patterns
  3. Gang of four design patterns
  4. Inversion of Control

Is MVC pattern missing from the list here?

Other patterns:

  1. Producer Consumer design pattern
  2. Resource Acquisition Is Initialization Pattern

Links to this note