what pattern(s) would you vote off the island?

[Nate Schutta]

After reading Martin Fowler's OOPSLA wrap up (http://martinfowler.com/bliki/OOPSLA2004.html) I couldn't help but wonder: what pattern would you vote off the island?

Personally, I would love a second edition but I don't think that is likely...

Nate

[Junilu Lacar]

Not really a vote off but I really wish people would stop using "Value Object" instead of Transfer Object.

[David Hibbs]

I'd skimmed his comments once before, but your question prompts me to consider it more deeply.

Popping open my copy of the GoF, I see several patterns that I would not remember were there were it not for the handy copy of aforementioned book.

The dislike of Singleton probably comes from the all-too-often incorrect implementations of it, coupled with it being a misnomer in clustered environments. That said, I'm still a fan of Singleton as a way of avoiding repeated creation of objects that are of a utilitarian nature such as configuration information. I say "Save the Singleton!"

I don't hate Bridge, Interpreter or Adapter, but they could all be @deprecated and unified into a single pattern I like to call a Converter.

I don't understand the dislike of Factories. Really, they are an integral part (or can be, anyway) of a Strategy. More confusing to me than the term Factory is "Builder". Something fresh out of a factory is new and needs state set. But in what state does an object come from a Builder?

Anyway, I think factory vs. builder is a po-tay-toh/po-tah-toe issue.

These things said, high on my list to vote off would be...

Composite -- isn't this just aggregation/composition? Do we really need to describe this as a pattern ?!?!

Mediator -- This is either where business logic goes or a good place for a strategy. When was the last time you saw this term in code???

Memento -- Hibernate, BMP, CMP... who needs a Memento?

[David Hibbs]

Originally posted by Junilu Lacar:
Not really a vote off but I really wish people would stop using "Value Object" instead of Transfer Object.

+1.

[Greg Ostravich]

I don't know what pattern I'd vote off, but I'm not sure I'd get rid of Composite. It's one of the few patterns that was simple to understand and recognize.
I think the value in Composite is that if you recognize that Structural Pattern than you have some 'gimmes' in terms of Behavioral patterns to walk that structure. Knowing you have a Composite, you may decide to use the Visitor and/or Iterator pattern.

There's my $.02 -

[Michael Ernest]

Originally posted by David Hibbs:

These things said, high on my list to vote off would be...

Composite -- isn't this just aggregation/composition? Do we really need to describe this as a pattern ?!?!

Mediator -- This is either where business logic goes or a good place for a strategy. When was the last time you saw this term in code???

Memento -- Hibernate, BMP, CMP... who needs a Memento?

I think Composite has multiple important uses, not the least of which is a valuable teaching aid and a mnemonic for understanding how one kind of object can or should contain specializations of itself.

My ex-father-in-law was fond of saying that most of what he saw in OO concepts was just common sense stuff he had been doing in C all along. Then again, he wrote code solo, more or less. He didn't need a vocabulary of terms or a notation scheme to describe his techniques to others: he just needed to produce a usable interface to his clients, who could care less about the means of construction so long as everything worked according to spec.

It seems to me Fowler is on the verge of forgetting that design patterns aren't an edge to greater innovation: it's a system of documenting so-called common sense OO programming techniques. Now that Fowler is a little bored, he wants something sexy to emerge from all this patterns talk. Apparently that means for him pruning out the 'dead weight' from the catalog, the words that for him have fallen from favor.

But languages in any form don't work that way. Outside of France, there is no reliable process or persuasion by which words that matter can be arbitrarily separated from those that don't. Words are not like laws or codes. They are the elements that construct laws and codes.

The only indicators we can rely on for 'important' patterns are trailing ones, such as actual usage. Martin Fowler might help accelerate the process by disdaining this or that, but that's fashion sense, not practice.

[Lanny Gilbert]

I don't think I'd vote it off the island, but I know that I'd rename the Singleton pattern. Especially since I've seen it used so often to provide more than one instance of a class.

I don't know what I'd call it tho...

Maybe Single -but on occasion multiple- ton??

[Gerald Davis]

The decorator pattern is evil look what it has done to the Java io package man!, why is it unnecessary complicated. Is it doing the Irish Jig. It seems to me these classes below were once only states. States! you know the 'true' 'false' 'readable' and 'writeable'. Now they have mutated into object themselves bloatware city on steroids . I danna think Bill Gates could have done a better job himself.
Imagine if we was to adopt this style to business modelling.

