Modules and interfaces

In software development, there is a long history of decomposing a system into smaller modules. This modularisation is the standard technique for dealing with large and complex systems. The modules partition the system design or code. Some typical examples of modules are:

• whole programs or applications
• software libraries
• classes, in an object-oriented language such as Java.

Although modules may appear as self-contained elements, because they are all parts of a larger whole there must always be relationships between them that need to be taken into account, as Example 8 shows.

These relationships limit the ability to change one module without affecting other modules.

In general, we say that the interface to a module defines how other modules can use that module. Sometimes, you can define more than one interface for a module to allow yourself to be more precise about which services will be offered to different kinds of client.

An interface is the means of connecting one module to another. It tells you what to expect about the behaviour of a given module and what services it will provide, without telling you how those services will be provided. For example, the interface can define how a bank accounts module will respond to queries about the balance of an account or the types of accounts available.

The interface of a module is a description of all the externally visible operations and what other modules need to know and do to make use of them, but without any details of how the operations are implemented internally. From an object-oriented point of view, we say that the interface to the bank accounts module is an encapsulation of what we know about accounts in a bank.

A module that provides services to other modules may in turn need to use the services of yet other modules. These required services are called its context dependencies. A module’s context dependencies and its interface, including any requirements that prospective clients need to meet, form a sort of contract with clients. The contract describes what the module does and what needs to be true for the module to do it. Clients can assume that if the necessary conditions are met, the module will fulfil its specified responsibilities.

The concept of an interface helps the developer to be more productive. If you can rely on the specification contained in another module’s interface, there is less for you to understand because you do not need to know how it works. Furthermore, you have a better chance of understanding your part of the software system because you can focus on the things you need to perform your task. A side effect of this added understanding is that you are less likely to introduce errors. Furthermore, if a module is hidden behind an interface it is potentially replaceable.

Once your software system contains a set of modules that are well understood, each with its own interface and context dependencies, you can consider whether any of them can be reused. It may be that a popular set of modules is adopted as a standard.

The ability for different computing systems to communicate over a network has developed because of the adoption of such a standard set of modules. Control over the complexity of computer communications has been gained by decomposing the problem into a number of layers. Each layer has a well-defined interface through which the layer above it accesses its services.