| Su | Mo | Tu | We | Th | Fr | Sa |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 |
Browse archives
Syndicate
Design Patterns Suck
Submitted by reeses on Sat, 2002-12-14 18:33.
Something about the fad of the past few years regarding design patterns has bothered me since I first read about them. I know my opinion is not new or original in any way, but I feel it must be stated, because this is my blog, and it's my duty to state tired opinions and beat dead horses.
In three words, Design Patterns Suck.
What does the body of structured programming teach you? If you do something more than once or twice, pull everything together into one procedure/function/library/module/macro and make calls into that mechanism, rather than replicating the code itself.
Why is it then, that we're teaching OOAD babies that patterns are a good thing?
"Hey, you're going to make your design, and you're going to say you need an adapter/bridge/facade/proxy/whatever here, so code one up!" Where "code one up" does not involve making a call into a procedure/function/library/module/macro.
Shouldn't we all be offended at the ease with which patterns have been thrust upon us, and our tools vendors' inability to provide us with language or even IDE support for most or all of at least the GoF patterns?
How about, in Java, language support for facades, an example I use because it's semantically simple and I'm too lazy to draw up something more:
package foo;
facade Persistence exposes Database, FileStore {
public FileInfo getFileInfo(long oid) -> Database.getFileInfo(long oid);
public FileData getFileData(long oid) -> FileStore.getFileData(long oid);
...
}
This would be the equivalent of writing a class with methods of the same name above, that make calls to the delegates mentioned above. In fact, this could be done with preprocessor support, or god forbid, real macro support. I don't know how sophisticated most of the freely available Java preprocessors are. I've written a few very simple ones, based on cpp rather than on something more advanced (eg., Lisp's macro system), but this particular example looks like a weekend project. Maybe I'll dink with a Java Design Pattern Generator and see what I can come up with.
Of course, we have much more complicated examples, in terms of abstract factories, etc., but we have to start somewhere. I think it should be a Bad Smell, though, when certain languages need a pattern (Visitor) that other languages do not. It's a sign of a deficiency in a language if you can't abstract very common behavior, that an entire industry acknowledges is common behavior.
delicious
digg
reddit
technoratiDesign Patterns do not suck, but their uninformed use certainly does. Most of the DP texts preach "The more patterns in your code, the better". This is knowledge without understanding. There is truth in the old statement "you can write bad code in any language" and you can produce bad designs using patterns. Knowing DP does not teach you how to design.
While many of the DP techniques are academically “cute”, I would not want to trouble shoot them.
Architecture Astronauts + Design Patterns = crypto-unmaintainable code.
Patterns are in my opinion a super-hyped thing. Most of the time, using DP only add lot of complexity to a solution that could have been very simply implemented using the very principles of OO languages: polymorphism and inheritance.
I honestly think that the problem with design patterns is that too much focus is given on reusability and extensibility, and this usually results in over-engineered architectures, which in the end do not evolve that much. KISS approach (or spartan approach if you prefer) gives usually smaller (and better) code, easily understandable by anybody and maintainable.
Quote from a Design Patterns prophet: "With patterns, you don't have to think of a solution anymore, you design the solution instead..."
It's called a Fad Pattern. Truth is, programmers have been using design patterns in unformalized ways since the beginning of software development. Nothing wrong (and actually a positive thing) that software development has reached a state where patterns have been recognized, classified, formalized, discussed, and now taught. A lot of code has been written with out formalized design patterns that does amazing things, and that code isn't "yukky" because it doesn't conform to the hip hop generation's definition of great code.
From your statements above, you really don't get design patterns. If you think that design patterns are "re-using" similar pieces or "patterns" of code, then you missed the point completely. I hope you didn't actually read Gang of Four, because if you did and that's all that you got out if it, you must've been banging your head against a wall for a LONG time.
When used in small specific code, OOD is good, when used all over, by fucking wanker geeks, who don’t have social lives, it sucks.
DP, I don't even wanna go there. When I write my software I get down to business and call the APIs as sequentally as possible, I am not wasting time with some mumbo jumbo design pattern invented by a guy in his useless phd thesis.
Get a life.