This post might be considered academic, but it offers a good overview of what I believe to be the guiding principles in terms of software modularity.

Let’s start with a little bit of background. Sometimes the way businesses are modeled are constrained by the available technology, which may block innovation, change and even growth in the business. Instead of establishing barriers, technologists should keep pushing for the evolution of technology, and keep fighting people who are against this evolution.

You may be fortunate enough to live in a better world, where software is built according to real business goals, bringing real value to the company. Great! However, this is not quite enough yet. Business models keep changing quickly, which means that the software in place ought to be flexible enough to support these changes, and also expansible enough to support that always desirable growth.

The real problem here is the following: How can we simultaneously achieve flexibility, expansibility, and maintainability in software architecture? This is a very tough question, but the answer is rather simple: “Achieve this by using high modularity levels”. Unfortunately, this cannot be achieved by some sort of magic, but only by dint of a focused architectural effort, as described below.

I like thinking of a module as just a block of code – this block of code can vary from being a method to being a class, a component, and a (web) service. Now, the modularity level evaluates the usage of modules in a given software architecture, mainly when it comes to encapsulation, coupling, and cohesion. Several authors have written about modularity, but my personal choice is Bertrand Meyer. His study on Object-Oriented Software Construction presents five criteria as a guide to evaluating modularity.

1. Modular Decomposability – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.
2. Modular Composability – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.
3. Modular Understandability – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.
4. Modular Continuity – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.
5. Modular Protection – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Mr. Meyer also presents the following six principles.

1. Linguistic Modular Unit – Modules must correspond to syntactic units in the language used.
2. Few Interfaces – Every module should communicate with as few other modules as possible.
3. Small Interfaces – If two modules communicate at all, then they should exchange as little information as possible.
4. Explicit Interfaces – When two modules communicate, this fact must be obvious.
5. Information Hiding – All information about a module should be private to that module unless it is specifically declared public.
6. Open & Closed – A module should be open for small changes (with no impact on its interface), and closed in terms of readiness.

Both lists are quite self-explanatory, aren’t they?

From my point of view, software modularity is an overused expression, and people are usually not familiar with any criteria or principles for evaluating the level of modularity, such as the ones listed above. This post aims to provide a means whereby the  often misunderstood concept of modularity is made explicit, while providing a foundation for designing truly loosely-coupled modules. I hope you find it useful.

Related Posts

1. Object Orientation’s Worst Enemy
2. Dependency Inversion: Killing Gorillas and Butterflies