|
|
Posted by FluffyCat on 10/29/27 11:33
On 30 Nov 2005 08:35:22 -0800, "Oli Filth" <catch@olifilth.co.uk>
wrote:
>FluffyCat wrote:
>> I know these patterns can look like spaghetti code at first, but if
>> you will be doing any serious OO programming they are extremely
>> important. The visitor pattern is absolutely one that is used and
>> useful, so it is worth taking the time to understand it.
>>
>> I try to make these examples as simple as possible, while sticking to
>> the original intent of the pattern. In the GoF on page 334 - 335 the
>> UML shows anObjectStructure calling the concrete element (which I call
>> the visitee) with accept(Visitor), the concrete element then calls the
>> visitor, which in turn calls a method back in the concrete element.
>
>Exactly; what's the point in calling Visitee->accept(Visitor), whose
>only job is to call Visitor->visit(this)? If ObjectStructure has a
>reference to both Visitor and Visitee, why doesn't it just call
>Visitor->visit(Visitee)? This would make for a simpler, more intuitive
>arrangement.
>
I'm not clear if you object to the Visitor pattern as it is generally
accepted in the OO world, or only to my example of it.
The accept mechanism allows the objectStructure (my testVisitor) to
create the Visitee (eg BookVisitee) and Visitor (eg
PlainDescriptionVisitor) that is appropriate for whatever
obectStructure needs. The objectStructure then uses
Visitee->visit(Visitor) to simultaneously register the appropriate
Visitor with the Visitee, and allow the Visitee to call the approprite
function for and with itself in the Visitor. Then the function in the
Visitor having been passed a Visitee knows what functions in the
Visitee it needs.
The objectStructure merely chooses the pieces to be used, the pieces
then in turn run the show. Sure, objectStructure could control
everything and not let the pieces specify anything. In the Visitor
pattern the Structure calls the Visitee calls the Visitor calls the
Visitor. Of course, there are often many useful variations of any
pattern, and a derivative might be just the thing for a given need.
I'm just trying to show the pattern in it's most classical established
form.
(I know my written descriptions of these patterns aren't the greatest.
This is why I merely provide examples and don't have much tutorial
verbiage on www.fluffycat.com/SDCMSv2/)
>> A useful example of the visitor pattern could show the visitor being
>> able to create HTML or XML output for the same concrete element. I
>> didn't do this because it would "muddy the waters" of the example with
>> whatever overhead I'd need to add to produce the HTML and XML.
>
>But even that wouldn't require the double dispatch, e.g.:
>
>$book = new Book();
>$HTMLThing = new HTMLThing();
>$XMLThing = new XMLThing();
>
>$HTMLThing->display($book);
>$XMLThing->display($book);
>
>
Well, I'd have a more robust example in general, which could show the
pattern in a more useful light, but also more complex. I think that
the simplicity of testVisitor could be undermining my example to some
degree by making some things simpler and yet also perhaps pointless.
>P.S.: Please don't top-post...
k, while I think "top-posting" can make the response part of the
message clearer, if it is against established comp.lang.php standards
I'll certainly stop. I'm all about following standards.
Navigation:
[Reply to this message]
|