Should my internal API classes be all in one package?
- by Chris
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
