I have three classes that work together to do one function (from the perspective of the rest of my program). There is a little bit of set up between them, so, to make it easier for the rest of my program, I grouped them into:

  • ListManager: object, which initializes them to the right values when it is constructed. The three objects it stores are:

    • Timer:
    • TriggerManager: basically a wrapper around an ArrayList that manages Trigger objects
    • CueList: a linked list with the usual getters and setters that come with that.

Since the rest of my program is only interacting/referencing the TriggerManager class, should I write wrapper methods for the objects it manages?

  1. So should I make ListManager.add(Cue c) as a wrapper for CueList.add(Cue c).
  2. OR should I just add getters for the three objects and let the rest of my program use that to manipulate them.

I tend to think that the later option is far more maintainable, but at the same time, the code produced if I make the wrapper just seems... prettier...

What's the best practice in situations like this?

  • I reformatted your example a bit, to help visually clarify it; however, I think there might be a couple points that need to be technically sorted out in your example. Is the ListManager actually the TriggerManager, and should the second of three items being stored, the TriggerManager, instead be a Trigger? – JustinC Jun 8 '13 at 5:59
  • Why is the latter option far more maintainable? I'm not an expert by any means, but the former seems like the natural choice for me. – Steve P. Jun 8 '13 at 16:40
  • @SteveP. Because every time I add another method to one of the classes or change an argument, I'll need to update the other class as well. – sinθ Jun 8 '13 at 17:26
  • @MikeG, okay, that makes sense. What exactly do you mean by "getters?" – Steve P. Jun 8 '13 at 17:30
  • @SteveP. As in "Getters and Setters"? It just means ways of accessing instance variables through methods. stackoverflow.com/questions/1568091/why-use-getters-and-setters – sinθ Jun 8 '13 at 17:37

It depends on the kind of abstraction you want to achieve with your ListManager. If your ListManager is just a data tuple of 3 independent objects, the "wrapper" approach is pointless. If it provides an abstraction on it's own, because the the 3 objects are not independent from each other, then you should use specific accessor methods.

For example, do you want the rest of your program to get full control over the ListManager.CueList? And does this not introduce any specific pitfalls for the user of your ListManager? Then add a public getter for the CueList.

Or is it better when the rest of your program gets only restricted access to ListManager.CueList (for example, to allow only a specific subset of the CueList methods to be called like CueList.add)? Might this prevent any unintentional errors? For example, must CueList.add be always called in conjunction with some additional operations? Then use the ListManager.add(Cue c) approach.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.