1

We are creating an android library for use with Android. That means an Eclipse-like IDE and an Ant-like build process.

The nature of the library is that it has two distinct parts, representing different levels of abstraction - let's say 'upper' and 'lower'.

Assume, for the purposes of this question, that we need to call methods in one part from the other, but would like to keep those methods hidden from the library user. I've scoured the usual references but they all stop at the point of explaining package name conventions and scope rules. I've failed to find anything that answers this on SO, though this was useful.

The immediate solution is to simply have everything in one package and for those methods to be package-private. However, for reasons of maintainability, clarity, and not-having-100-files-in-one-folder we'd prefer to split the parts into different folders.

The obvious splitting point is to split the (let's say 'wibble') package into com.me.wibble.upper and com.me.wibble.lower packages/folders, but that makes any interconnecting methods undesirably public. In mitigation they could be hidden from the javadoc with @hide.

Another thought is whether could we split the parts at the top level and instead of the classic /main and /test folders have /upper, /lower and /test and all parts share the same com.me.wibble namespace. I'm unsure if/how Eclipse would cope with that.

Is there a conventional way of doing this, or is it just not done? If there are ways, what are the pro's and con's?

Community
  • 1
  • 1
Cheeseminer
  • 2,948
  • 1
  • 20
  • 36
  • Have you considered using [reflection](http://docs.oracle.com/javase/tutorial/reflect/)? With it, you can keep all of your methods private, but keep your code in separate packages. – Bryan Herbst Oct 24 '13 at 16:49
  • Akk! There's nothing private about reflection! http://tutorials.jenkov.com/java-reflection/private-fields-and-methods.html – Pedantic Oct 24 '13 at 19:57
  • @Tanis I'd not considered reflection. My background is C (which wouldn't have this original problem ;-) so I was looking for a 'normal' solution, but thanks for the suggestion; and the warning, Pedantic. – Cheeseminer Oct 25 '13 at 08:21

1 Answers1

0

hmmm......Instead of asking for the solution, sometimes it is better to give the question. WHY you want library users to have a restricted view may generate a better answer than the HOWTO. There are a few answers I thought of but didn't give because I don't know the motivation behind the question (I don't want to waste your time with an answer that is not applicable).

/upper,/lower/,/test doesn't make your situation any nicer. It just makes the project more organized. Whether they are all in the same folder or separate it doesn't affect much.

It sounds like you need public 'interfaces' for library users while having private 'interfaces' for your own use. This is possible with hacking but can be painful if this is large pre-existing collection of code.

Lan
  • 1,206
  • 1
  • 11
  • 26
  • The basic motivation behind why I want to give restrict users' view is as presented in Effective Java - "the single most important factor that distinguishes a well designed module is [how well] it hides it's internal implementation.". However, that isn't really the right question :) The right question is why do I want to separate two units that -could- be coded as one module? The motivation is to help us keep the logical separation clean: coding as one module could lead to muddled interaction between the units. You can regard this code as a new creation: it's a major refactor/rewrite. – Cheeseminer Oct 25 '13 at 08:16
  • @Cheeseminer Joshua Bloch has a book, a thesis, and a few presentations on designing (library ?) APIs. If this is a super critical task, you may considering looking into the literature. My advice is to make everything, even many classes, package private by default. Your upper/lower/test folders can share namespaces. Reducing package dependencies can be a boost in your design in the long term but may be very painful in the short-term. To expose your classes to the outside world, there is the Factory patterns & interfaces. – Lan Oct 29 '13 at 14:58