15 ms·

Ah, the good old Design Patterns book, responsible for more atrocious over-abstracted, unreadable, hard to maintain Java code than anything else before or since

Ah, the good old Design Patterns book, responsible for more atrocious over-abstracted, unreadable, hard to maintain Java code than anything else before or since.

k__ 10y ago
Not only Java... But I guess the Problem is how OOP is teached. Before I learned about design patterns I only saw car or animal examples. Design patterns were the first real world OOP stuff I saw at university.
- gt2 10y ago
  Out of curiosity how long ago were you at university?
  - pjmlp 10y ago
    Not the OP, but to provide an idea how it used to be. I learned OOP with Turbo Pascal 5.5, for MS-DOS, around 1990. Started using Turbo Vision with Turbo Pascal 6.0. Eventually also started coding with Object Windows Library in Turbo Pascal and Turbo C++. Borland manuals were my introduction to OOP, followed by books like "Designing Object-Oriented C++ Applications using the Booch Method.". Only later I got to learn about the multiple ways of doing OOP (CLOS, Beta, SELF, ...).
    - k__ 10y ago
      Yes. I mean, I did OOP in some languages, because, well, they had object like constructs. For example VBA had all these Excel tables modeled as objects you could access and modify via code. Then there was C++ and Java with their factories and factory factories and whatnot. And lastly the examples of cars that have wheels and animals that inherited stuff etc. pp. So I had different concepts in my mind, all being objects. On the one hand the examples of university. On the other hand the tangible Excel table of VBA that I understood. "At table is an object with some methods and properties" And then the "real programmer stuff" like a controller, a presenter, a singleton, a emitter... Things that were really abstract to me, because they didn't map directly to tangible things I saw in the software as a user. Design patterns somehow made this more easy to grasp. But I first started to understand the whole thing after building my own API in PHP (started after it got classes haha) that had module- (controllers), protocol- (views) and data-objects (models).
  - k__ 10y ago
    I studied my BSc from 2007 - 2011
gnufied 10y ago
Careful there - lest you throw the baby with the water. As with all things - there are some good ideas there and some bad. And as I understand it, the book simply presented patterns - programmers were already using at that time. So the book's existence in itself wouldn't cause bad code IMO. Now if someone were to write a "modern design patterns" book, people will probably write about: 1. Actor pattern and concurrency using message passing. 2. Immutability and - designing types with no shared mutable state. 3. Dependency injection 4. Pattern matching 5. MVC 6. mocks and stubs and fake objects? 7. ... And same as before - some of these ideas when applied to certain cases could be bad.
- runako 10y ago
  > "if someone were to write a "modern design patterns" book" Based on my recollection of the original Design Patterns book, all of the patterns you list are included in the original book. Caveat: I haven't opened the book in over 5 years, but I'd be surprised to learn that any of the 6 patterns you list are not in the original DP.
  - gnufied 10y ago
    What i listed was just an example but you can verify quickly - https://www.amazon.com/dp/0201633612/?tag=devbookscom20-20 https://www.amazon.com/dp/0201633612/?tag=devbookscom20-20 without opening the actual book. And afaict - none of the patterns I listed are mentioned verbatim.
    - laxd 10y ago
      Seems like MVC is treated in GoF. http://blog.iandavis.com/2008/12/what-are-the-benefits-of-mvc/ http://blog.iandavis.com/2008/12/what-are-the-benefits-of-mv...
      - munificent 10y ago
        It talks a little about it, but it's not called out as a specific pattern with a chapter all its own.
amelius 10y ago
You forgot to wrap your comment in a Factory class.
- metaobject 10y ago
  Why stop there? Why not a CommentFactoryFactory?
  - clock_tower 10y ago
    After all, software factories give you interchangeable parts, and let you reuse your code wherever you want!
  - hinkley 10y ago
    Head over to github and search for Enterprise FizzBuzz. That'll keep you busy cringing or laughing or both for a while.
JimDabell 10y ago
I don't think that's fair. The driving point of that book was that developers needed a higher level language to talk about these patterns than simply at the code level, and showed people how to put together a vocabulary. Yes, it came with a library of sample patterns useful for Java developers, but they weren't egregious examples, nor were they the main point of the book. They were just taken to an extreme by people who skipped over the first part of the book and just skimmed the library. It was a "how to think about your craft" book that people misread as a "how to achieve a programming task" book.
- oselhn 10y ago
  This book was written before Java for C++ developers (amazon shows 1994). Edit: I agree with your opinion. Just wanted to show that this problem is much older and related to other languages too (probably with the similar OOP implementation).
  - esfandia 10y ago
    The book has examples in both C++ and Smalltalk.
