Keep your implementations hidden

Most Java applications I have worked on the last years embraced the "Program to Interfaces" principle. The name is rather self explanatory so I won't go into detail in the principle. As interfaces by itself are quite useless we need to have at least one implementation. In a typical application this is done by a defining a class such as:

public class JbcAddressDao implements AddressDao {
}

Nothing wrong here one might say, but I think that this code is in conflict with one of the main aspects of Object Orientation.

At QCON London 2006 Martin Fowler mentioned that one of the main aspects of OO is "Keeping secrets from each other". Since we defined the concrete implementation as public, the JdbcAddressDao is exposed to the outside world. There is nothing to prevent client code to use the implementation rather then the interface and therefor we loose our secret.

One way of dealing with this is that we could declare the constructor package private or protected. This will prevent client code from instantiating a JdbcAddressDao (in a real application the instantiation is probably done by a container like Spring which can handle package private and protected constructors), but the client code is still able to cast the interface to the concrete implementation. So this is a small improvement but still it exposes too much.

To really prevent client code to use a JdbcAddressDao we should declare it as package private. This way we are sure that no one outside our package can use our class. This does require that the implementation and interface are in the same package, which actually makes sense since implementation and interface are kind of related anyway. Containers like Spring can still instantiate package private classes and otherwise you could define a Factory to instantiate JdbcAddressDao and return it as a AddressDao.

I think when we are more careful in which access modifiers we use for implementations we are able to create more robust applications and are one step closer to OO heaven :-).

Comments (4)

  1. Erik Rozendaal - Reply

    October 10, 2007 at 9:20 am

    AFAIK making the implementation package private does not require the implementation and interface to be in the same package. This makes sense, because in a DDD design you may want the interface to be part of the domain, while the implementation is part of the integration layer in a separate package.

    But structuring your packages in such a way that many interfaces/classes can remain package private is definitely a good thing!

  2. Lars Vonk - Reply

    October 10, 2007 at 9:29 am

    Hi Erik, yYou are of course right. Thanks for spotting that. It indeed does not require an implementation to be in the same package as the interface. I guess that is what happens in you post blogs in the late evening....

  3. Peter Veentjer - Reply

    October 10, 2007 at 10:23 am

    Hi Lars,

    I have been on the road of making everything as strict as possible and code quality usually doesn't improve (you don't have subpackage visibility for example). I would rather rely on good coding standards (like programming to interfaces) instead of enforcing it with the very limited mechanism's we have for visibility in Java.

  4. Peter Veentjer - Reply

    October 10, 2007 at 4:13 pm

    The following link is a nice read and maybe a better solution than the current approach:

    http://www.infoq.com/news/2007/10/java-modularity-ijam

Add a Comment