Is there any java pattern for package structure that justify the existence of the default visibility modifier?

Question

I understand "how packages should be structured" is very opinion based. But java contains a rule for default package visibility, so it implies that there is a specific reason or pattern, thought in the creation of Java, of how packages should be structured in an object oriented environment using object oriented principles.

I will use the Car Example, starting with methods using the default visibility:

com.company.car.Startup#main (public)
com.company.car.engine.CoreEngine#rotate (default)

At first glance, all methods are semantically supposed to be initially declared as default (in this case except the main() which is the point of entry and should be public).

Ok, now Startup#main need to call the CoreEngine#rotate method when I start the car. But I don't want to expose that rotate() method publicly when somebody uses the CoreEngine for things other than internal purposes (like calling CoreEngine#turnEngineLightOn from a remote control device outside the car).

But... the rotate() method has a default visibility which is package restricted, It is inaccessible from main() method too!

In this case, I have few options:

• Turn the CoreEngine#rotate method public and rely on duck typing
• Change the package of the Engine class

I understand in practice that this is not how a real life project should consider the packages role in the design of a project. So does it mean that default visibility is something practically useless semantically? Is this a language failure or there is a design pattern to handle a project structure that solves this semantics problem?

Does a pattern like this really exist? If so, is it documented? Can you provide some real life examples using object oriented code?

Answer 1

Try to have a look at Item 13 Minimize the accessibility of classes and members of Joshua Bloch's book, Effective Java. As the item's title said, the accessibility to your classes and methods has to be stricter as possibile.

So, if you're creating an API, you could use default package visibility for classes and methods that you don't want external components can use.

I think that there is not need of a specific pattern, but there is a need of a good design process. In your example I think there is a design problem, that is: you have two classes too tightly coupled, Startup and CoreEngine that are not in the same package.

As you stated, you can't simply unite Startup and CoreEngine into one single class, because you will violate the Single responsibility principle.

I think you should revise your use case and ask yourself what operation must be available to your user. In this way, you define which will be public methods. IMHO you have three possibilities:

1. Following what is said here;
2. Try to think about to use inner classes;
3. Let unchanged the whole diagram of classes and give to your API user the javadoc of really public classes.

With respect to point 2. I suggest to have a loot at this page: Nested Classes. As reported in the article, compelling reasons for using nested classes include the following:

• It is a way of logically grouping classes that are only used in one place: If a class is useful to only one other class, then it is logical to embed it in that class and keep the two together. Nesting such "helper classes" makes their package more streamlined.

• It increases encapsulation: Consider two top-level classes, A and B, where B needs access to members of A that would otherwise be declared private. By hiding class B within class A, A's members can be declared private and B can access them. In addition, B itself can be hidden from the outside world.

• It can lead to more readable and maintainable code: Nesting small classes within top-level classes places the code closer to where it is used.

Do you think that a solution like the following could solve your problem?

// Class Car provides the public API to interact with a car, but
// it delegates the specific functionalies to its inner classes.
public class Car {
   private Startup startup;
   private CoreEngine core;
   // ...
   private class Startup {
      // The class can access to 'core', then it can 
      // invoke rotate() method
      public void main() { /* ... */ } 
   }
   private class CoreEngine {
      public void rotate() { /* ... */ }
   }
}

What is missing in Java is the possibility to nest scopes. In Scala and Js you can do it.