Improved Radial Encapsulation

 radial   encapsulation  is a means of organizing java packages to minimize package-level  potential coupling  and  structural disorder  .

that idea is almost trivial.

oracle supplies the official term, "subpackage," when it  writes  , "the naming structure for packages is hierarchical. the members of a package are class and interface types ... and subpackages."

oracle does not define a "parent" package but genealogical terminology proves useful: thus given package structure  a.b.c  , we can say that  b  is the parent of  c  ,  a  is the grand-parent of  c  , and that, in general,  a  and  b  are both antecedents of  c  , and  b  and  c  are descendants of  a  .

radial encapsulation allows package dependencies only on antecedents.

thus in the example above,  a.b.c  could not depend on  a.d  , because  d  is not a parent, grand-parent, or any antecedent of  c  .

this constraint snubs oracle's anemic package mandates, by  which  , "... hierarchical naming structure for packages is intended to be convenient for organizing related packages in a conventional manner, but has no significance in itself." the constraint, however, heaves with it the tremendous benefit of allowing programmers to design package structures of arbitrarily low structural disorder. see figure 1 where the program on the right is radially encapsulated.

 figure 1: left structural disorder 76%; right structural disorder: 3%. 

to continue the example above, what if  a.b.c  does indeed require the services of  a.d  ? must we contort our package structure to squeeze  d  in as an antecedent of  c  ? of course not. we use the facade design pattern and have  d  export its interfaces into  a,  where those interfaces are then available to all.

that was classical radial encapsulation.

 steve mcduff   commented  , however, "as applications grow, this solution would force ... a lot of facades in common low-level packages to exist."

steve is, unfortunately, correct. radial encapsulation of large systems does encourage a certain ... bottom-heaviness.

so this post proposes a small improvement on radical encapsulation with the introduction of: the ground.

take any package and declare it the "ground parent." the ground is then the set of immediate subpackages of this ground parent, on which the guiding principle of radial encapsulation is loosened: this set of subpackages that may be depended upon by any descendant of the ground parent.

figure 2 presents a radially encapsulated structuring of the following 5 qualified packages:

1.  com.a.b 
2.  com.a.c.d 
3.  com.a.c.e 
4.  com.a.f 
5.  com.a.g.h 

 figure 2: a radially encapsulated package structure. 

in classical radial encapsulation, package  e  , for example, could not depend on  b  because  b  is not an antecedent of  e  .

with improved radial encapsulation, however,  e  can now depend on any of the ground packages (shown in green) and on packages  a  and  com  (both are antecedent). it cannot, however, depend on packages  d  or  h  , those packages being neither ground nor antecedent — encapsulation remains strengthened over and above oracle's defaults.

let's take a look at refactoring a classic radially encapsulated program into the updated variety.

figure 3 shows the package structure of  spoiklin soice  . a typical model/view/controller split, note that the neither the  model  nor  view  nor  controller  packages are antecedent to one another and thus for, say, the  controller  to use the services of the  model  , then  model  must export its interfaces into  link  or  spoiklin  (  com  ,  edmundkirwan,  and  base  were deliberately kept sparse).

 figure 3: a radially encapsulated package structure. 

this left  spoiklin  a little bloated: figure 4 shows these dependency lines (unlike figure 3, which shows hierarchy) with the thickness proportional to the number of dependencies.

 figure 4: dependencies in the program of figure 3. 

figure 4 shows another drawback of the old approach: the diagram fails to show which interfaces in  spoiklin  — whether exported from  model  ,  view  or  controller  — are most depended upon. which part of the system suffers most from change-sensitivity because so many others depend on it?

figure 5 presents the same system refactored to the improved radial encapsulation.

 figure 5: the new radial encapsulation. 

here,  spoiklin  is declared the ground parent and hence  model  ,  view  , or  controller  (and others besides) form the ground. the  controller  sub-tree of packages can now export its facades not into a common package but into the  controller  package itself, with other sub-trees similarly possessing their own dedicated ground packages. this both removes bloat and clarifies system dependencies, as shown in figure 6.

 figure 6: dependencies in the newly radially encapsulated system. 

figure 6 reveals that  model  is the most depended-upon package (and hence functionality) of the system. yet of course, as with classical radial encapsulation, all the  model  sub-tree of implementation packages are hidden from all the  view  and  controller  implementations, affording the system substantial flexibility.

summary

establishing a ground, that is, a set of packages that may be depended upon by any descendant of the ground parent, improves radial encapsulation's scalability.

which is good.