Meaningless Drivel is fun!*
The moose likes OO, Patterns, UML and Refactoring and the fly likes what pattern(s) would you vote off the island? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "what pattern(s) would you vote off the island?" Watch "what pattern(s) would you vote off the island?" New topic
Author

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

David Hibbs
Ranch Hand

Joined: Dec 19, 2002
Posts: 374
Originally posted by Ilja Preuss:
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???"


I agree completely. I often find myself helping newer developers, so I can't expect them to remember every little step right away. I like to provide a template method (I call it a skeleton method, but it's the same idea). It's pretty easy for them to pick up a class, override some empty methods, and achieve the expected results. Later on, when they understand more, they can dig deeper and see what other details were hidden or completely override them if necessary.


"Write beautiful code; then profile that beautiful code and make little bits of it uglier but faster." --The JavaPerformanceTuning.com team, Newsletter 039.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by David Hibbs:
[QB]


Well, that's not a pattern, it's an interface definition...


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


I guess you could almost call this a Mediator.


No, that's neither an Adapter or Interpreter, nor a Mediator.

A simple example for an Adapter is a class that Adapts an Enumeration to the Iterator interface: EnumerationIterator.

An Interpreter interpretes a textual expression.

A Mediator has at least two references to objects it delegates between.

Your Tranformer might well be seen as a pattern, but is certainly different from those other three patterns.

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.


Call it whatever you want. As I said before, I don't think the term Factory is well defined.

I'd just expect a lot of confusion when the name Factory Method is used for constructs that don't match the GoF pattern of the same name. That's why I'd advice against doing so.

3) Limiting scope to GoF terms, that means it must be one of Abstract Factory, Builder, Factory Method, Prototype, or Singleton.


That's where I don't follow you. Why should I limit the scope to GoF terms? Especially as you asserted above that GoF doesn't handle this case?


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


Of course not. If you had said "a Controller can be adapted so that it also works as a Mediator" I wouldn't have objected (though I might have questioned wether that would often be a good idea). "A Controller is a Mediator", that I simply cannot agree with.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by David Hibbs:
I agree completely.


Nice to see that we actually agree on something.
Michael Feathers
author
Greenhorn

Joined: Aug 24, 2004
Posts: 24

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.


Originally posted by Ilja Preuss:
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)?


It seems that we (the community) swing back and forth on the question of what a pattern is. Originally, patterns were seen as the description of a problem and the core of a solution, rather than just the solution. So, for instance, the problem for Template Method is: how do we get ourselves into a position where we can just subclass and override details to get variation. But, that is not the same problem as: I'm changing code over and over again in this hierarchy, how do I fix it? The common bit is the end point, but if the end point is what determines the pattern then there are other issues. People can arrive at the same code structure when they apply Bridge as they would if they applied Strategy, for instance.

I don't lose sleep over these things. I don't mind the fuzziness, but it does feel weird to say to myself that I am applying Template Method when I'm just removing bits of duplication. At the end, the template method (the thing, not the pattern) just sits there like a surprise. I didn't have to write a template method, I just removed duplication and a method became one whether I noticed it or not.


[/qb]
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???"[/QB]


True, that is very valuable. No qualms there.
[ December 05, 2004: Message edited by: Michael Feathers ]

Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0131177052/ref=jranch-20" target="_blank" rel="nofollow">Working Effectively with Legacy Code</a>
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Michael Feathers:
It seems that we (the community) swing back and forth on the question of what a pattern is. Originally, patterns were seen as the description of a problem and the core of a solution, rather than just the solution.


Well, I agree that that is the definition, yes.

So, for instance, the problem for Template Method is: how do we get ourselves into a position where we can just subclass and override details to get variation. But, that is not the same problem as: I'm changing code over and over again in this hierarchy, how do I fix it? The common bit is the end point, but if the end point is what determines the pattern then there are other issues.


I'm not sure that the common bit is only the end point. After all, the latter problem can be fixed in a whole bunch of ways. It's only when you think "a nice solution would be too the common things, those that I have to change all over the hierarchy, into the superclass, and let the subclasses only define the variation" that you may end up using Template Method, isn't it?

People can arrive at the same code structure when they apply Bridge as they would if they applied Strategy, for instance.


Certainly. Bridge is not much more than a combination of the Strategy and Template Method patterns, used to solve a specific problem. I think I don't see your problem.

