Do you think design patterns are academic nonsense, useless and elitist? If this is how you feel, the aim in this chapter is to show you the opposite, because nothing could be more wrong.Patterns can be very pragmatic, highly useful in day-to-day work, and extremely interesting to all (or at least most) developers. More here.
Also, in this chapter, author Anil Hemrajani provides you with an end-to-end approach to XP and AMDD-based architecture and design modeling using guidelines provided by Agile Model Driven Development and Extreme Programming. Learn how to develop a free-form architecture, explore objects using CRC cards, develop class and package diagrams for Time Expression, and much more.
… you can easily get trapped by a myriad of pattern logics and “rules” that you must follow.
In theory they are nice, but sometimes you have to simplify a little bit.
That said, DDD is a very nice concept and there are very good books about it.
Which boils down to using them properly, like anything else.
Anyone who thinks they are “nonsense”, “useless” or “elitist” is either too stupid to get it, or simply doesn’t know anything about programming and has little to no experience.
Sorry, that is rubbish. Design patterns came on to the scene about 4 years ago in earnest. Before they were on my radar, I was a perfectly capable programmer. After they arrived, ditto. They are a nice diversion, they can help with the basic design steps to solving a problem, but solutions don’t revolve around them. Been there, done that, don’t want to go there again. What a nightmare that was. Fascades with mediators. Iterators, visitors, singletons. Proxies over TCP/IP that implemented Observers. Every problem solved with a pattern. Every pattern causing a problem…
Anti Patterns are a good thing to know about too, by the way.
You missed my point. I didn’t say you can’t develop good software without them or they are required. Good job.
Oh and the best book on Design Patterns came out 12 years ago. That is when they really came on to the scene.
Keep It Simple Stupid
😉
Exactly … I have become very very sick of working on projects that massively overuse patterns for absolutely no reason other than to make things way more complex than they need to be.
Design patterns have become an easy way to look clever in interviews, without having the slightest grasp of how to put a quality app together.
I spend a large amount of my time ripping out poorly implemented patterns at work so that our code is actually *readable*. Patterns are great when used properly to solve certain problems. But they can be seriously misused.
Even then, I think the most useful thing I’ve learned recently is about dependency injection. It makes it soooo much easier to test if you’ve written code where you inject all of your dependencies instead of relying on singletons or factories.
I prefer the phrase “Keep It Stupidly Simple”
…when you want to work around the rigidity of object-oriented programming for certain tasks.
It would be really bad to sometimes break the “everything is object-oriented” dogma in order to have a simple design
It reminds me of “modern” C++ programmers who think it’s funny and clever (well, it is) to abuse every feature of C++ to emulate features available in better languages (template metaprogramming, blasphemous uses of operator overloading, etc.)
It reminds me of “modern” C++ programmers who think it’s funny and clever (well, it is) to abuse every feature of C++ to emulate features available in better languages (template metaprogramming, blasphemous uses of operator overloading, etc.)
Exactly. Everybody knows that those features of C++ aren’t actually there to be used. They’re just there to play around with in hobby projects.
The only feature C++ has which is worthwhile is to allow declaration close to use instead of only at the beginning of a scope, right?
For the rest, just implement one part of your project in Haskell, another in ML, a small bit if Perl for the nice regex stuff, bolt in a Javascript interpreter for easy prototyping, some VB, a bit of Java for the nice OO there, and with contract enforcement layers in Eiffel (oh and the performance critical parts in assembly, of course).
Using a single language which tries hard to be multi-paradigm is just funny and clever.
In my day, when I was a programmer, we had functions, subroutines, data structures, algorithms and techniques. Today, we have “methods”, “classes” and “patterns”. Same stuff, different lingo.