Declaring classes/interfaces as non-public
Going further, we can declare interfaces/classes as non-public (by skipping the public keyword from the class/interface definition it becomes non-public and is set by default in the so-called package-private access mode). This way, those classes, and interfaces are visible (can be used/extended) only inside their packages. We cannot apply this technique to the ElectricComponent interface. This interface has to be public because is implemented by most of our classes. However, we can apply this technique to the ElectricBreaker interface, since this interface should be implemented only by ElectricPanel class which is in the same package as it:
interface ElectricBreaker extends ElectricComponent {}
Now, ElectricBreaker cannot be extended/implemented outside its package. Moreover, we can apply this technique to the abstract classes Transistor, Resistor, and Capacitor:
abstract class Capacitor implements ElectricComponent {}
abstract class Resistor implements ElectricComponent {}
abstract class Transistor implements ElectricComponent {}
Notice that we cannot apply this technique to the ElectricCircuit class. This class is abstract but it is used in the ElectricPanel class, so it cannot be non-public. However, it cannot be extended thanks to the package-private constructor added previously.
Throwing everything in a module
In addition, we can place the whole hierarchy inside a Java module and export/expose to our client only a small part of it. However, this will not affect the closing level from inside the module, so wil skip it.At this moment almost the entire hierarchy is closed to extension/implementation. The exceptions are the MetalResistor class and the ElectricComponent interface which can be extended/implemented from anywhere inside/outside the model, and the ElectricCircuit, Capacitor, Transistor, and Resistor classes which can be extended only inside of their packages. By placing the model in a Java module, we can block these actions from outside the module, but they are still possible from inside the module.
Conclusion
From this point forward, there are no more techniques, tricks, or hacks that we can apply. We can reconsider the model design, but this will be too costly and will basically mean redesigning for closing the model which may affect the model structure and logic.For the sake of discussion and in the context of redesigning, we may consider Java enums. Java enums give us a nice closed hierarchy and are transformed internally in regular Java classes. Nevertheless, using enums to design a closed model and shape arbitrary classes can be really weird, unwieldy, and inconvenient.In conclusion, before JDK 17, we have the radical final modifier and some control at the package level via package-private access.It is obvious that what’s missing here is something in between, something to give us more granularity and control. Fortunately, JDK 17 can help us to achieve a 100% closed hierarchy via Sealed Classes, but this is the topic of the next problems.
