3 ms·
Good design and OOP avoids using GoF patterns while coding for many reasons. One is that they do not map well to the domain and the other is they are difficult
by zabil 5y ago
Good design and OOP avoids using GoF patterns while coding for many reasons. One is that they do not map well to the domain and the other is they are difficult to TDD or test. They are really tough to use too if you plan to publish your lib as an API.
The reason GoF got so popular is because for anyone struggling with OO principles it was easy to understand and apply. I hope for a better way to teach design by not using patterns.
- nuerow 5y ago> Good design and OOP avoids using GoF patterns while coding for many reasons. I'm sorry but this assertion is not only patently wrong but it also makes absolutely no sense at all. Whether you know it or not, design patterns are pervasive and sometimes even the central selling point of frameworks or even runtime environments. For example, one of javascript's central features and selling points is it's use of an event loop (a design pattern) and extensive use of callbacks (another design pattern) and also promises (another design pattern). Ever heard of a worker process? That's also a component of a design pattern. What about futures, promises? What about shared pointers? What about observables? What about MVC? Data transfer objects? Active records? All design patterns. > The reason GoF got so popular is because for anyone struggling with OO principles it was easy to understand and apply. No, not really. The true value of the GoF book, and others like it, is that it documented widely used design patterns and thus enabled an ubiquitous language to form.
- zabil 5y agoThanks for the references. Apologies for not explaining that well. I wasn't generalising about all patterns rather about using GoF patterns with a cookie cutter approach. Atleast, I am sure made that mistake.