Employee = new EmployeesFromDepartment19FiredBeforeFebruary()

It doesn't look nice does it. One bad class I can understand, but a whole package full of tripe like this. Java is total pants.

What a mess; composition gone mad, what kind of design pattern is this.
data = new AsciiInputStream(new FileInputStream("data.dat"));

So many classes; make them into functions? why would you do a daft thing like that for!!?
PrintStream FileOutputStream InputStreamReader OutputStream WritableNonBufferedWindowsSocket bla bla bla bla

This is how IO should be in a sane man's language
s = OpenSocket(url, buffered=true, writable=true)

[Sathya Srinivasan]

Originally posted by Greg Ostravich:
I don't know what pattern I'd vote off, but I'm not sure I'd get rid of Composite. It's one of the few patterns that was simple to understand and recognize.
I think the value in Composite is that if you recognize that Structural Pattern than you have some 'gimmes' in terms of Behavioral patterns to walk that structure. Knowing you have a Composite, you may decide to use the Visitor and/or Iterator pattern.

There's my $.02 -

I agree. To my knowledge, one of the best uses of the Composite pattern is the Component-Container in AWT.

But it also tends to be misused a lot.

[Sathya Srinivasan]

Originally posted by Gerald Davis:
The decorator pattern is evil look what it has done to the Java io package man!, why is it unnecessary complicated. Is it doing the Irish Jig. It seems to me these classes below were once only states. States! you know the 'true' 'false' 'readable' and 'writeable'. Now they have mutated into object themselves bloatware city on steroids . I danna think Bill Gates could have done a better job himself.

A bad implementation, or at least an unnecessary implementation, does not mean that the pattern itself is bad. For example, the use of Decorator in ScrollPane is very good.

[Ilja Preuss]

Originally posted by Gerald Davis:
The decorator pattern is evil look what it has done to the Java io package man!

It made it easy to reuse? If I ever get my BrainReader(TM) working, all I need to do is to implement a BrainInputStream. I don't need to care at all wether you actually want it to be buffered, wether you want to read it line by line, wether you want to convert it to a textual represenation (by wrapping it into a reader), or even use some decorator I'm not even aware of!

why is it unnecessary complicated.

Gee! Relax! Take a deep breath! And then realize that where the io package is complicated it isn't inherently because of the use of the Decorator pattern! :roll:

Imagine if we was to adopt this style to business modelling.

Employee = new EmployeesFromDepartment19FiredBeforeFebruary()

Sorry, that's simply not true.

What a mess; composition gone mad, what kind of design pattern is this.
data = new AsciiInputStream(new FileInputStream("data.dat"));

Well, the Decorator pattern, probably. AsciiInputStream doesn't seem to be part of the JDK, though, so I'm not sure.

So many classes; make them into functions? why would you do a daft thing like that for!!?

For reusability, probably.

PrintStream FileOutputStream InputStreamReader OutputStream

Not sure what problem you have with those.

WritableNonBufferedWindowsSocket

Not at all like anything I've ever seen in the JDK. Actually such a kind of class exactly is *not* needed because of the use of the Decorator pattern!

This is how IO should be in a sane man's language
s = OpenSocket(url, buffered=true, writable=true)

So you'd like to reinvent buffering for every single kind of input? Stunning...

[Kishore Dandu]

how about Singleton(not 100% of the times, but not to use it as often as practised at this point of time)

[Ilja Preuss]

Originally posted by Michael Ernest:
Now that Fowler is a little bored, he wants something sexy to emerge from all this patterns talk. Apparently that means for him pruning out the 'dead weight' from the catalog, the words that for him have fallen from favor.

I didn't understand him that way at all.

First, he didn't at all say what he voted for; he just reported the result of a group vote.

Second, the patterns weren't "voted off" because they were boring, according to the report. Most where voted off because they didn't seem to be used frequently enough to be mentioned as a pattern (at least according to the participants). Factory Method explicitely was mentioned as having a confusing name, not as being useless.

[Gerald Davis]

Thanks dude I needed someone defend java a little, I thought I was started to lose my mind.

Originally posted by Ilja Preuss:

So you'd like to reinvent buffering for every single kind of input? Stunning...