- DonaldFisk 10y ago
  That's very interesting. I haven't read Design Patterns. I have read A Pattern Language, and the Timeless Way of Building, by Christopher Alexander, and Patterns of Software by Richard Gabriel. It's been my understanding that Design Patterns had only a couple of dozen patterns (which turn up again and again in Java code) and prescribed their use generally, but if they're only examples of patterns, and programmers are encouraged to invent their own (which I do anyway), it might be worth a read.
  - the_af 10y ago
    GoF's Design Patterns, for all its flaws, was never intended as a prescription or even as an exhaustive description of every design pattern. It was a recording of commonly used and battle-tested patterns. I think the motivation was good; the bad thing was that it became some sort of bible to be followed blindly. I don't think that was the intention of the authors, though.
jasode 10y ago
>, the good old Design Patterns book, responsible for more atrocious over-abstracted, This is a misunderstanding of the DP book. It would be similar to saying that the existence of TVTropes.com is responsible for terrible scripts of tv shows and movies. Or, the existence of the Oxford English Dictionary is responsible for bad novels and useless documentation. The DP book is a catalog (to gain awareness) and not a checklist (that you must do). It's a collection of observations about software structures out in the wild. It's not about prescription. Even without the phrase "design patterns", it's easy to surmise that programmers out there are independently and unknowingly re-inventing the same higher-level structures (similar to tv tropes) but without giving them formal names. The DP book gives them formal names and hence, an attempt at shared vocabulary. One can go to the amazon.com page for Design Patterns and click "Look inside" for the "First Pages" and see that the authors wanted to present a catalog: https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...
- dragonwriter 10y ago
  > >, the good old Design Patterns book, responsible for more atrocious over-abstracted, > This is a misunderstanding of the DP book. It is discussing an effect of the book, not the intent. > It would be similar to saying that the existence of TVTropes.com is responsible for terrible scripts of tv shows and movies. Which would be entirely accurate if script writers were widely using TVTropes pages as templates and creating bad scripts from it, regardless of what TVTropes is intended to be.
  - jasode 10y ago
    >It is discussing an effect of the book, not the intent. Do you truly believe that specific DP book caused that effect? I don't. The DP book is extremely dry reading and most programmers have not actually read it. ([In terms of readership/ownership ratio] It's a book like Stephen Hawking's "Brief History of Time" ... everybody knows about it and some might have it on the coffee table but very few actually read it.) I do think the _phrase_ of "design patterns" (not the book) has become a sort of gravitational force such that any discussion about "overcomplicated design" seems to fall toward that particular phrase. Or put differently, "bad designs" is now a synonym of "design patterns" so much so such that you can't even say "design pattern" and have it be interpreted as a neutral term. It's become a trigger word. >Which would be entirely accurate if script writers were widely using TVTropes pages as templates and creating bad scripts Yes, I agree that would be equivalent. However, I don't think the existence of tvtropes compels directors like Michael Bay to repeat the "walk away calmly from explosion in the background" scene. The motivation to repeat that "cinematic pattern" comes from somewhere else. Likewise, the majority of bad/overcomplicated abstractions in source code come from somewhere else besides that particular DP book.
criddell 10y ago
I don't think that's fair. The patterns already existed, they just created a taxonomy and added editorial. I think it's one of my favorite programming books. Everybody independently created singletons and factories and builders, we just all called them different things.
pmcl 10y ago
Couldn't agree more. Lol
munificent 10y ago
> responsible for more atrocious over-abstracted, unreadable, hard to maintain Java code I have the misfortune to remember what some object-oriented codebases looked like before "Design Patterns". While people—generally those who haven't read the book or completely glossed over the section on the consequences of each pattern—have certainly over-used design patterns, I'll still take that over under-use of them. An over-engineered too-many-design-patterns codebase is annoying and tedious. A hundred thousand lines of code filled with half-way-reinvented design patterns with its own made up terminology, hard coupling everywhere, piles of global state, and no real architecture to speak of at all is a nightmare.
- black2 10y ago
  It's all in my phone. I read it all.I NEVER GAVE PERMISSION for this to be placed on my Android I decided to look one of the 50or so things like this on my phone.. I never had e permission j believe i can tell you what state and what address this man is doing this from!
