Question

I’m hard at work packaging up an API for public consumption. As such I’m trying to limit the methods that are exposed to only those that I wish to be public and supportable. Underneath this of course there are a multitude of limited access methods.

The trouble is that I have a lot of internal code that needs to access these restricted methods without making those methods public. This creates two issues:

• I can’t create interfaces to
  communicate between classes as this
  would make these my internal methods
  public.
• I can’t access protected or default
  methods unless I put the majority of
  my internal classes in the same
  package.

So, I have around 70 or 80 internal classes in cleanly segregated packages BUT with overly permissive access modifiers. Would you say that a single package is the lesser of two evils or is there a better way to be able to mask my internal methods whilst keeping more granular packages?

I’d be interested to find out the best practice here.

I’m already aware of This

Answer 1

There are two solutions to your question that don’t involve keeping all classes in the same package.

The first is to use the Friend Accessor/Friend Package pattern described in (Practical API Design, Tulach 2008).

The second is to use OSGi. There is an article here explaining how OSGi accomplishes this.

Related Questions: 1, 2, 3, and 4.