it does feel weird to say to myself that I am applying Template Method when I'm just removing bits of duplication. At the end, the template method (the thing, not the pattern) just sits there like a surprise. I didn't have to write a template method, I just removed duplication and a method became one whether I noticed it or not.


That happens to me, too (as I mentioned in another thread, I reinvented Memento that way, without knowing before I searched for alternatives). I don't have a problem with that, though. After all, that is how the patterns came into being - being observed as evolving over and over again as solutions to recurring problems. Therefore it seems natural to me that we can come up with patterns without actively striving to implement them.
David Hibbs
Ranch Hand

Joined: Dec 19, 2002
Posts: 374
Originally posted by Ilja Preuss:

Well, that's not a pattern, it's an interface definition...


Isn't this often how one describes a pattern (at least when one cannot draw UML such as in a text forum) ?


No, that's neither an Adapter or Interpreter, nor a Mediator.


Exactly; it's a Converter!


A simple example for an Adapter is a class that Adapts an Enumeration to the Iterator interface


Yes, I understand that quite well. But I can just as easily have a converter return an Iterator when passed an Enumeration.
public Iterator convert(Enumeration enum) if you will. Now I don't have to worry about ClassCastExceptions either, as I did not propogate the need for EnumerationIterator deeper into my code. Granted, you can just call it an Iterator anyway but I use it for sake of making the point that I can just as easily use a converter.


An Interpreter interpretes [sic] a textual expression.


Yes, but what does it interpret the textual expression into? A Runnable? Most likely, but it could also simply interpret it into another String... convert it into an Object (ala Digester).


A Mediator has at least two references to objects it delegates between.


Yes yes... I was just making a half joke.


Your Tranformer might well be seen as a pattern, but is certainly different from those other three patterns.


That's why I called it somethign different. I simply state that it may be an easier way of describing the other patterns or a substitute thereof.


Call it whatever you want. As I said before, I don't think the term Factory is well defined.


Exactly my point! We agree that the term Factory isn't well defined.

So why shouldn't I call a static method of this nature a Factory?



That's where I don't follow you. Why should I limit the scope to GoF terms?


Only for sake of limiting debate/discussion to the scope of the original question; the original question was about revising and voting out patterns from GoF. Hence, I limit it to GoF patterns and terms.

I think though that we've sufficiently demonstrated that the patterns from GoF already have been revised. =)


Of course not. If you had said "a Controller can be adapted so that it also works as a Mediator" I wouldn't have objected (though I might have questioned wether that would often be a good idea). "A Controller is a Mediator", that I simply cannot agree with.


That's fine, and I agree. My point was more the other way around, though -- "A Mediator is a Controller." Yes, it is a more specialized controller, but if you can understand a controller you should be able to more easily grasp the concept of a Mediator.
David Hibbs
Ranch Hand

Joined: Dec 19, 2002
Posts: 374
Originally posted by Ilja Preuss:

Nice to see that we actually agree on something.


I think we actually agree on a lot of things!


It's just that I started by playing the devil's advocate and picking on a few little "weakling" patterns, resulting in what I think has been
an intriguing philosophical discussion.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by David Hibbs:
Isn't this often how one describes a pattern (at least when one cannot draw UML such as in a text forum) ?


Actually not, no. That's how you might describe the structure of a pattern, but at least as important parts of a pattern are the context and consequences, for example.


But I can just as easily have a converter return an Iterator when passed an Enumeration.
public Iterator convert(Enumeration enum) if you will. Now I don't have to worry about ClassCastExceptions either, as I did not propogate the need for EnumerationIterator deeper into my code. Granted, you can just call it an Iterator anyway but I use it for sake of making the point that I can just as easily use a converter.


Yes. And using a Converter would result in different consequences, so that we probably will want to use it in different contexts than the other patterns.

So it seems reasonable to give them different names, so that we can discuss their differences.


We agree that the term Factory isn't well defined.

So why shouldn't I call a static method of this nature a Factory?


Well, I wouldn't do that because it's likely to cause confusion in your audience.


Only for sake of limiting debate/discussion to the scope of the original question; the original question was about revising and voting out patterns from GoF. Hence, I limit it to GoF patterns and terms.


The question was wether Factory Method is a good name for the pattern, as far as I remember. I think to discuss this, it's kind of unproductive to limit yourself to GoF terms...



