Skip to Content
When designing software, a strong decoupling and least possible complexity is desirable when having stability, readability, maintainability and extensibility in mind. Object oriented languages feature this purpose by restricting the visibility of their entities to a defined scope. Decoupling as well as reducing complexity means mainly to use the strictest scope possible for the entities. Another feature used in object oriented language for that purpose is the grouping of entities within other entities (like classes or packages) and possibly reducing visibility to these. Some patterns suggest grouping an application in even larger entities than is featured by a language – like layers or maybe the well known MVC pattern. Many of these patterns require that the incorporated entities (like neighbouring layers) have some knowledge about each other but some should be hidden to other entities of the same level (as between non-neighbouring layers). This introduces some difficulties when trying to arrange these entities in packages: The mutually known parts have to be made public – and thus are visible to parts of the application where they should not. Even worse – if you are writing an API parts become exposed where you don’t want them to be exposed to the public. This can render enhancements or redesign difficult or impossible at all. One can come around this restriction in some way by letting the entities only communicate by interfaces and some public factory classes/methods but even this creates a published API which cannot be altered easily.
A solution I thought about would be to enhance the language such that it is possible to arrange the package in a hierarchical way and to control access between the ordered packages. In some way it is analogue to the friends concept of C++, but one can control access more fine grained than possible there. The enhancement could be defined as follows:

  1. Introduction of a new keyword like eg. exportto packagename which is defined in the header of a class in analogy to the import statements. The packages defined here have access to the members as defined in the next section. I am currently not sure if it could be an advantage that all classes in a package MUST have equal exportto statements thus rendering the entire package exported to another package.
  2. Introduction of a new keyword like eg. exportprivate as modifier to members. These members are exposed accessible to the members of the packages defined in the previous section. These members are packageprivate as well. Protected members are not exported (as in my opinion they neither should be packageprivate as they are today).

These enhancements would offer several opportunities. First, one can arrange packages hierarchical by exporting the sublevel packaged classes to the toplevel package. The classes in the subpackages can be hidden entirely from the API. Second, one can arrange higher level entities such as layers in a way that only a minimal set of classes or members of one entity are visible to another entity. As an example one can make members only visible between neighbouring layers making a cross-layer reference impossible. Or in an MVC pattern it would be possible to put Model, View and Controller each in a separate package (and thus to hide their implementation details from each other) and to expose only the Controller package to the outside application.

Another point I personally find quite annoying is that interface members behave different by default compared to class members. Interface members with no (=default) modifier are intrinsically public whereas class members with no modifier are package private. Since it is possible (and makes sense in my opinion) that interfaces themselves are defined package private it should be possible to do so for their members as well. As an example lets assume an API where you expose a bunch of objects to the outside. Some of these objects can be persisted in some way, but this behaviour should be unintentional for a client of the API. Therefore you would like to mark these objects with some non-public interface which asks for a method save() which can persist the object (thanks to Michael for this striking example). Obviously one does not want to make this method public which is currently enforced even by a package private interface. There can be many reasons why you do not wish or you are not able to introduce an abstract class in your class hierarchy as an alternative. Interestingly, the developers of Java themselves broke this rule by introducing the interface Serializable, which carries implicit methods which can be overridden (readObject(ObjectInputStream) and writeObject(ObjectOutputStream) which both are defined private). Although one can consider Serializable as some abstract class where the definition as interface overrrides the lack of multiple inheritance… As a result I would find it quite useful that at least package private interfaces can have package private members. If there is an export mechanism to come like the one described above, this level of definition should be possible for interfaces as well, of course.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply