Martin Fowler has written up a really nice piece on his OOPSLA experience.

He starts off by discussing the Gang of Four Design Patterns book. There was a 'vote off the island' session which kicked off Factory Method (due to the confusion over what it means - the pattern is different to the more common usage of the term), Bridge, Flyweight, and Interpreter. Two patterns, Singleton and Chain of Responsibility, were split decisions.

What would you change from that great book?

Read more: Martin's OOPSLA 2004

I wont comment on voting off.. however with regards to the Singletons.. I would think "Dependency Injection" would be a nice inclusion :)

what is wrong with Flyweight?

what is wrong with Flyweight?

According to the article:

Most of the others were voted off because people felt they were sufficiently uncommon and that other patterns would probably take their place

Personally, I've used flyweight several times, and it's indispensable when you need it. I don't know what could possibly replace it.

God bless,
-Toby Reyelts

Hmmm... I think people are becoming too pedantic here.

First of all, the arguement about Flyweight being "sufficiently uncommon" is absolute nonsense. It's probably the most important pattern ever recognized. You only work with it several dozen times everyday. I guess everyone forgot that Servlets, Struts Actions, and JSPs (if they are designated as thread-safe) are all Flyweights. One of the great things about J2EE is that web-tier components are Flyweights and not a new instance of an page/controller for every HTTP request. Without Flyweights, memory usage becomes linear under load. If they wanted to get rid of something, why not get rid of Prototype since Java handles this for you anyway?

Also, if you can't understand the purpose or function of a factory method, You probably shouldn't be writing software IMHO.

I agree, atleast on Factory method. I think people who voted it off never developed one not because they didn't wanted but I think they get around with open source products. They might have thought if its available, why bother develop? I am surprised as Fowler that singleton got away with split decision. Because many times Singleton is over used.

Virtually every design pattern that utilizes composition is dependency injection. It's really on a different plane of abstraction than the one design patterns resides on. It's more like a fundamental principle that design patterns can leverage.

Virtually every design pattern that utilizes composition is dependency injection. It's really on a different plane of abstraction than the one design patterns resides on. It's more like a fundamental principle that design patterns can leverage.

Yeah, I agree its more of way of expressing collaborating objects or composition. And is not something that application developers will implement, rather use.
It would be something that a framework would implement.

(However technically Fowler seems to refer to it as a "pattern")

"In the Java community there's been a rush of lightweight containers that help to assemble components from different projects into a cohesive application. Underlying these containers is a common pattern to how they perform the wiring, a concept they refer under the very generic name of "Inversion of Control". In this article I dig into how this pattern works, under the more specific name of 'Dependency Injection'..."

http://martinfowler.com/articles/injection.html

Regardless I was half serious, hence the ":)"

Again, its not a pattern that developers would implement like a Singleton, rather they would use it (ala Spring)

It's really on a different plane of abstraction than the one design patterns resides on. It's more like a fundamental principle that design patterns can leverage.

Yes and no.

While, Dependency Injection is the cleanest means of implementing the _concepts_ in the GoF Creational Patterns, it is, in itself, an abstraction of these patterns.

Objects don't need to care if their dependencies are Singletons or Prototypes, and an IoC container itself is the mother-of-all Abstract Factories.

Dependency Injection does nothing more than restate the Dependency Inversion Principle. There are other principles, such as the Open-Close Principle and Liskov Substitution that most patterns comply with.

Guys,

You cannot be serious discsussing it. Those names have been here for ages. I wouldn't call it "nice" experience. I'd rename it to "stupid".