2

I have a problem and I'm having trouble finding the optimal aproach to it. A colleague recommended the Visitor pattern but I'm not sure if what I want can be done using Visitor. Even if it can be done there are some serious issues about clarity if I use that approach.

I'm trying to serialize / deserialize settings and finding that I need to add the same helper methods to a number of classes (bad). I'd prefer to move these helpers out of the classes I'm putting them in (which should have no code dealing with serialization / deserialization but am unsure how to factor it out) and into a centralized spot.

Currently I'm trying to get / set parameters on objects (buttons, other menu components, ...) which are contained in parent menu classes. I don't actually want these parent classes to have helper methods (both because it is causing code duplication across the parent classes and because the parent classes shouldn't "care" or "know" about these serialization / deserialization details)

The easiest way (of course) would be to have centralized methods that take a "void *" pointer. That aproach would be easy to read but (owing to the "void *") a bit dirty. The "void *" would be a reference to each of the parent (menu) classes I need to work on.

Given that I have m things that I have to get parameters to and from (and I can only access them through the n parent menu classes), and the parameter lists can be different... can I really use Visitor for this? Is it the proper pattern to use?

Dan S
  • 355
  • 2
  • 15

2 Answers2

1

Visitor is definitely way to go. Using Visitor you can extend the functionality of class without having to modify it. The term "Visitor" apparently a misnomer and it has nothing to do with pattern, In-fact it is a very powerful pattern as it allows you to extend class from outside.
See this When should I use the Visitor Design Pattern?

Community
  • 1
  • 1
Abhishek Bansal
  • 5,197
  • 4
  • 40
  • 69
  • I've seen things claiming visitor is opaque because the calls can't be customized. The classic examples have accept() visit() as the only methods. Can I still use visitor if I have m things each of which I need to do at least 2 distinct operations on; add to that the fact that the parameter list might be radically different on some of these m things. Basically I need to do at least 2 * m things with a varying parameter list- can visitor do that? – Dan S Mar 18 '14 at 14:59
  • Actually it is worse than 2 * m. On my Buttons I have (so far) four operations (get & set for: location & value). Some of the menu components might have as few as 2 operations (get/set), others will be some higher even number. – Dan S Mar 18 '14 at 15:13
  • You can have as many overloaded `visit` functions as you want in visitor. Depending upon your argument list appropriate function will be called. – Abhishek Bansal Mar 18 '14 at 16:15
  • See this link also if it helps http://4thmouse.com/mystuff/articles/TemplateVisitor.html#N1002C – Abhishek Bansal Mar 18 '14 at 16:24
  • I'm not sure I understand how to apply the example. I suppose I could use an AbstractVisitor to make the parameter list flexible. I'd also like to have descriptive method names like getButtonValue() setButtonValue() getButtonLocation() setButtonLocation() rather than the standard "visit"/"accept"... I'm going to have a number of methods to create. Can I do that? – Dan S Mar 18 '14 at 18:05
  • Yes Sure Why not ?.. You can obviously give whatever function name you want. IF you see first answer in the link i provided in my answer function names are not accept/visit. – Abhishek Bansal Mar 18 '14 at 19:01
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/50023/discussion-between-dan-s-and-abhishek-bansal) – Dan S Mar 19 '14 at 11:33
0

Sounds like visitor fits the problem description, but it can be a bear to implement.

Assuming GUIElement is part of the hierarchy of objects you want to serialize, Manager figures how how to traverse those elements for the serialization order, and the Visitor class does the work of serializing, here's how I would see the dynamics of it based on your description:

Visitor sequence diagram

Diagram created here.

Community
  • 1
  • 1
Fuhrmanator
  • 11,459
  • 6
  • 62
  • 111
  • I like your userid... sounds like you serve cats. – Dan S Mar 19 '14 at 15:50
  • So it sounds like you're saying make helpers in each visitor that do the little actions I want (getButtonValue()) and each concrete visitor (serialize / de serialize) does the whole collection of them). – Dan S Mar 19 '14 at 17:16
  • @DanS The goal with the pattern is to encapsulate the ugly stuff into the Visitor and not have it in the GUIElements. If you get too many methods in a Visitor, you could refactor them into separate classes that collaborate with the Visitor. Once the Visitor is in control, a lot of things can happen. All these changes won't require coding anything in your GUIElements (in theory). – Fuhrmanator Mar 19 '14 at 21:58