Hacker News Reader

Comment by cop359 | Hacker News Reader

" 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)

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...

View on HN

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.

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.

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.

> 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).

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.

Perhaps it's just a difference in styles, I avoid inheritance like the plague. To me something has to be really, really special to inherit off another class that I've written.

And even then I'll come back to it the next day and see if I can get rid of it or it really does still make sense.

Factory classes make less sense in a language with first class functions, but Factory functions are handy sometimes. As you can see in this example of a Factory function in Python from the standard library[1], it can be useful to return different subclasses depending on the arguments, but it doesn't have to be heavyweight like in Java.

[1]: http://docs.python.org/library/collections.html#collections....

The factory pattern exists to create jobs and products. Whether anyone wants or needs either is yet to be determined.

if you've coded more than 100 lines of Java in the last year.

That's just it. If you're a regular here, you're less likely than the average programmer to have done that, and it's probably not really the code you want to talk about if you have. Java isn't especially popular for personal projects, startups or most other things people want to talk about or show off here.

Given some combination of first-class functions, various metaprogramming capabilities, dynamic typing and paradigms other than class-based OO, many of these patters disappear.

Sure, and a lot of them get codified and built in to HN-friendly frameworks -- again node.js, EventMachine, ActiveRecord, DataMapper...

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.

Reply on news.ycombinator.com