4

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?

Improve this question
6
  • 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? Commented Jun 8, 2013 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. Commented Jun 8, 2013 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. Commented Jun 8, 2013 at 17:26
  • @MikeG, okay, that makes sense. What exactly do you mean by "getters?" Commented Jun 8, 2013 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 Commented Jun 8, 2013 at 17:37

2 Answers 2

Reset to default
1

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 its 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
0

Leading question is: what methods need to be available for the encapsulated fields?

When using collections the practical solution is the second one:

OR should I just add getters for the three objects and let the rest of my program use that to manipulate them.

...since there is a considerable number of methods the collections support (e.g. contains, iterator, size) that most probably get used by the caller code. Even when there are methods that should be unavailable for the encapsulated Collection fields the second solution is the practical one with a slight change of the getters returning unmodifiable collections returned by java.util.Collections's methods prefixed with unmodifiable.

For a different type of fields (different from Collection type) and with the requirement of refining the visible methods of the encapsulated fields wrapper methods most probably are preferred, depending on the use cases.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.