s = OpenSocket(url, buffered=true, writable=true)

No no no not at all my friend, this is a fa�ade pattern function, it could implement all of those input,out and writable objects underneath. This is the advantage of a fa�ade pattern; implementation changes but interface stays the same. Implementation changes and improvements to java are very hard with all these low low level classes floating around on source. If I was working with java.io , would have to role my own fa�ade function like this to hide these java.io classes from rest of application.

Look at how Jpython and Python use almost completely different implementations to implement the same OpenSocket functionality.



Imagine if we was to adopt this style to business modelling.
Employee = new EmployeesFromDepartment19FiredBeforeFebruary()

Originally posted by Ilja Preuss:

Sorry, that's simply not true.

OK, I over exaggerated a bit
data = new EmployeeFromDepartment19(new FiredBeforFebruary("data.dat"));
A little improvement but its still pants.

[Michael Ernest]

Originally posted by Ilja Preuss:

First, he didn't at all say what he voted for; he just reported the result of a group vote.

Second, the patterns weren't "voted off" because they were boring, according to the report. Most where voted off because they didn't seem to be used frequently enough to be mentioned as a pattern (at least according to the participants). Factory Method explicitely was mentioned as having a confusing name, not as being useless.

Perhaps I'm reading too much between the lines, but it seems to me if an advocate takes the trouble to report a survey, he has something invested in the intent of the survey. The actual results are less important than the act of determining what is "useful" or "used" and what isn't.

As I mentioned before, this kind of thing really isn't well served by casual surveys. Just because Nicholas Petreley or some other trade rag pundit thinks COBOL is dead doesn't make it so, especially to someone like Nicholas Petreley when the mail comes pouring in to prove that such comments are out of touch. Same thing with this kind of survey: I'd still bet you that regardless of what people said they used or didn't used, they're inclined to dismiss patterns they know so well as to rarely think consciously when they apply them.

Factory could perhaps be better named, but to me this is like saying the word "set" could have fewer individual dictionary entries. The word has been established; how useful is it now to change that word and start an entirely new discussion over what the new word should be, how will people learn or be informed that Factory and this new chosen word actually point to the same thing, etc., etc.? What standards body will emerge as an authority to arbitrate the passing of information, and then how will people come to know where to find this body's website, or what-have-you?

I think those who consider the costs, along with the romance, of changing the status quo generally find fewer reasons to complain. That doesn't mean discussion should be precluded; quite the contrary. In any system of conventions, however, certain terms over time will simply seem more arbitrary than apt to a new generation of users. It's bloody difficult to know what will be intuitively clear 20 years from now. Certainly when GoF was published, factories weren't so foreign to the general consciousness...

[Rick Portugal]

Originally posted by Lanny Gilbert:
I know that I'd rename the Singleton pattern. Especially since I've seen it used so often to provide more than one instance of a class.

I don't know what I'd call it tho...

Maybe Single -but on occasion multiple- ton??

What do you mean by that? Do you have an example where Singleton provides multiple instances of a class? Sounds like a contradiction.

[Ilja Preuss]

Originally posted by Michael Ernest:
Perhaps I'm reading too much between the lines

Well, I think you do...

