Settling the debate against Design Principles and Design Patterns
The Complex World of Design Principles/Patterns
When I was in college, we were introduced to Object-Oriented Programming. We learned the concept of abstraction, encapsulation, and inheritance. It was a new world. Little did I know that I was going to get bombarded with a sea of design principles/patterns. Before diving into its depth, I want to set some context. I am not an expert on design principles/patterns. I don't understand all of them. Hence, I don't use all of them. Let's get started.
Some of the design principles I have encountered
- SOLID
- KISS - Keep it simple, stupid
- DRY - Don't repeat yourself
- YAGNI - You aren't gonna need it
Design Patterns is a whole different game. There are so many that I don't want to start listing them here. But I do find a few of them very complicated.
Why is this world complicated?
Let's face it. Creating complex applications with multiple moving parts is hard. You have multi-billion dollar companies running softwares like facebook, and Instagram. While a normal social media user might not understand the complexities behind the application, a software engineer does. We understand why FAANG companies need thousands of engineers.
Are design principles necessary?
For complex applications, it is supposed to. The idea is, a problem can be solved in multiple ways. These design principles provide rules to eliminate bad solutions and pick a good one. So, Are design principles necessary? Yes if you understand them. Also, I encourage everyone to understand them.
How do I interpret Design Principles?
Some design principles are pretty straightforward forward and that is why I like them. For example:
- DRY: Don't Repeat Yourself is just a sophisticated way of saying don't copy and paste code. If you think you need to Ctrl+C/V, just think about creating a function for the code and use the function.
- YAGNI: You aren't gonna need it means don't try to complicate your design to incorporate requirements that are not yet defined. If I want to create functionality to determine the area of a square, do I need to implement the volume of a cube as well?
Are design patterns necessary?
Design patterns are different. They are not rules. They are template solutions to well-known problems. I know it is not an accurate description, but it is the simplest one I can offer. So, Are design patterns necessary? It depends on the complexity of the problem. Simple problems don't need design patterns and might even violate design principles like YAGNI. But they can also help you break down complex problems if you can identify the correct design pattern. The major issue I have with design patterns is that I can map a problem to multiple design patterns and it causes confusion. Maybe it is a lack in understanding of the design pattern but as I said earlier I am still learning.
YAGNI FTW
My default approach for any decision is based on YAGNI. Don't do it if you don't need it. For now, I focus on OOP - creating correct interfaces. If I am comfortable with a design principle, I apply it. If I think a design pattern can help me solve a problem, I use it.