Right now I'm reading Design Patterns and Best Practices in Java by Kamalmeet Singh, Adrian Ianculescu and Lucian-Paul Torje, a very good book that explains the multitude of design patterns that the Java language has and some best practices in Java. During development I'm already used to identify opportunities and use creational patterns such as Singleton, Factory and Builder. However, I never really read a book listing design patterns like that, which was always a point of worry for me as a developer and I'm trying to fix that now to evolve even more in my development skills.
However, advancing through the reading one question arose, principally regarding the behavioral patterns I'm reading right now. The book is very clear in the explanation of what the patterns do, examples and applicability, but there is the old saying: "it is easier said than done". In my opinion it should feel natural, you cannot write code trying to find excuses to use X or Y design pattern. How developers develop this kind of habit? How they know that, looking to a problem, that they should use, for example, observer pattern or mediator pattern, without resorting to a book to remember their use cases? Is it just a matter of experience? How to gain experience without falling into excessive use of patterns?
My familiarity with creational patterns comes from its solid use in Java itself and many famous libraries, I saw that they were convenient and started to use them myself. However, creational patterns are much more concrete and easily identifiable than behavioral patterns. It sounds hard to do the same natural process that I did with creational patterns.
What did you people do to make it natural, if anything at all? Should I worry about it that much? What are the most important patterns that you think it is necessary to know to apply on the fly? I'm looking forward to your points of view in this subject that are always in vogue in the development community. :)
Top comments (6)
Design patterns are written as abstract solutions to abstract problems. In order for you to start using them naturally you need to think of your specific requirements in abstract terms. Rather than start coding right away think about what the core components of your problem are and with experience you'll find that the right design pattern often just pops into your head as the approach.
Use this approach when discussing problems with your colleagues and you may be surprised how much you start 'name dropping' patterns as you talk. Where I work it's considered normal too say stuff like "so I used the Strategy pattern" or "I think the Command pattern is a good fit for that".
Personally I think people put to much stock in Design Patterns as a teaching tool. Before I moved away from OOP a few years ago, I was really big on design patterns, but not for teaching, for communication.
If you code for years and years chances are you have unknowingly implemented just about all patterns. Many experiences I have had when describing a pattern to either an individual or a group, just about every time they will respond with "Oh yeah, I do that all the time" and my canned response to that is, "Awesome, well now you have a name for it"
Because of years and years of this, I switched my motivation of teaching them from:
to:
For instance I could provide a dev with complicated flow/class diagrams and waste everybody's time in a protracted design meeting to describe how we could approach a challenge.
OR I can make a statement like "Well, this could be a
Directorusing aCompositeon the Manifest.Just my 2-cents
EDIT: oh I see @simonhaisz already posted something along these lines.
I would say it depends on experience with patterns. When you first learn them, trying to design with patterns can easily bias you to implementing one when perhaps the problem could be solved more simply. And usually patterns have some variation in how they can be implemented. For example, Producer/Consumer should use different concurrency controls for different usage situations.
I definitely do not believe that using pre-packaged design patterns like lego blocks to build software is a good idea. I think this often ends up with over-engineered and hard-to-maintain software. Largely because it leads you to focus on the technical aspects of the implementation, which are generally less important than making sure that your user's problem is really solved.
I usually find that implementing a solution in the simplest way I know how is the best choice. That includes choosing a path which makes bad states and edge cases unlikely or impossible. Sometime during/after the implementation, I might realize that I ended up using a design pattern. And then comparing what I did to the pattern might help to refine the solution even further.
In the longer term, you might start to recognize some implementation problems as fitting a design pattern very well. But do not put too much stock in it. Sometimes, it only takes a quick email from a customer to change requirements. If you get stuck on the idea of implementing the pattern, your brain will filter out contrary details. I have made this mistake before, which resulted in not delivering what the customer really wanted.
And lastly, one thing that patterns can do is allow you to efficiently communicate your solutions to others. Saying Producer/Consumer is a lot faster than describing how that works. However, this depends on the other party being familiar with the pattern. When the other party is not familiar with it, then it ends up taking longer to explain it. Because now there are two new ideas they have to conceptualize: 1) the pattern and 2) your software's usage of it to solve the problem. Whereas they just wanted to know 1) how your software solves the problem. I usually ask first if they are aware of the pattern I want to mention. If not, I proceed to explain the solution first, then point out how the pattern fits in.
Anyway, I really like the idea of design patterns, but I find them difficult to use prescriptively. It's more like an animal classification... it is not easy to predict what classifications you will see when walking through strange woods. But once you get back to camp, you can tell everyone about the Danaus plexippus (monarch butterfly) that you did observe.
Thank you for the reply, I think it was longer than my post! hahaha
Yeah, you are right, with the ever changing environment we live in as developers, we generally don't have much time to think about the best way to implement right off the bat and if we try to apply patterns in everything it ends getting in way more than helping. I will follow your suggestion in trying to make design patterns as part of my code improvement stage, I already do that with the creational patterns, that are the ones I'm more used to like I said in the text.
I was programming for a few years - self taught mostly - before I learned that design patterns were even a thing. When I found out about them, by and large they fell into two categories. First was "oh wow new shiny!" - things I thought were cool and could see uses for. The other category was "wow I've already been using this, what's special about it?"
Personally I tend to overuse ideas - the hammer analogy someone else here commented about - and I did that quite a bit with patterns when I first learned them. I think that's okay as long as you have the awareness after the fact (or better yet, during!) to realize "hey, you know, I really didn't need to go all out and make a full-on adapter for this when I could've just done blargh."
Eventually you'll get to a point where it's a natural choice based on the code base and the needs of your project. But you'll have to spend a good chunk of time over using and under using them to get there.
You know, every time I read something about Design Patterns and I end up reading about a specific pattern and I laugh, because I can recall all the times I've used that pattern before without even knowing the official name for it.
This isn't a problem for me as I've done most of my development work as a solo developer, but communicating a certain approach to a problem can be made simpler by knowing the official name. Makes sense.
Now please, don't decide you're going to use pattern A, B, C, X and Y, and then start thinking about the problem you're trying to solve, because you might just end up building a marvellous monstrosity versus a natural approach that, where afterwards you say, "Oh cool, I used Pattern C".
This way, the situation dictates the exact solution.