Question

I have a manager class that is responsible for managing Objects of a certain kind. To do so it needs to manipulate these Objects, but these Objects have no relation to the manager whatsoever, so design technically, they are in separate packages “project.managers” and “project.objects” . The important thing is that the Objects in question should only be manipulated by the managers and nowhere else, but need to be accessible by every other class in the project.

As such I’d like to have the managers have access to manipulating methods, but restrict access to every other class. The most obvious one would be to move the manager class and object class into the same package and declare manipulating methods protected, but as the managers and objects are completely separate entities they don’t fit there philosophically.

(This is partly because I want my IDE to stop showing me the manipulating methods whenever I autocomplete code on the Objects in question so I always have to go the route through the manager so corresponding tables are correctly updated whenever I change the Objects in question).

Are there any ideas to that or is the obvious way the best in any case?

Answer 1

Why not have an interface called

ManagerFunctions

and another called

ClientFunctions

You managed objects will implement both of these.

When you create the managed objects, you pass them around, but only as references to ClientFunctions. The manager objects will, however, refer to them as ManagerFunctions and consequently have access to their ‘managed’ functions. The appropriate casting will simply expose the appropriate methods.

Your IDE will automatically present you wil the appropriate methods depending on how these objects are referenced.