3 ms·

I can't speak for the original commenter, but I think that book has (unintentionally) done a lot of damage to software by getting people excited about things th

I can't speak for the original commenter, but I think that book has (unintentionally) done a lot of damage to software by getting people excited about things they have no business getting excited about. It's impossible to read that book as a junior developer and get any use out of it. What inevitably happens is the junior developer reads it, gets excited about the patterns, and injects as many patterns as they can into all of the source code they write. I've done it myself, and I've seen this happen to others time and time again. You can accomplish writing perfectly clean, readable, and maintainable projects that multiple people work on without learning any of the design patterns in that book. You will probably discover later that you were using certain patterns without knowing what they were called. The earlier you learn this, the better off you will be.

geezerjay 9y ago
> You can accomplish writing perfectly clean, readable, and maintainable projects that multiple people work on without learning any of the design patterns in that book. You will probably discover later that you were using certain patterns without knowing what they were called. The earlier you learn this, the better off you will be. The main value of learning design patterns is not how or when you use them, but in the way they establish a common language that people can use to describe somewhat complex designs and/or the intent behing a design in rather simple terms. Design patterns facilitate creating conceptual models of software constructs, thus they help explore ideas and communicate them with others while focusing on essential aspects and ignoring implementation details. For instance, at first glance the strategy pattern may be seen as a fancy word to describe inheritance, but mentioning inheritance says nothing about the intent of implementing algorithms as strategies. If, on the other hand, someone says that a component will be implemented based on a strategy pattern then it's already implicit that the designer expects that an algorithm should be exchangeable with ease and also that more versions could be added later without any trouble.

geezerjay 9y ago

> You can accomplish writing perfectly clean, readable, and maintainable projects that multiple people work on without learning any of the design patterns in that book. You will probably discover later that you were using certain patterns without knowing what they were called. The earlier you learn this, the better off you will be. The main value of learning design patterns is not how or when you use them, but in the way they establish a common language that people can use to describe somewhat complex designs and/or the intent behing a design in rather simple terms. Design patterns facilitate creating conceptual models of software constructs, thus they help explore ideas and communicate them with others while focusing on essential aspects and ignoring implementation details. For instance, at first glance the strategy pattern may be seen as a fancy word to describe inheritance, but mentioning inheritance says nothing about the intent of implementing algorithms as strategies. If, on the other hand, someone says that a component will be implemented based on a strategy pattern then it's already implicit that the designer expects that an algorithm should be exchangeable with ease and also that more versions could be added later without any trouble.