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???"
"Write beautiful code; then profile that beautiful code and make little bits of it uglier but faster." --The JavaPerformanceTuning.com team, Newsletter 039.
Originally posted by David Hibbs:
[QB]
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.
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.
3) Limiting scope to GoF terms, that means it must be one of Abstract Factory, Builder, Factory Method, Prototype, or Singleton.
Ahh. There is of course no reason that you can't extend a concept to add some extra responsibilities.
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
Originally posted by David Hibbs:
I agree completely.
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
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)?
[/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]
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>
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.
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.
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.
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
Originally posted by Ilja Preuss:
Well, that's not a pattern, it's an interface definition...
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
An Interpreter interpretes [sic] 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. As I said before, I don't think the term Factory is well defined.
That's where I don't follow you. Why should I limit the scope to GoF terms?
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.
"Write beautiful code; then profile that beautiful code and make little bits of it uglier but faster." --The JavaPerformanceTuning.com team, Newsletter 039.
Originally posted by Ilja Preuss:
Nice to see that we actually agree on something.
"Write beautiful code; then profile that beautiful code and make little bits of it uglier but faster." --The JavaPerformanceTuning.com team, Newsletter 039.
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) ?
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.
We agree that the term Factory isn't well defined.
So why shouldn't I call a static method of this nature a Factory?
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. =)
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.
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
Composite -- isn't this just aggregation/composition? Do we really need to describe this as a pattern ?!?!
http://www.jamonapi.com/ - a fast, free open source performance tuning api.
JavaRanch Performance FAQ
http://www.jamonapi.com/ - a fast, free open source performance tuning api.
JavaRanch Performance FAQ
So what would your Converter pattern look like? I can't imagine it...
http://www.jamonapi.com/ - a fast, free open source performance tuning api.
JavaRanch Performance FAQ
moose poop looks like football shaped elk poop. About the size of this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
|