donovanm 10y ago
I feel like it probably did more good then bad. Codebases devoid of any design patterns arent likely great quality. But it requires judgement to not over engineer.

Ah, the good old Design Patterns book, responsible for more atrocious over-abstracted, unreadable, hard to maintain Java code than anything else before or since.

k__ 10y ago

Not only Java... But I guess the Problem is how OOP is teached. Before I learned about design patterns I only saw car or animal examples. Design patterns were the first real world OOP stuff I saw at university.

gt2 10y ago
Out of curiosity how long ago were you at university?
- pjmlp 10y ago
  Not the OP, but to provide an idea how it used to be. I learned OOP with Turbo Pascal 5.5, for MS-DOS, around 1990. Started using Turbo Vision with Turbo Pascal 6.0. Eventually also started coding with Object Windows Library in Turbo Pascal and Turbo C++. Borland manuals were my introduction to OOP, followed by books like "Designing Object-Oriented C++ Applications using the Booch Method.". Only later I got to learn about the multiple ways of doing OOP (CLOS, Beta, SELF, ...).
  - k__ 10y ago
    Yes. I mean, I did OOP in some languages, because, well, they had object like constructs. For example VBA had all these Excel tables modeled as objects you could access and modify via code. Then there was C++ and Java with their factories and factory factories and whatnot. And lastly the examples of cars that have wheels and animals that inherited stuff etc. pp. So I had different concepts in my mind, all being objects. On the one hand the examples of university. On the other hand the tangible Excel table of VBA that I understood. "At table is an object with some methods and properties" And then the "real programmer stuff" like a controller, a presenter, a singleton, a emitter... Things that were really abstract to me, because they didn't map directly to tangible things I saw in the software as a user. Design patterns somehow made this more easy to grasp. But I first started to understand the whole thing after building my own API in PHP (started after it got classes haha) that had module- (controllers), protocol- (views) and data-objects (models).
- k__ 10y ago
  I studied my BSc from 2007 - 2011

gnufied 10y ago

Careful there - lest you throw the baby with the water. As with all things - there are some good ideas there and some bad. And as I understand it, the book simply presented patterns - programmers were already using at that time. So the book's existence in itself wouldn't cause bad code IMO. Now if someone were to write a "modern design patterns" book, people will probably write about: 1. Actor pattern and concurrency using message passing. 2. Immutability and - designing types with no shared mutable state. 3. Dependency injection 4. Pattern matching 5. MVC 6. mocks and stubs and fake objects? 7. ... And same as before - some of these ideas when applied to certain cases could be bad.

runako 10y ago
> "if someone were to write a "modern design patterns" book" Based on my recollection of the original Design Patterns book, all of the patterns you list are included in the original book. Caveat: I haven't opened the book in over 5 years, but I'd be surprised to learn that any of the 6 patterns you list are not in the original DP.
- gnufied 10y ago
  What i listed was just an example but you can verify quickly - https://www.amazon.com/dp/0201633612/?tag=devbookscom20-20 https://www.amazon.com/dp/0201633612/?tag=devbookscom20-20 without opening the actual book. And afaict - none of the patterns I listed are mentioned verbatim.
  - laxd 10y ago
    Seems like MVC is treated in GoF. http://blog.iandavis.com/2008/12/what-are-the-benefits-of-mvc/ http://blog.iandavis.com/2008/12/what-are-the-benefits-of-mv...
    - munificent 10y ago
      It talks a little about it, but it's not called out as a specific pattern with a chapter all its own.

amelius 10y ago

You forgot to wrap your comment in a Factory class.

metaobject 10y ago
Why stop there? Why not a CommentFactoryFactory?
- clock_tower 10y ago
  After all, software factories give you interchangeable parts, and let you reuse your code wherever you want!
- hinkley 10y ago
  Head over to github and search for Enterprise FizzBuzz. That'll keep you busy cringing or laughing or both for a while.

JimDabell 10y ago

I don't think that's fair. The driving point of that book was that developers needed a higher level language to talk about these patterns than simply at the code level, and showed people how to put together a vocabulary. Yes, it came with a library of sample patterns useful for Java developers, but they weren't egregious examples, nor were they the main point of the book. They were just taken to an extreme by people who skipped over the first part of the book and just skimmed the library. It was a "how to think about your craft" book that people misread as a "how to achieve a programming task" book.

oselhn 10y ago
This book was written before Java for C++ developers (amazon shows 1994). Edit: I agree with your opinion. Just wanted to show that this problem is much older and related to other languages too (probably with the similar OOP implementation).
- esfandia 10y ago
  The book has examples in both C++ and Smalltalk.
