In Part 1 of this series we learned about the benefits of the Visitor Pattern and saw a basic approach according to the GoF description.
As clean and elegant the visitor pattern might look in the first place, it nonetheless has its disadvantages. Say, we want to add a new shape TShapeTriangle. We have to do it inside the same unit the other shapes are declared. As the shapes reference the visitor and the visitor references the shapes we have to put all shape classes together with the visitor into the same unit. Although this might work in some smaller scenarios, it definitely doesn’t in most of the real ones. Probably this is one of the reasons why the Visitor Pattern is not as famous as it should be.
Can we find a solution? Yes, we can!
Lets examine why there is such a close coupling between all the shapes and the visitor: The shapes use the visitor’s method corresponding to their own class and the visitor has to know about all the shapes it has to handle. How can we break this up?
The answer are interfaces! Instead of declaring a visitor capable of handling every defined shape, we declare an interface for each shape that only handles that specific shape.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 |
unit uShapeBase; interface uses Classes; type TAbstractShape = class public procedure Accept(Visitor: IInterface); virtual; abstract; end; { we avoid ref-counting here } TShapeVisitor = class(TInterfacedPersistent) public procedure Visit(Instance: TAbstractShape); end; type TShapeRectangle = class(TAbstractShape) private FX0: Double; FX1: Double; FY0: Double; FY1: Double; public procedure Accept(Visitor: IInterface); override; property X0: Double read FX0 write FX0; property X1: Double read FX1 write FX1; property Y0: Double read FY0 write FY0; property Y1: Double read FY1 write FY1; end; IShapeRectangleVisitor = interface ['{6F521E71-5DB8-4ECE-B453-60F9A3B8BE22}'] procedure VisitShapeRectangle(Instance: TShapeRectangle); end; type TShapeCircle = class(TAbstractShape) private FCenterX: Double; FCenterY: Double; FRadius: Double; public procedure Accept(Visitor: IInterface); override; property CenterX: Double read FCenterX write FCenterX; property CenterY: Double read FCenterY write FCenterY; property Radius: Double read FRadius write FRadius; end; IShapeCircleVisitor = interface ['{27D7DCD3-952A-4879-8667-E86023612BFB}'] procedure VisitShapeCircle(Instance: TShapeCircle); end; implementation uses SysUtils; procedure TShapeVisitor.Visit(Instance: TAbstractShape); begin Instance.Accept(Self); end; procedure TShapeCircle.Accept(Visitor: TShapeVisitor); begin (Visitor as IShapeCircleVisitor).VisitShapeCircle(Self); end; procedure TShapeRectangle.Accept(Visitor: TShapeVisitor); begin (Visitor as IShapeRectangleVisitor).VisitShapeRectangle(Self); end; end. |
I’d say the real reason the Visitor pattern doesn’t work in the real world is that the concrete examples where it makes sense (and the head spinning induced by trying to disentangle who actually ends up doing what and how) are simply too few and far between.
This rendering example, for instance.
The chances of needing to render to a canvas but not have to have any other interaction with the canvas are remote in the real world. e.g. in response to a mouse click determine which shape, if any, the user has clicked on.
The information needed to make that determination is almost certainly involved in rendering the shape (the hit region will correspond to the rendered area). You could of course have a “HitTestVisitor”, which will have to duplicate a lot of the code already contained in the “RenderVisitor”, not to mention any number of other visitors.
Also, any visitor can usually just work directly with the objects in question. No need to complicate things with invocation ping-pong with A visiting B just so that B can invoke A’s visit method. Just have A work directly against B and B doesn’t have to know anything about A at all.
Or more succinctly: With the Visitor Pattern you can only visit things which actually accept visits. It’s by invitation only.
It strikes me that you could implement a shape canvas renderer without even that level of coupling in a way that is much easier to understand and follow.
Maybe this was just a sub-optimal example.
I suggest to follow the remaining parts of this four-part series…