It was just an informal, non-representative survey, whichs outcome Martin Fowler found interesting enough to shortly mention it. As you say, that won't change much, besides perhaps sparking some thoughts in some people's heads (which I can't think of as a bad thing).

Factory could perhaps be better named

It was about Factory *Method*, not Factory!

how will people learn or be informed that Factory and this new chosen word actually point to the same thing, etc., etc.? What standards body will emerge as an authority to arbitrate the passing of information, and then how will people come to know where to find this body's website, or what-have-you?

We don't need a standards body, we need good names that most people understand. Most people already use the name "Factory Method" differently from the description in the GoF book, so it probably wouldn't be much of a problem to give the original pattern a better name, would it?

And new names for existing patterns were already introduced in the past (Data Transfer Object and Dependency Injection come to mind).

[Ilja Preuss]

Originally posted by Gerald Davis:

OK, I over exaggerated a bit
data = new EmployeeFromDepartment19(new FiredBeforFebruary("data.dat"));
A little improvement but its still pants.

Yes, it's not something I would do. I don't see the similarity to the java.io package (there is no FileFromDriveC class, as far as I can tell).

[Ilja Preuss]

Originally posted by David Hibbs:
The dislike of Singleton probably comes from the all-too-often incorrect implementations of it, coupled with it being a misnomer in clustered environments. That said, I'm still a fan of Singleton as a way of avoiding repeated creation of objects that are of a utilitarian nature such as configuration information. I say "Save the Singleton!"

Well, I don't have anything against reusing a single object where appropriate. I very seldom find it really appropriate to provide a global access point to that object, though. Most often I prefer a Just Create One over a Singleton, therefore.

I don't hate Bridge, Interpreter or Adapter, but they could all be @deprecated and unified into a single pattern I like to call a Converter.

Aren't Interpreter and Adapter quite different in their structure? And in which way is Bridge a "Converter" at all?

I don't understand the dislike of Factories.

I don't remember anyone reporting a dislike for Factories. What I remember is a dislike for the *name* "Factory Method" (which I can connect to - many people seem to confuse that pattern with simple creation methods).

More confusing to me than the term Factory is "Builder". Something fresh out of a factory is new and needs state set. But in what state does an object come from a Builder?

Sorry, I don't follow you. Certainly an object can leave its factory in a ready-to-use state (actually I'd prefer it that way).

The difference between Builder and Abstract Factory is that with the Builder pattern you need to do a whole sequence of method calls to create a single object, but thereby also have more control over what the object will look like.

Composite -- isn't this just aggregation/composition?

Actually not, no. With the Composite pattern, the trick is that the "parts" implement the same interface as the "whole" and therefore client code doesn't need to care wether it's working on one or more objects. For example, when you call repaint on a JComponent, all its child components will be repainted, too, without you having to call their methods, too.

Mediator -- This is either where business logic goes or a good place for a strategy. When was the last time you saw this term in code???

You don't necessarily need to name your classes after a pattern to use a pattern.

Memento -- Hibernate, BMP, CMP... who needs a Memento?

The Mementa pattern actually is orthogonal to the use of a persistence layer. I once looked it up to see wether there was a better solution to a problem I just solved, I found out that I just reinvented it...

[Elisabeth Robson]

I'd be very interested in taking a poll to find out what patterns people use the most and least. We did some research before writing Head First Design Patterns to try to determine the most used (and useful) patterns as we knew we wouldn't be able to cover them all. We did find some information about the use of the GoF patterns, which happened to coincide exactly with the patterns we wanted to cover in-depth with only one exception, but I'd be interested to find out what people here think too.

Is there a way to do an official poll, or similar, to avoid too many posts and/or emails on the subject?

Personally, I've got some patterns I rely on often (probably my most used pattern is Observer), but even the patterns I've never used in production have at the very least made me think about the design and try to come up with situations where I might actually use it. So I'm not sure I'd throw any off the island, but perhaps just make some go to the beach and relax

Elisabeth

[Ilja Preuss]

Originally posted by Junilu Lacar:
Not really a vote off but I really wish people would stop using "Value Object" instead of Transfer Object.

You probably mean that they should call TOs TOs, not that you shouldn't use VOs at all?

[Sathya Srinivasan]

Originally posted by Elisabeth Freeman:
... which happened to coincide exactly with the patterns we wanted to cover in-depth with only one exception, ...

may we know which one?

Originally posted by Elisabeth Freeman:

So I'm not sure I'd throw any off the island, but perhaps just make some go to the beach and relax

I would agree! Patterns are usually formed using the 3+ rule (as Elisabeth mentioned in a different thread), which means that there are at least 3 applications in the world that need this approach. So, by defition, all patterns are useful. It's just that some are more useful than others.

[Nicholas Cheung]

You probably mean that they should call TOs TOs, not that you shouldn't use VOs at all?

In fact, TO and VO are referring to the same thing? I feel it is just a change of the name, not a big deal indeed, isnt it?

Nick

[Elisabeth Robson]

... which happened to coincide exactly with the patterns we wanted to cover in-depth with only one exception, ...

may we know which one?

Template Method. We didn't think it was a commonly used pattern, but it was in the 2nd most useful category, which suprised us. So we included it in our in-depth coverage. Once we did a bit of digging, we actually found it used in the JDK in a few places too, which was nice because we could point to "real-world" usage of the pattern.

Elisabeth

[Ilja Preuss]

Originally posted by Nicholas Cheung:

