|
I assume your prefix for packages is given by your domain,
for example, jvalue.org. In the following, consider a growing
framework of classes that make up all the basic data types (value
types) in your domain like money, currency, percentage, etc.
With a small number of classes, make one package:
- org.jvalue.value; // all classes and interfaces
With a growing number of interfaces and implementation classes,
make two packages. One is the interface package, and the other
one is the implementation package. The implementation package
is subordinate to the interface package and therefore contained
within. Call it Impl:
- org.jvalue.value; // primarily interfaces
- org.jvalue.value.impl; // primarily classes
Add more implementation class packages if needed.
- org.jvalue.value; // primarily interfaces
- org.jvalue.value.Impl; // primarily classes
- org.jvalue.value.simple; // primarily classes
With a growing number of test cases, put them into a package
of their own. The test case package is also a subordinate package
of the interface package. Call it Test:
- org.jvalue.value; // primarily interfaces
- org.jvalue.value.impl; // primarily implementation classes
- org.jvalue.value.test; // all test cases for the implementations
in org.jvalue.value and org.jvalue.value.impl
Add more test case packages if needed.
For framework extensions using inheritance, provide a dedicated
extensions package called extensions:
- org.jvalue.value; // primarily interfaces
- org.jvalue.value.impl; // primarily implementation classes
- org.jvalue.value.test; // all test cases for the implementations
in org.jvalue.value and org.jvalue.value.impl
- org.jvalue.value.extensions; // provides all externally
provided add-ons
If you make a whole new extension of the framework, provide
a new package hierarchy in your own package structure. For example,
if you add your company specific basic data types, start all over
with a new hierarchy:
- com.mystartup.killerapp.value; // shhhttttt, it's top secret.
Proceed from here as illustrated above.
|