package name

[GuyBrush Treepwood]

Maybe this is a strange question, but how to decide how to call packages
you implement.
I have a BeanClass Folder, that is in com.threepwood.bookmarked.domain .
I want to implement a comparator for these kind of objects.
Should the FolderCompator go in com.threepwood.commons.util.comparators
for example? How to choose a good name, consistent with the
standard classes.

 

[iamfractal]

Hi, GuyBrush!

An excellent question, one which goes to the heart of your
encapsulation strategy.

Firstly, if your FolderComparator is only available to classes with
com.threepwood.bookmarked.domain then it should be put in there,
package-private (default access specifier).

Only if it's also available for use within other packages might it be
placed outside com.threepwood.bookmarked.domain, so for the rest of
this discussion, we'll assume that it is required by other packages.

Next, do you practice any correlation between a package's location in
its package hierarchy and its visibility to other packages? If you do
not, then you can put in any other package you like, as you package
visibility to be indepepent of its hierarchical position. If this is
the case, then go ahead an put your class in
com.threepwood.commons.util.comparators.

If you do, however, employ a visibility/hierarchy philosophy, then this
philosphy will dictate a subset of all the system's packages in which
this FolderComparator may reside. If, for example, you decide that a
package is only visible to its hierarchical peers, and the leaf-wise
descendents of those packages, then this will dicate that
FolderComparator may only be placed in:
A) com.threepwood.bookmarked.domain itself,
B) a peer of com.threepwood.bookmarked.domain,
C) A root-wise antecedent of com.threepwood.bookmarked.domain or its
peers.

Such philosophies can increase a system's flexibilty and similarly
reduce impact propagation.

..ed

www.EdmundKirwan.com - Home of The Fractal Class Composition.

 

[GuyBrush Treepwood]

Hi, GuyBrush!

An excellent question, one which goes to the heart of your
encapsulation strategy.

Firstly, if your FolderComparator is only available to classes with
com.threepwood.bookmarked.domain then it should be put in there,
package-private (default access specifier).

It should mainly be available in com.threepwood.bookmarked.presentation

Only if it's also available for use within other packages might it be
placed outside com.threepwood.bookmarked.domain, so for the rest of
this discussion, we'll assume that it is required by other packages.

Next, do you practice any correlation between a package's location in
its package hierarchy and its visibility to other packages? If you do
not, then you can put in any other package you like, as you package
visibility to be indepepent of its hierarchical position. If this is
the case, then go ahead an put your class in
com.threepwood.commons.util.comparators.

I think my FolderComparator would only be of use in
com.threepwood.bookmarked.* . Would that imply that it should also be
defined somewhere in this hierarchy? And so yes, where exactly,
com.threepwood.bookmarked.common.FolderComparator ?

 

[iamfractal]

It should mainly be available in

com.threepwood.bookmarked.presentation

That word, "Mainly," confuses me a little. Golden Rule: classes should
be as encapsulated as possible. If FolderComparator is *only* available
to other classes within com.threepwood.bookmarked.presentation, then it
should be declared in that package with the default accessor.

If it is *also* used by classes outside that package then you have two
choices, both of which are perfectly acceptable:
1) Put it in the package where the majority of its client classes
reside.
2) If you have package dedicated to holding common classes (as you
suggest with your original post) then put it in there.

I've seen both in professional code; both are fine.

(As an aside, the reason why both are acceptable is that Java class
visibility is (ignoring inner classes) package-private or
system-public. If Java had an accessor which allowed a class to be
public to a restricted number of packages, then this would probably
dictate where you could place the class; it is precisely this level of
intermediate visibility that is offered by the visibility/hierarchy
philosophies mentioned previously.)

I think my FolderComparator would only be of use in
com.threepwood.bookmarked.* . Would that imply that it should also be
defined somewhere in this hierarchy? And so yes, where exactly,
com.threepwood.bookmarked.common.FolderComparator ?

You seem not to be employing a visibility/hierarchy philosophy, so you
are free to declare FolderComparator anywhere you like.

But if you *were* employing such a philosophy, then that would have
restrained where the class could be declared.