Feeds

Building cohesion into programming

Time is of the essence

Top three mobile application threats

There are many reasons for getting cohesive.

The principle of locality, which is normally considered with respect to locality of reference when using resources such as memory, can also apply to the organisation of APIs and classes and the partitioning of packages, components and header files. This criterion for cohesion is based on the idea that things that are used together belong together.

Popular as the practice appears to be, it makes little sense to bundle all of your exception classes into a single package named exceptions or all of your compile-time constants in a single header file named "constants.h".

The cohesion is coincidental and doesn't reflect how the code is used or what it means: If usage of a particular class can result in a specific exception, why is the exception not defined close to the class? If you need a particular constant, such as a service name, why should that also bring in unrelated constants, such as a default buffer length?

It turns out that there is in another criterion that can be used to arrive at the same conclusion in this case: stability. Or, put another way, put things together that change together. The change in question is not runtime change but development-time change: the change that code endures over the software lifecycle.

The other side of the partitioning coin from cohesion is coupling, and stability also applies here: a unit (function, class, header, package, layer, etc) should ideally depend on units that are more, not less, stable than itself. Put simply: prefer to build on solid ground.

In the case of the exceptions package, all the feature packages whose classes need to throw exceptions that are defined in the exceptions package depend on the exceptions package, as do the users of the feature packages. This is likely to make the exceptions package one of the most, if not the most, heavily depended upon packages in a system.

Unfortunately, it is also likely to be one of the least stable: any new exception for a feature package will affect the exceptions package, as will the addition of any new feature package that needs new exception types. This conceptual instability can manifest itself concretely if the compiled classes for lower layers are deployed separately from those that are higher up, i.e. placing the code for application features in one JAR file and the code for so-called utility classes, such as exceptions, in another.

The same problem exists for a "constants.h" header, but the churn problem shows up sooner during the compilation–link cycle: every time the header file is modified, a rebuild is triggered, regardless of whether or not an including source file depends on the constant in question. Changing a default buffer length will still cause a rebuild for files whose only interest is in a service name. So the lack of cohesion, from the perspective of common use, makes changes more likely: it reinforces the lack of cohesion from the perspective of stability.

The solution in both cases is to split up the package and the header and relocate their constituent parts according to the features they relate to.

In the case of the constants, there is one more refinement that can further reduce coupling and isolate change... but we'll discuss that another day.

Maximizing your infrastructure through virtualization

More from The Register

next story
Apple fanbois SCREAM as update BRICKS their Macbook Airs
Ragegasm spills over as firmware upgrade kills machines
HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
Don't panic though – Apple's backdoor is not wide open to all, guru tells us
Mozilla fixes CRITICAL security holes in Firefox, urges v31 upgrade
Misc memory hazards 'could be exploited' - and guess what, one's a Javascript vuln
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Captain Kirk sets phaser to SLAUGHTER after trying new Facebook app
William Shatner less-than-impressed by Zuck's celebrity-only app
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
EU dons gloves, pokes Google's deals with Android mobe makers
El Reg cops a squint at investigatory letters
Chrome browser has been DRAINING PC batteries for YEARS
Google is only now fixing ancient, energy-sapping bug
prev story

Whitepapers

Top three mobile application threats
Prevent sensitive data leakage over insecure channels or stolen mobile devices.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Top 8 considerations to enable and simplify mobility
In this whitepaper learn how to successfully add mobile capabilities simply and cost effectively.
Application security programs and practises
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
The Essential Guide to IT Transformation
ServiceNow discusses three IT transformations that can help CIO's automate IT services to transform IT and the enterprise.