In fact, TO and VO are referring to the same thing?

I don't think so.

http://faq.javaranch.com/view?DataTransferObject
http://faq.javaranch.com/view?ValueObject

[Ilja Preuss]

Originally posted by Elisabeth Freeman:
Is there a way to do an official poll, or similar, to avoid too many posts and/or emails on the subject?

I created a wiki poll page at http://faq.javaranch.com/view?DesignPatternsPoll. Have fun!
[ December 01, 2004: Message edited by: Ilja Preuss ]

[Mark Spritzler]

I'd vote Prototype off the island.

Mark

[Elisabeth Robson]

Awesome - thanks for creating the poll! Everyone take the poll so we can figure out which are the most used patterns.

Elisabeth

[David Hibbs]

Originally posted by Ilja Preuss:

Aren't Interpreter and Adapter quite different in their structure? And in which way is Bridge a "Converter" at all?

If you're a pattern purist, then yes--you're exactly right. The important issue, IMHO, is not so much the internal structure as that they take something in one form to another.

Forget I mentioned Bridge. I had a moment of Design Confusion.
I do think it should be renamed for clarity.


I don't remember anyone reporting a dislike for Factories. What I remember is a dislike for the *name* "Factory Method" (which I can connect to - many people seem to confuse that pattern with simple creation methods).

...

Sorry, I don't follow you. Certainly an object can leave its factory in a ready-to-use state (actually I'd prefer it that way).

The difference between Builder and Abstract Factory is that with the Builder pattern you need to do a whole sequence of method calls to create a single object, but thereby also have more control over what the object will look like.


The difference between a "factory method" and a "simple creation method" is semantic. A "simple creation method" can be a factory method or vice versa. It is only one implementation.

Similarly, I think the difference between a builder and a factory that you mention is also semantic. Theoretically, yes, you can have more control over a builder. However, you can always implement a factory to provide more control.

re: my point on ready to use... consider some real world items. When you get a house from a home builder, you need to do a bunch of things to make it so you want to use it -- install appliances, move in your stuff, etc etc. When you get a car from a factory, you drive it off the lot.

Patterns should be named so that they inspire a thought of something everyone^M the majority of people is familiar with.


Actually not, no. With the Composite pattern, the trick is that the "parts" implement the same interface as the "whole" ... For example, when you call repaint on a JComponent, all its child components will be repainted, too, without you having to call their methods, too.


You can implement basic composition this way, too. IMHO it's more of an extension of the basic concepts of aggregation and delegation. If people think it's a good one to keep around because it's an easy one to grasp, well, OK, but I don't think it needs its own name.


You don't necessarily need to name your classes after a pattern to use a pattern.


No, but you frequently do--I simply used the name to spur some thought. You didn't answer the question, though. When did you last see a Mediator in your code?

If you want to keep it around, call it a Controller so it can be tied to MVC. That's really what it's doing--controlling the interaction of pieces of the model and/or view.

[David Hibbs]

Originally posted by Ilja Preuss:

If I ever get my BrainReader(TM) working, all I need to do is to implement a BrainInputStream. I don't need to care at all wether you actually want it to be buffered, wether you want to read it line by line, wether you want to convert it to a textual represenation (by wrapping it into a reader), or even use some decorator I'm not even aware of!

Just as long as you never implement a BrainWriter (TM). Even if you do, I REFUSE to ever pass you my BrainOutputStream. Or if I do, it will be permanently buffered to /dev/null.

[Gerald Davis]

Originally posted by David Hibbs:


Just as long as you never implement a BrainWriter (TM). Even if you do, I REFUSE to ever pass you my BrainOutputStream. Or if I do, it will be permanently buffered to /dev/null.

Brain(Stream=Input,Buffered=false,socket=true)

Does the same as

BrianInputBufferedSocked
BrianOutputBufferedSocket
BrianIntputSocket
BrianOutput
BrianOutputBuffered
BrianInputBuffered
bla bla bla bla
bla
This id doing my head in|

This is why I think the factory method is the best design pattern, second to facade.

[Ilja Preuss]

Originally posted by Gerald Davis:
Brain(Stream=Input,Buffered=false,socket=true)

What does the socket=true mean?

What if I want to have a Reader?

Does the same as

