Java back-door interface, or, restricting method access by calling object

Question

I'm using Java. I want to have a setter method of one class that is only accessible to an "owning" object of another class. I'll be more specific:

I have Node and Port interfaces. Every node has a set of Ports, and each Port belongs to a single Node. A Port may be enabled or disabled, handled with a simple boolean property. However, I only want to allow the Node that "owns" the Port to set its enabled/disabled property. This should happen when Node.fixYourPorts() is called (OK, it has a different name, but I'm trying to simplify).

So, I want everybody to be able to call port.isEnabled(), but only the owning Node should be able to call port.setEnabled().

I can think of a few ways to do this, but I'm not sure which is best, and I'm concerned that I may be thinking about this problem the wrong way. Ideas so far:

1. Each Node implementation would need a matching Port implementation in the same package, and PortImpl.setEnabled() would be package-access. Doesn't guarantee that one Node won't change another Node's Ports, but that's close enough for me. The Node code is much more under my control than any random client code that may get a Port instance.

2. Instead of programming to the interface Port, program to an abstract base class, AbstractPort which is a static nested class inside the interface Node. This base class would provide the setter method, so then Node implementations could call it. Not sure if this would even work.

3. Write another layer of code on top of all of this that the client would not be able to poke through. Add setEnabled to the Port interface. The layer of code on top would make sure the setter is not exposed.

4. Add the setter to the interface. If you as the client enable or disable a port yourself, then you need to be prepared for things to not work correctly. Add a comment to this effect.

This is all complicated by the fact that Node and Port implementations will be persisted to a DB using Hibernate.

Any help?

Answer 1

Can you expose the Port to client classes, and expose it to the Node object with an additional interface providing the setter method ? e.g. the component constructing it will create a (say) ConfigurablePort (extending Port) and pass this to the Node, but pass the Port back to the client as a mere Port.

interface ConfigurablePort extends Port {
   void setValue();
}

// in some factory... Or perhaps in the Node itself?
public Port createPortForNode(Node node) {
   ConfigurablePort port = new Port();
   node.setPort(port);  // as Configurable
   return port; // as immutable
}

So you're not worried here about packaging issues, and you avoid the headache of having to implement methods (even to throw an exception) that you don't want to.

Answer 2

For the users of Port that should have the lesser access, expose the object with an interface that only supplies certain methods.