4 ms·

" 99% of the design problems you'll encounter have been encountered before and are probably cataloged. " Bonus: It's already been done! http://en.wikipedia.or

by cop359 15y ago

" 99% of the design problems you'll encounter have been encountered before and are probably cataloged. " Bonus: It's already been done! http://en.wikipedia.org/wiki/Design_Patterns_(book) http://en.wikipedia.org/wiki/Design_Patterns_(book) I heard that when they wrote the book they basically mailed a whole bunch of people in the field to find out all the patterns people were using and they weren't able to find more then 23. After getting 23 every other pattern they would hear about would be just an iteration of one of the ones they had. Full Disclosure: I haven't actually read the book yet. But I'm planning to...

mattmanser 15y ago
Have you read this recently? It impressed me 4 years ago, now I honestly think it's a relic of a bygone era. Language advances, different API design and dynamic programming and anonymous functions have got rid of a lot of the problems that you actually had to do these shitty patterns for. UML also sucks and is dead, again, not sure why anyone would bother with it. When is the last time you saw a UML article or GoF article on HN? Wake up, they're both dead concepts. I'm not even sure why patterns have died, they just have. Probably because people just program that way now anyway. Yes, they were useful, but they're not needed any more. People don't write code like that any more because they don't really have to.
- davesims 15y ago
  Maybe it's that patterns are so common place we take for granted that someone had to name them. I guarantee you've used Proxy, Observer, Factory, Abstract Factory, Facade, Bridge or some approximation of one of these if you've coded more than 100 lines of Java in the last year. If I say "ActiveRecord" or "DataMapper" you probably think Ruby on Rails, not Chapter 10 of Patterns of Enterprise Application Architecture. If I say "Factory" you're probably not thinking Chapter 3 of GOF. When you think about node.js or EventMachine, do you think about the definition of the Reactor Pattern in POSA Volume 2? Patterns aren't dead. They won.
  - gambler 15y ago
    There is a fundamental problem with Deign Patterns: the knowledge and effort required to apply them appropriately vastly exceeds the knowledge necessary to effortlessly re-create them on the spot.
  - paganel 15y ago
    > If I say "Factory" you're probably not thinking Chapter 3 of GOF Honest question, what does this pattern accomplish? I'm asking this because I just saw a bunch of Factory-like classes in some PHP code I was trying to port to Python, and for the life of me I couldn't understand why the original programmer had made it so complicated and convoluted, when he could have done it all in 30 lines of code. And a second question for whoever might have the free time to answer it: does anybody actively use inheritance (or, why not, multiple inheritance) on a daily basis and in the same time do they feel like it helps them? (as in: does the size of their code base gets significantly smaller? does the code fits better in one's head? things like that).
    - davesims 15y ago
      A Factory is used to create an object of a specific type, when the calling code only has a reference to a supertype or prefereably an abstract type of that object. This reduces coupling and therefore side-effects in your code. For instance: Car car = CarFactory.newCar(someLocalContext); Might return a specific type of car for the given context, but the calling code's coupling is only to the supertype Car, and therefore can operate in the same way on any kind of Car. Since php is dynamically typed there's not as much reason to use this pattern, although in certain cases it might be the right choice. The Factories in question might actually be more like Builders -- classes used to hide complex construction processes. I use inheritance all the time in Ruby and Java these days. With Ruby you get Modules and the Mixin approach, which allows for what is essentially multiple inheritance. I try to keep the level of inheritance close to 1 (I can't remember the last time I went past that) but yes, it's an essential tool in the toolkit. I'm apparently one of the last coders on earth that still uses UML, but I find it helps me clarify architectures and visualize my code. OOP was meant to be visual in nature -- object relationships are, imho, best understood visually rather than through linear code. My suggestion would be to get used to UML or some hacked derivative thereof and express your dependencies visually, and you may find inheritance starts to make more sense.
davesims 15y ago
Sure, not only the GOF, but 5 volumes of POSA, Martin Fowler's POEAA, and reams of digested pattern books like Head First Design Patterns, etc. There's dozens.

by cop359 15y ago

mattmanser 15y ago

Have you read this recently? It impressed me 4 years ago, now I honestly think it's a relic of a bygone era. Language advances, different API design and dynamic programming and anonymous functions have got rid of a lot of the problems that you actually had to do these shitty patterns for. UML also sucks and is dead, again, not sure why anyone would bother with it. When is the last time you saw a UML article or GoF article on HN? Wake up, they're both dead concepts. I'm not even sure why patterns have died, they just have. Probably because people just program that way now anyway. Yes, they were useful, but they're not needed any more. People don't write code like that any more because they don't really have to.

davesims 15y ago
Maybe it's that patterns are so common place we take for granted that someone had to name them. I guarantee you've used Proxy, Observer, Factory, Abstract Factory, Facade, Bridge or some approximation of one of these if you've coded more than 100 lines of Java in the last year. If I say "ActiveRecord" or "DataMapper" you probably think Ruby on Rails, not Chapter 10 of Patterns of Enterprise Application Architecture. If I say "Factory" you're probably not thinking Chapter 3 of GOF. When you think about node.js or EventMachine, do you think about the definition of the Reactor Pattern in POSA Volume 2? Patterns aren't dead. They won.
- gambler 15y ago
  There is a fundamental problem with Deign Patterns: the knowledge and effort required to apply them appropriately vastly exceeds the knowledge necessary to effortlessly re-create them on the spot.
- paganel 15y ago
  > If I say "Factory" you're probably not thinking Chapter 3 of GOF Honest question, what does this pattern accomplish? I'm asking this because I just saw a bunch of Factory-like classes in some PHP code I was trying to port to Python, and for the life of me I couldn't understand why the original programmer had made it so complicated and convoluted, when he could have done it all in 30 lines of code. And a second question for whoever might have the free time to answer it: does anybody actively use inheritance (or, why not, multiple inheritance) on a daily basis and in the same time do they feel like it helps them? (as in: does the size of their code base gets significantly smaller? does the code fits better in one's head? things like that).
  - davesims 15y ago
    A Factory is used to create an object of a specific type, when the calling code only has a reference to a supertype or prefereably an abstract type of that object. This reduces coupling and therefore side-effects in your code. For instance: Car car = CarFactory.newCar(someLocalContext); Might return a specific type of car for the given context, but the calling code's coupling is only to the supertype Car, and therefore can operate in the same way on any kind of Car. Since php is dynamically typed there's not as much reason to use this pattern, although in certain cases it might be the right choice. The Factories in question might actually be more like Builders -- classes used to hide complex construction processes. I use inheritance all the time in Ruby and Java these days. With Ruby you get Modules and the Mixin approach, which allows for what is essentially multiple inheritance. I try to keep the level of inheritance close to 1 (I can't remember the last time I went past that) but yes, it's an essential tool in the toolkit. I'm apparently one of the last coders on earth that still uses UML, but I find it helps me clarify architectures and visualize my code. OOP was meant to be visual in nature -- object relationships are, imho, best understood visually rather than through linear code. My suggestion would be to get used to UML or some hacked derivative thereof and express your dependencies visually, and you may find inheritance starts to make more sense.

davesims 15y ago

Sure, not only the GOF, but 5 volumes of POSA, Martin Fowler's POEAA, and reams of digested pattern books like Head First Design Patterns, etc. There's dozens.