BrianInputBufferedSocked
BrianOutputBufferedSocket
BrianIntputSocket
BrianOutput
BrianOutputBuffered
BrianInputBuffered
bla bla bla bla
bla
This id doing my head in|

Again, that's not the alternative I'd be using; and I don't understand why you would think it was.

[Ilja Preuss]

Originally posted by David Hibbs:
If you're a pattern purist, then yes--you're exactly right. The important issue, IMHO, is not so much the internal structure as that they take something in one form to another.

So are you saying that in any situation you can use an Adapter, you could as well use an Interpreter? I don't get it...

The difference between a "factory method" and a "simple creation method" is semantic.

Actually not, no. A creation method typically is static, whereas a Factory Method has to be an instance method, because it needs to be called polymorphically. Typically the factory method is declared abstract in the class it is used in and defined in subclasses (it is a specialization of the Template Method pattern).

Similarly, I think the difference between a builder and a factory that you mention is also semantic. Theoretically, yes, you can have more control over a builder. However, you can always implement a factory to provide more control.

With a factory, every method call creates a product. With a builder, every method call specifies more properties of the product to build - only after a sequence of those calls you finally pick up the product from the builder.

The *whole reason* for the existance of the Builder pattern is to give you finer control over how the product will get build!

Patterns should be named so that they inspire a thought of something everyone^M the majority of people is familiar with.

Well, yes, that sounds like a good idea. It's somewhat dangerous to conclude that your personal thoughts are exactly the ones that match what the GoF had in mind, though, isn't it?

Actually not, no. With the Composite pattern, the trick is that the "parts" implement the same interface as the "whole" ... For example, when you call repaint on a JComponent, all its child components will be repainted, too, without you having to call their methods, too.


You can implement basic composition this way, too.

Huh? Of course you can, as Composite is making of composition. So when you use composition the Composite way, you are simply implementing the Composite pattern. So what?

IMHO it's more of an extension of the basic concepts of aggregation and delegation. If people think it's a good one to keep around because it's an easy one to grasp, well, OK, but I don't think it needs its own name.

IMO, it needs its own name simply because it's so usefull. To me "we will implement a composition" has a very different meaning from "we will implement a Composite" - not a big difference in the actual code, but a huge difference in how the code will get used.

When did you last see a Mediator in your code?

I have to admit that I find the Mediator to be so basic (or at least what I understand it to be), that I have trouble saying wether/when I used one. It's quite possible that I'm missing something about this pattern, though.

If you want to keep it around, call it a Controller so it can be tied to MVC.

Why would you want to tie something so generic as Mediator to something as specialized as MVC?

That's really what it's doing--controlling the interaction of pieces of the model and/or view.

Another common misconception: The responsibility of the Controller in the MVC pattern is *not* to mediate between the Model and the View (they are actually allowed to talk directly to one another), but to handle user input.

[Pradeep bhatt]

Originally posted by Nicholas Cheung:

In fact, TO and VO are referring to the same thing? I feel it is just a change of the name, not a big deal indeed, isnt it?

Nick

https://coderanch.com/t/99140/patterns/Diffference-between-Value-Object-Transfer

[David Hibbs]

Originally posted by Ilja Preuss:

So are you saying that in any situation you can use an Adapter, you could as well use an Interpreter? I don't get it...

No, I'm saying that where you would use an Adapter, you could use a Converter. Where you would use an Interpreter, you could also use a Converter. Consider Converter as a superclass of both Adapter and Interpreter. The goal is similar (to make one object usable where it wouldn't normally be usable).

Actually not, no. A creation method typically is static, whereas a Factory Method has to be an instance method, because it needs to be called polymorphically.

Who made that law?

Sure, the GoF definition of a Factory works as you state, but the GoF doesn't have a simple creation method. If we stick with "pure" GoF terms, a creation method then must be either a Factory or an Abstract Factory.

Open Source factory example: commons logging. @see LogFactory.getLog(getClass().getName())

Is this a factory or not?

The *whole reason* for the existance of the Builder pattern is to give you finer control over how the product will get build!

Perhaps. Consider... every example I've seen of a Builder only provides a few options. Most times they are used exactly as in an example. So I have to make 3 calls to do with a builder what I could do in a factory -- or by specifiying a "creation method" that simply takes the parameters I desire. So it seems that I can collapse a builder to a factory.

