Well... I was reading the popular Design Patterns: Elements of Reusable Object-Oriented Software and another book on design patterns that claims to be the future version of this book and realized that we already use most of the concepts in our daily life. We just have to know what is called what. Of course, I found some unique and interesting patterns but that's about it.
Many of the patterns are only applicable to certain languages. Specially static typed languages with an attempt to make them more dynamic. So naturally dynamic typed languages don't need such patterns. For example, Python doesn't need builder patterns because by design every object has a builder method (__new__()) inbuilt in it which we can customize as per our requirements anytime we need to. Similarly, it doesn't need singletons as we can directly import objects from other packages.
However, such features make it a dynamic (flexible?) language at the cost of performance. Any static language using design patterns with an attempt to achieve the same flexibility is basically transforming itself to be more like a dynamic typed language.
I may be wrong in many cases, but that's my thought about it.
UPDATE: I would like to take back some claims I made in this comment. I just finished reading the book and realized how ignorant I was. I kept ignoring all the advantages this book let me gain. read this comment for more information.
Constructor method != Builder method
Actually constructor method is __init__() which handles initialisation of a new instance object. I'm talking about __new__() which handles building of an object. However, it's true that there are some builder patterns which are more that just customising the __new__() method (like all the factories). What I meant is that we don't have to think about this unless we hit the roadblock where it's really needed. And once we hit that roadblock, introducing a new pattern is much easier in this case as you have all the options you need for the change.
Most of the patterns I found in the book encourages us to move logics from compile time to run time as much as possible. Which is exactly what dynamic languages do where everything heppens on the runtime. This is what makes them flexible but at the cost of performance.
Very interesting! I might have to check out that book...
Definitely do. I just finished reading the complete book and realized how ignorant I was.
I would like to take back my comments such as "We just have to know what is called what. Of course, I found some unique and interesting patterns but that's about it."
I didn't realize the advantages I gained before reading the conclusion part. The goal of this book was to give a name to the most commonly used patterns so that we can recognize them and refer to them more easily.
Before I started reading this book, I used to get confused when getting introduced to a new repository or code base. But now, it's much easier to learn a new code base. Because now, just by reading the name of a class or the name of the package it's inside, or the kind of relationship it has with other classes or objects, I know what it's supposed to do (like aha... it's an observer, and these are supposed to be strategy classes etc.). Still, I kept ignoring all the powers I gained until I finished the whole book.
I will write a more detailed post about what I gained from this book soon.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.