DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Securing Your Software Supply Chain with JFrog and Azure
Register Today

Trending

  • Microservices With Apache Camel and Quarkus
  • Understanding Dependencies...Visually!
  • Microservices With Apache Camel and Quarkus (Part 2)
  • Microservices With Apache Camel and Quarkus (Part 3)

Trending

  • Microservices With Apache Camel and Quarkus
  • Understanding Dependencies...Visually!
  • Microservices With Apache Camel and Quarkus (Part 2)
  • Microservices With Apache Camel and Quarkus (Part 3)

Improved Radial Encapsulation

Putting more focus on your dependencies and how they relate can drastically improve scalability and flexibility. Start with a ground package and work from there.

Edmund Kirwan user avatar by
Edmund Kirwan
·
Dec. 14, 16 · Tutorial
Like (6)
Save
Tweet
Share
9.71K Views

Join the DZone community and get the full member experience.

Join For Free

 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: two java package structures

 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

 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

 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: spoiklin diagram of spoiklin soice

 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: a newly radially encapsulated package structure

 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: spoiklin diagram of spoiklin soice

 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.

Encapsulation (networking)

Opinions expressed by DZone contributors are their own.

Trending

  • Microservices With Apache Camel and Quarkus
  • Understanding Dependencies...Visually!
  • Microservices With Apache Camel and Quarkus (Part 2)
  • Microservices With Apache Camel and Quarkus (Part 3)

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: