Let's get cohesive

Biting into sound principles

The Power of One Brief: Top reasons to choose HP BladeSystem

To sharpen our concept of cohesion a little more, we can draw on another criterion, which is that of common use: if you're going to use one feature of a cohesive module, you should be just as likely to use another. In other words, move things together that are used together and separate those that are not.

This is not a question of whether or not an application as a whole would or would not use a set of features together; but whether one of its parts would. You may also recognise this co-dependency approach by another name: normalisation. An application may use both threading and file I/O functionality, but it is not inevitable that a class in that application that depends on using threading, will also depend on using file I/O. Threading and file I/O stand out as obvious and separate candidates for common use, and so each represents a separate cohesive concept.

By contrast, a not uncommon habit on C projects is to put all the typedefs in one header file ("typedefs.h") or all the constants in a header file ("constants.h"). While it is clear that all the features in the header file have something in common, it is not clear that this is actually useful except in the most trivial sense.

This question of common use (also documented, a little misleadingly, as the Common Reuse Principle) highlights another consideration as well: the criteria used for separating or combining parts should be visible and positively defined.

Consider, by way of counterexample, the java.util package, which appears to contain as ragtag an assortment of unrelated classes as you are ever likely to find. What is the common theme that binds the collection classes together in the same package as, for instance, the calendar facilities? It isn't that they are utilities, because this theme cannot be applied consistently or meaningfully — everything in software is ultimately a utility to something else.

The implication of the name util fails to explain just why the many collection classes are merged in a package of unrelated utilities that clearly do not measure up against a yardstick of common use; but the BigInteger and BigDecimal utility classes get a package — albeit inaccurately named — pretty much to themselves.

By way of contrast, the criterion used for the partitioning of the System.Collections namespace in the .NET library is clear. The criterion used to define the content of java.util is a somewhat accidental one that can be summarised as "it contains utility classes that are not defined in other packages".

Yes, it's some kind of design reasoning, but one that's difficult to employ constructively. But this is not (just) a rant about things named "util" or similar. This problem of arbitrary cohesion is found in libraries and applications that many programmers commonly work with. The presence or absence of a particular feature in such libraries and classes is more a matter of lottery than of reasoning. For example, the C library's <stdlib.h> header can be characterised as "holding all the standard library features that are not already defined in other standard headers (except for the couple that are)".

A lot of learning is from example. Lessons are absorbed, often passively and unconsciously, from our environment. For programmers, this environment includes the standard APIs they work with, which is why we should value a good understanding of their developmental strengths and weaknesses, and focus on more than just their functional behaviour. If it has sufficient functionality, it is always possible to work with uncohesive code. But effective design is more than just affording the basic "possibility of use": ease of use, errors in use, cost of use, delight in use, and so on, are all part of the picture. ®

Seven Steps to Software Security

More from The Register

next story
Secure microkernel that uses maths to be 'bug free' goes open source
Hacker-repelling, drone-protecting code will soon be yours to tweak as you see fit
KDE releases ice-cream coloured Plasma 5 just in time for summer
Melty but refreshing - popular rival to Mint's Cinnamon's still a work in progress
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
Put down that Oracle database patch: It could cost $23,000 per CPU
On-by-default INMEMORY tech a boon for developers ... as long as they can afford it
Another day, another Firefox: Version 31 is upon us ALREADY
Web devs, Mozilla really wants you to like this one
Google shows off new Chrome OS look
Athena springs full-grown from Chromium project's head
prev story


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.
Consolidation: The Foundation for IT Business Transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.
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.
How modern custom applications can spur business growth
Learn how to create, deploy and manage custom applications without consuming or expanding the need for scarce, expensive IT resources.
Securing Web Applications Made Simple and Scalable
Learn how automated security testing can provide a simple and scalable way to protect your web applications.