Design Patterns
2019, Feb 01
Notes on Why/What/Where about design patterns.
Design patterns are solutions to recurring problems; guidelines on how to tackle certain problems. They are not classes, packages or libraries that you can plug into your application and wait for the magic to happen. These are, rather, guidelines on how to tackle certain problems in certain situations. Also design pattern isn’t a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.
⚠️ Certain things which are important about design patterns
- Design patterns are not a silver bullet to all your problems.
- Do not try to force them; bad things are supposed to happen, if done so.
- Keep in mind that design patterns are solutions to problems, not solutions finding problems; so don’t overthink.
- If used in a correct place in a correct manner, they can prove to be a savior; or else they can result in a ugly crafted mess of a code.
🙉 Myths about design patterns
- Those 23 Design Patterns are capable to make dent to any problem. This is untrue, Design patterns in general sense is a vocabulary for developers to communicate well a solution in less efforts. They are not just bound to Object Oriented Design.
- Design patterns makes solution efficient. This is untrue, any code is efficient if it is hitting minima in time/space complexity only, if a design pattern is making that happen, it can be considered to be making code efficient, else not.
- Patterns are just rules, tricks, and data structures. This is untrue, Patterns are not rules you can apply mindlessly nor are they limited to programming tricks
- Patterns Guarantee Reusable Software, Higher Productivity, world in peace, etc. This is untrue, Patterns do nothing to remove the human from thinking creative towards process. They may give the feel, if used elegantly.
- Plumbing right Patterns will Generate elegant Architectures. This is untrue, Patterns themselves don’t generate anything. People do - and they do it well only if they and the patterns they use are effective. An Architect should never plumb design patterns or try to put them aggressively, just for a sake of design.
- When solving a problem, you should always just start with the appropriate pattern. This is untrue, please don’t try to plug a design pattern and hope it serve the best. A developer should be aware about design patterns just to better communicate, those recurring problems, in given context.
🖖 Design Patterns are not just for developers, UX desiginers or Architects. It isn’t bad to know if you being manager or even someone from testing background 🤟
If you are an architect, You should know more than you being aware about just Design Patterns:
- You should be well versed with the programming environment (languages internals/infrastructures et al) its efficient techniques/best practices involving its usage.
- You should be well versed/experienced about Software Development AntiPatterns.
- You should be well enlightened with Software Architecture AntiPatterns.
- You should have done at-least once in life-time, refactoring a bad code to good code, refactoring legacy systems to modern system.