Post a Comment
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.
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.
...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.



