4

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?

DPM
  • 1,960
  • 3
  • 26
  • 49
salbeira
  • 2,375
  • 5
  • 26
  • 40

3 Answers3

4

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.

Brian Agnew
  • 268,207
  • 37
  • 334
  • 440
  • I already thought about "API-ficating" my project to a collection of interfaces with a bunch of implementations to make extending the basic ideas behind it easier. This might be the kick to start actually doing it. – salbeira Nov 19 '12 at 14:55
0

You're asking for something akin to the "friend" declarations of C++, but there's no direct equivalent in Java - package visibility is the nearest. Alternatively you could go for a model like the XML DOM, where the methods that should be public are defined in interfaces and all client access is via these interfaces. The manager would know the concrete class of the implementation so could downcast to that as required.

Ian Roberts
  • 120,891
  • 16
  • 170
  • 183
0

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...

Technically, you would declare the manipulating methods package protected (no modifier at all). Protected methods allow the class to be extended easier.

but as the managers and objects are completly seperate entities they don't fit there philosophically.

I understand. Java doesn't have the "friend" declaration that C++ has.

You could comment the manipulating methods, but that doesn't solve your Eclipse problem.

Gilbert Le Blanc
  • 50,182
  • 6
  • 67
  • 111