Well, yes, that sounds like a good idea. It's somewhat dangerous to conclude that your personal thoughts are exactly the ones that match what the GoF had in mind, though, isn't it?

I never claimed it matched what the GoF had in mind. The talk was of how to update the GoF patterns to what is commonly accepted -- I simply want to match the updated names to the updated patterns.

IMO, it needs its own name simply because it's so usefull. To me "we will implement a composition" has a very different meaning from "we will implement a Composite" - not a big difference in the actual code, but a huge difference in how the code will get used.

That's fair -- I said we could keep it, remember?

I just think if you want it to be a specific pattern that you should give it a distinct name. Newcomers to OO and patterns will inevitably become confused. Consider: A composite object is not the same as a Composite object. The difference is only capitalization if you read it. Hope you're not listening to this through a speech interpreter.

Why would you want to tie something so generic as Mediator to something as specialized as MVC?

OK, to clarify. By "tie" I did not mean that Controller (my new name) would not exist without MVC. I simply meant that Controller could become a component of a larger pattern (MVC) which would aid in understanding MVC.

Another common misconception: The responsibility of the Controller in the MVC pattern is *not* to mediate between the Model and the View (they are actually allowed to talk directly to one another), but to handle user input.

I never said that this was its sole role/responsibility. While what you say "(they are actually allowed to talk directly to one another)" is true, the Controller is also not only there to handle user input. It also selects the next view based on model operations(MVC Model 2) -- which puts it squarely in the Mediator role.
[ December 02, 2004: Message edited by: David Hibbs ]

[Ilja Preuss]

Originally posted by David Hibbs:
No, I'm saying that where you would use an Adapter, you could use a Converter. Where you would use an Interpreter, you could also use a Converter. Consider Converter as a superclass of both Adapter and Interpreter. The goal is similar (to make one object usable where it wouldn't normally be usable).

So what would your Converter pattern look like? I can't imagine it...

Sure, the GoF definition of a Factory works as you state, but the GoF doesn't have a simple creation method.

True. I'm using the definition from "Refactoring to Patterns", but I think I've already seen it before. Do you know of a definition of Creation Method that conflicts with this?

If we stick with "pure" GoF terms, a creation method then must be either a Factory or an Abstract Factory.

I don't understand this reasoning.

Certainly the term Factory Method is already defined by GoF, in a way that doesn't allow a Factory Method to be a simple static method. So it seems clear to me that if we mean a static method that creates things, we should use a different name for it...

Open Source factory example: commons logging. @see LogFactory.getLog(getClass().getName())

Is this a factory or not?

It's neither a Factory Method, nor an Abstract Factory, obviously. So...?

Perhaps. Consider... every example I've seen of a Builder only provides a few options. Most times they are used exactly as in an example. So I have to make 3 calls to do with a builder what I could do in a factory -- or by specifiying a "creation method" that simply takes the parameters I desire. So it seems that I can collapse a builder to a factory.

Of course you can. You can refactor one pattern into the other. Sometimes it doesn't make sense, though.

A good example for the Builder pattern is PanelBuilder from the FormLayout library:

PanelBuilder builder = new PanelBuilder(layout);
CellConstraints cc = new CellConstraints();
builder.addLabel("&Title",      cc.xy  (1, 1));
builder.add(new JTextField(),   cc.xywh(3, 1, 3, 1));
builder.addLabel("&Price",      cc.xy  (1, 3));
builder.add(new JTextField(),   cc.xy  (3, 3));
builder.addLabel("&Author",     cc.xy  (1, 5));
builder.add(new JTextField(),   cc.xy  (3, 5));
builder.add(new JButton("..."), cc.xy  (5, 5));
return builder.getPanel();

I never claimed it matched what the GoF had in mind. The talk was of how to update the GoF patterns to what is commonly accepted -- I simply want to match the updated names to the updated patterns.

Well, this is the first time I hear someone stating he has a problem with the names of Abstract Factory and Builder. To me, they connect quite nicely to what the patterns do.

I just think if you want it to be a specific pattern that you should give it a distinct name. Newcomers to OO and patterns will inevitably become confused. Consider: A composite object is not the same as a Composite object. The difference is only capitalization if you read it. Hope you're not listening to this through a speech interpreter.

Well, yes, that's a small problem.

