When it comes to problem solving in Software Engineering, the methodology behind it isn’t unexplored territory. There are many different ways to solve a problem and an even wider variety of ways to approach them. Design patterns are the tried and true methods of development.
Design patterns aren’t a how-to-guide or a checklist to use when solving problems. They are used to aid a Software Engineer, for example a certain Design pattern could be made in a way to account for certain problems, a developer could take note of this to improve their development.
The closest thing I could describe this is using a cookbook’s instructions to cook a dish. If you follow the instructions down to a T, you might find that the finished product feels like something is missing, or could use a small adjustment. This is where personal experience is used to fill in the holes and create something complete.
During my time developing dorm room cooks, I’ve used a variety of design patterns in my code.
Prototype is a fully initialized instance to be copied or cloned, observer is used for publishing and subscribing, MVC is used for mongoDB, and Factory is used for defining methods.
People aren’t perfect, our code isn’t perfect, but using design patterns we can refine our development using methods that have been reliable for years as reference. By using it as an aid, it becomes a great tool alongside personal experience for all Software Engineers.