DonaldFisk 10y ago
That's very interesting. I haven't read Design Patterns. I have read A Pattern Language, and the Timeless Way of Building, by Christopher Alexander, and Patterns of Software by Richard Gabriel. It's been my understanding that Design Patterns had only a couple of dozen patterns (which turn up again and again in Java code) and prescribed their use generally, but if they're only examples of patterns, and programmers are encouraged to invent their own (which I do anyway), it might be worth a read.
- the_af 10y ago
  GoF's Design Patterns, for all its flaws, was never intended as a prescription or even as an exhaustive description of every design pattern. It was a recording of commonly used and battle-tested patterns. I think the motivation was good; the bad thing was that it became some sort of bible to be followed blindly. I don't think that was the intention of the authors, though.

jasode 10y ago

>, the good old Design Patterns book, responsible for more atrocious over-abstracted, This is a misunderstanding of the DP book. It would be similar to saying that the existence of TVTropes.com is responsible for terrible scripts of tv shows and movies. Or, the existence of the Oxford English Dictionary is responsible for bad novels and useless documentation. The DP book is a catalog (to gain awareness) and not a checklist (that you must do). It's a collection of observations about software structures out in the wild. It's not about prescription. Even without the phrase "design patterns", it's easy to surmise that programmers out there are independently and unknowingly re-inventing the same higher-level structures (similar to tv tropes) but without giving them formal names. The DP book gives them formal names and hence, an attempt at shared vocabulary. One can go to the amazon.com page for Design Patterns and click "Look inside" for the "First Pages" and see that the authors wanted to present a catalog: https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...

dragonwriter 10y ago
> >, the good old Design Patterns book, responsible for more atrocious over-abstracted, > This is a misunderstanding of the DP book. It is discussing an effect of the book, not the intent. > It would be similar to saying that the existence of TVTropes.com is responsible for terrible scripts of tv shows and movies. Which would be entirely accurate if script writers were widely using TVTropes pages as templates and creating bad scripts from it, regardless of what TVTropes is intended to be.
- jasode 10y ago
  >It is discussing an effect of the book, not the intent. Do you truly believe that specific DP book caused that effect? I don't. The DP book is extremely dry reading and most programmers have not actually read it. ([In terms of readership/ownership ratio] It's a book like Stephen Hawking's "Brief History of Time" ... everybody knows about it and some might have it on the coffee table but very few actually read it.) I do think the _phrase_ of "design patterns" (not the book) has become a sort of gravitational force such that any discussion about "overcomplicated design" seems to fall toward that particular phrase. Or put differently, "bad designs" is now a synonym of "design patterns" so much so such that you can't even say "design pattern" and have it be interpreted as a neutral term. It's become a trigger word. >Which would be entirely accurate if script writers were widely using TVTropes pages as templates and creating bad scripts Yes, I agree that would be equivalent. However, I don't think the existence of tvtropes compels directors like Michael Bay to repeat the "walk away calmly from explosion in the background" scene. The motivation to repeat that "cinematic pattern" comes from somewhere else. Likewise, the majority of bad/overcomplicated abstractions in source code come from somewhere else besides that particular DP book.

criddell 10y ago

I don't think that's fair. The patterns already existed, they just created a taxonomy and added editorial. I think it's one of my favorite programming books. Everybody independently created singletons and factories and builders, we just all called them different things.

pmcl 10y ago

Couldn't agree more. Lol

munificent 10y ago

> responsible for more atrocious over-abstracted, unreadable, hard to maintain Java code I have the misfortune to remember what some object-oriented codebases looked like before "Design Patterns". While people—generally those who haven't read the book or completely glossed over the section on the consequences of each pattern—have certainly over-used design patterns, I'll still take that over under-use of them. An over-engineered too-many-design-patterns codebase is annoying and tedious. A hundred thousand lines of code filled with half-way-reinvented design patterns with its own made up terminology, hard coupling everywhere, piles of global state, and no real architecture to speak of at all is a nightmare.

black2 10y ago
It's all in my phone. I read it all.I NEVER GAVE PERMISSION for this to be placed on my Android I decided to look one of the 50or so things like this on my phone.. I never had e permission j believe i can tell you what state and what address this man is doing this from!

donovanm 10y ago

I feel like it probably did more good then bad. Codebases devoid of any design patterns arent likely great quality. But it requires judgement to not over engineer.