OK, to clarify. By "tie" I did not mean that Controller (my new name) would not exist without MVC. I simply meant that Controller could become a component of a larger pattern (MVC) which would aid in understanding MVC.

Well, I don't think that a MVC Controller really is the same as a Mediator.

I never said that this was its sole role/responsibility. While what you say "(they are actually allowed to talk directly to one another)" is true, the Controller is also not only there to handle user input. It also selects the next view based on model operations(MVC Model 2) -- which puts it squarely in the Mediator role.

Ah, ok, now we are talking about web applications. When you adapt the original MVC pattern to typical web applications, you have to make some compromises, I guess (though that might not be true with Squeaks Seaside).

I'm mainly working on Swing applications nowadays, and there the *sole* responsibility of the Controller actually is to handle user input.

[Michael Feathers]

Originally posted by Nate Schutta:
After reading Martin Fowler's OOPSLA wrap up (http://martinfowler.com/bliki/OOPSLA2004.html) I couldn't help but wonder: what pattern would you vote off the island?

I'd vote off Template Method. To me, it's not a pattern, it's just the typical result when you remove duplication in an inheritance hierarchy.

[Mark Spritzler]

Originally posted by Michael Feathers:


I'd vote off Template Method. To me, it's not a pattern, it's just the typical result when you remove duplication in an inheritance hierarchy.

But it is cool. I think it is a pattern. When you see common steps and that only a few steps are different for each type, then you say, "Hey, let's go Template"

Mark

[Ilja Preuss]

Originally posted by Michael Feathers:


I'd vote off Template Method. To me, it's not a pattern, it's just the typical result when you remove duplication in an inheritance hierarchy.

How does that conflict with the definition of a Pattern - being a common (typical!) solution to a common design problem (i.e. removing duplication in an inheritance hierarchy)?

I find it to be quite usefull to have a name for it: "Gee, I always forget to call super.foo() when I override this method in subclasses." "Why don't you use Template Method instead?" "Well, good question. Why didn't I think of it???"

[David Hibbs]

Originally posted by Ilja Preuss:

So what would your Converter pattern look like? I can't imagine it...

That's OK. My Converter pattern (as I've built it several places now) is actually very simple. In the most abstract terms possible:

  
public interface Converter
{
    public Object convert(Object original);
}

When actually implemented, it returns a different class from that passed in. An actual (yet rather useless) example might be

public class IntegerToLongConverter
{
    public Long convert(Integer input)
    {
        return new Long( input.longValue() );
    }
}

I guess you could almost call this a Mediator.

True. I'm using the definition from "Refactoring to Patterns", but I think I've already seen it before. Do you know of a definition of Creation Method that conflicts with this?

No, just being a little bit antagonistic -- and point out that by pure GoF names, there is no name for a static creation method. Call it whatever you want, but I call it a factory (especially if you pass it a parameter to indicate what you want). Judging by the Apache code, I'm not the only one.

I don't understand this reasoning.

Certainly the term Factory Method is already defined by GoF, in a way that doesn't allow a Factory Method to be a simple static method. So it seems clear to me that if we mean a static method that creates things, we should use a different name for it...

1) We agree (I think) that this is a pattern of some sort.
2) We agree (Again, I think) that this is a creational pattern.
3) Limiting scope to GoF terms, that means it must be one of Abstract Factory, Builder, Factory Method, Prototype, or Singleton.
4) Rule out Builder and Prototype.

This means it must be one of Abstract Factory, Factory Method, or Singleton.

It could be a Singleton, but there is no guarantee. Barring Singleton, a static creational method then must be a Factory of some sort. Perhaps we could call it a Simple Factory ?

A good example for the Builder pattern is PanelBuilder from the FormLayout library...

I wasn't aware of that one -- it's been quite some time since I've written any Java based UIs. That's pretty nice!

Like I said, though, my problem with Builder is that it seems to get used where you never really need to set options aside from the defaults. This means I have to write 3 or 4 lines of code where 1 should suffice. Pattern misuse, if you will. Of course, misuse probably should not be cause to throw a pattern out the window.

Well, I don't think that a MVC Controller really is the same as a Mediator

Maybe not, but it could be.

I'm mainly working on Swing applications nowadays, and there the *sole* responsibility of the Controller actually is to handle user input.

Ahh. There is of course no reason that you can't extend a concept to add some extra responsibilities. =)