I think though that we've sufficiently demonstrated that the patterns from GoF already have been revised. =)


Depends on what you mean by "revised".

My point was more the other way around, though -- "A Mediator is a Controller." Yes, it is a more specialized controller, but if you can understand a controller you should be able to more easily grasp the concept of a Mediator.


A Mediator certainly is a "controller" in the sense that it controls the collaboration of two objects. But that's not what the original MVC Controller is about at all - that is about handling user input.
steve souza
Ranch Hand

Joined: Jun 26, 2002
Posts: 860
Composite -- isn't this just aggregation/composition? Do we really need to describe this as a pattern ?!?!


I find many concepts we deal with in software development can be implemented well with the composite pattern. Primarily because we often want to execute the same command on a group of items that we do on one item. Some examples follow

- Often in software we have to delete, insert, update, copy, zip, unzip, move, reset, add, remove, get, and display groups of things. This group action is passed on to the individual item.

- For example we may want to delete files from a drive. The drive is a composite of directories, and directories are composites of files.

For example
drive.delete() - deletes all directories and files.

We could also add many drives to our composite and call
drives.delete()

- In a software system we created where I work we would execute a command on a server, and we used the Composite to execute this command on a group of servers. For example servers.execute();

- A group of composite examples follows (or should I say a composite of examples - examples.display() )
  • file systems (composites=drives, directories, leaf=files, commands=zip, unzip, copy, move, rename,..)
  • databases (composite=tables, leaf=rows, commands=checksum, delete)
  • GUIs (composites=windows, panels, leaf=widgets,commands=move,hide,highlight)
  • computer games (composite=game, leaf=players, commands=reset,checkscore, start, pause, save)
  • email (composite=folders, leaf=email message, commands=delete, move,encrypt)


  • [ December 15, 2004: Message edited by: steve souza ]

    http://www.jamonapi.com/ - a fast, free open source performance tuning api.
    JavaRanch Performance FAQ
    steve souza
    Ranch Hand

    Joined: Jun 26, 2002
    Posts: 860
    The definintion of composite from GOF is:

    "Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly."

    i.e. Composite objects and individual objects share the same interface.

    My open source class ArraySQL, allows you to query 2 dimensional Object arrays (Object[][]) in an SQL-Like syntax. In my implementation the SQL statement where clause is implemented as a composite of leaf conditionals, and other composites (paren levels).

    The Conditional interface has an isTrue() method that returns true if the row satisfies the condition. An example of a leaf conditional is col0='steve'. There are 3 composite conditionals in the example below: 1) the whole where clause, 2) col0='steve' and col1='souza), 3) (col0='jeff' and col1='beck'))



    Note the sql statement itself is an example of the builder pattern as it converts the sql string into a complex object structure (i.e. builder pattern - Separate the construction of a complex object from its representation so that the same construction process can create different representations.)
    steve souza
    Ranch Hand

    Joined: Jun 26, 2002
    Posts: 860
    So what would your Converter pattern look like? I can't imagine it...



    I don't know if I would call it a pattern, but as part of my open source project I recently used a Converter interface and the decorator pattern to chain formatting conversions together in a flexible way.

    The Converter example below can take any Object type as an argument and depending on the Object type different Converters will perform an action. Because Converters only act on data types that they know about all Objects can be passed to the Converter methods and no action is taken if the Object type doesn't match. Here are the rules I code below:

    1) If the Object is a Number (Integer, Float, Long etc) it will comma delimit the number and return this formatted string (i.e. 10000 becomes 10,000)
    2) if the Object is a Date object the short Date locale specific date format will be returned (i.e. a Date could be formatted as '12/22/04 9:00 PM')
    3) if the Object is a null or empty string then ' ' will be returned.
    4) If the Object is a boolean 'Yes' or 'No' will be returned.

    I have another class that uses the Converters to Format all cells within an Object[][] and allows you to set different formatting rules by column name or number.



    [ April 03, 2005: Message edited by: steve souza ]
    [ April 03, 2005: Message edited by: steve souza ]
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: what pattern(s) would you vote off the island?
     
    Similar Threads
    Humane Interfaces?
    Patterns and the GoF
    THE list of patterns
    what is an island?
    ONE-PROGRAM-ONLY Ranch Style