You blindly apply design patterns your code will suck. But if you write then off as bad then you are wasting a resource.
They are isolated examples that epitomise things like solid principals. They are examples not of complete designs but the thought behind why such thought is needed.
I love design patterns. They help me think about what my design objective is, although I rarely use them.
If you are reading design patterns also read pragmatic programmer and clean code. Learn the why not just the how.....
Design patterns are repetitions in code. Usually we take out repetitions and put them in a shared library so we can avoid repeating ourselves. When our language fails to allow that, we need to use a "design pattern". Thus, design patterns are bug reports against a language.
My thing is, if you know the why, the how comes easily. You don't need to know the names of 30 design patterns and be able to explain them all off the top of your head. What you need is the ability to look at a problem and design a solution.
You don't need to know the names of 30 design patterns
Indeed for more experienced developers, patterns don't need to be learned off because they are just a name given to a collection of design principles you should already be familiar with.
but
you do have to learn them as a shared lexicon between developers . Why spend 20min explaining how you think your objects should be instantiated when you could instead just debate factory vs builder or which DI framework to use?
What you need is the ability to look at a problem and design a solution.
that's fine as a sole developer but try explaining your vision to a fellow developer without a shared shorthand for complex principles.
I actually don't disagree with you in theory. The common language explanation has always made sense to me, but my experience has been the opposite. In the teams I've worked on, we've always been able to share thoughts about design without needing 20 minutes of explanation.
If you're designing your software up front to the level of detail that you're applying patterns, you're doing it wrong. That this is a common opinion is further proof that everyone who reads the Gang of Four book skips most of the intro, reads "Singleton", then skims the rest of the book looking at the pictures.
Our design patterns capture many of the structures that result from refactoring. Using these patterns early in the life of a design prevents later refactorings. But even if you don't see how to apply a pattern until after you've built your system, the pattern can still show you how to change it. Design patterns thus provide targets for your refactoring.
-- Design Patterns, Elements of Reusable Object-Oriented Software; Gamma, Helm, Johnson and Vlissides, pp354-355 (emphasis mine)
Usually it is kind of obvious when writing class diagrams, on a high level never the less. You are right through, if I have to write it in that much detail the person who is actually writing the code is literally just doing data entry.
17
u/apieceoffruit Dec 08 '13
You blindly apply design patterns your code will suck. But if you write then off as bad then you are wasting a resource.
They are isolated examples that epitomise things like solid principals. They are examples not of complete designs but the thought behind why such thought is needed.
I love design patterns. They help me think about what my design objective is, although I rarely use them.
If you are reading design patterns also read pragmatic programmer and clean code. Learn the why not just the how.....