Netty: Probably the Best Package Structure in the World
When it comes to dependencies and package structures, Netty is probably second to none. See what makes it so great and the encapsulation lessons you can take away.
Join the DZone community and get the full member experience.Join For Free
netty 's package structure is fantastic.
every programmer should study it; every system should mimic it; every project manager should print it out, slap on a wall, and say to developers, "that."
netty is an, "... an asynchronous event-driven network application framework for rapid development of maintainable high-performance protocol servers and clients," but that doesn't matter here, as we are not analyzing its behavior. instead, behold figure 1.
figure 1: netty's package structure evolving over 7 years.
figure 1 presents a spoiklin diagram (circles are packages; straight lines are down-the-page dependencies; curved lines are up-the-page dependencies) of netty's evolving package structure, and if you can't see immediately how well-structured it is, then take a peek at junit , struts , or ant .
nor is it merely the case that, "good structure is in the eye of the beholder." structural disorder offers an objective measurement of how poorly a program is structured: the lower the structural disorder, the better the structure. netty's disorder lies far below almost all others, see table 1.
|program||package structural disorder|
table 1: structural disorder of all programs reviewed in this series.
what's more, figure 2 shows how this final structural disorder is no accident. netty's structural disorder has been low throughout its seven-year lifetime.
figure 2: netty's structural disorder through 11 releases (with others for comparison).
so, why is this package structure so good?
given a diagram like figure 1, we can ask two quick questions to evaluate — loosely — the depicted structure's merit.
in commercial software development, "good structure," simply means, "cheap to update." furthermore, evidence suggests what every programmer with a grasp of ripple effects knows: the more things x depends on, the more likely will be impacted by ripple effects and hence the more costly x might be.
thus, pick a package that heavily depends on others and ask:
can we easily identify the depended-upon packages, and
how small a subset of the whole are these depended-upon packages?
badly structured programs obscure these dependencies, and scrutiny often reveals dependencies on almost the entire system. well-structured programs, however, clearly present the depended-upon packages and they are few.
let's ask these two questions first of a badly structured program.
figure 2 shows the nightmarish 90% structural disorder of jenkins , and then shows the highlighted transitive dependencies from the five packages (tool-tipped) that depend most on others.
figure 2: jenkins, oh jenkins.
tracing dependencies in jenkins clearly ... poses a challenge, with many packages depending on over 75% of the rest of the system.
figure 3 repeats the experiment, showing the transitive dependencies from the five netty packages that depend most on others: epoll, spdy, websocketx, http and nio .
figure 3: highlighting (in blue) the worst transitive dependencies in netty.
in striking contrast with jenkins, we can see the netty packages depended upon — and how few there are. netty has 55 packages, but the maximum depended upon by any other is just 12. that's just 22% of the system.
is netty's package structure perfect? of course not. particularly, the circular dependency between internal and concurrent creates regrettably strong coupling in that core internal/concurrent/channel/buffer/util package cluster.
looking beneath the surface, indeed, netty's class structure is bad. netty's designers apparently abandoned some of their excellent structural principles when they built their class-level. a shame.
but looking at that package structure ... wow.
finally, instead of analyzing netty's crucial releases, an architectural observation presents itself. netty's architects seem to have decided upon a rather brilliant deployment strategy. downloading netty gives you both an all-in-one jar file, but also 13 jar files that contain the separate parts of the system. presumably, you can load all netty or just the parts of it that you want.
one jar file, the "common" jar, houses the internal/concurrent/channel/buffer/util package cluster, whereas others hold, for example, "codec", "tcnactive", "transport", etc., suggesting that these latter jars are clients of the common jar but are not clients of one another and so have no dependencies on one another. thus, in their very deployment, netty's designers may have enshrined the separation and encapsulation of their sub-systems that has led to this industry-beating package structure.
the only remaining question is: why don't more projects follow netty's lead? why does jenkins have a 90% structural disorder? why didn't jenkins' designers properly partition their system to reduce inter-package coupling? why does the software development field so willingly accept the costs that these poor structures generate?
aren't we better than this?
if there were an annual award for the best java package structure in use today, netty would have won it seven years in a row.
Opinions expressed by DZone contributors are their own.