In my previous article i talked about the fundamental concepts of object oriented programming, abstraction, encapsulation, inheritance and polymorphism. These concepts are a part of developing object oriented code and if structured appropriately can be used to create highly modular reusable code.
Developing reusable code is a necessity of software development, it allows for a more efficient development cycle and continuous improvement of an existing development.
The alternative to code reuse is code salvage. Code salvage is an inefficient method of stripping the code down for it’s useful parts and discarding the rest. In creating modular code we hope to support code reuse by making all of the code module useful.
To create modular code we need to look at the key characteristics of a module. For that i am going to reference Bertrand Meyer’s   five criteria for modular development from his book Object-Oriented Software Construction. 
- 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 subproblems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.
- Modular Composability. A method satisfies Modular Composability if it favours the products 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.
- Modular Understandability. A method favours 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.
- Modular Continuity. A 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.
- Modular Protection. A method satisfied 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 neighbouring modules.
The scale of modularity for each of the criteria may vary per module but by using these criteria to guide development of modules we should be able to create discrete, understandable and robust modules that can be used as building blocks for projects.
We can assess the affect of leveraging these principles by understanding two artefacts of code development, coupling and cohesion.
- Coupling. The reliance of the module on other modules and the module’s environment.
- Cohesion. A cohesive module makes sense as a discrete entity, it has a clearly defined role, purpose and it’s internal function is easy to understand.
Modular code should have low coupling and high cohesion. The lower the coupling, the less reliance the module has on external factors to function, this increases the chance that the module can be reused. Higher cohesion also increases the likelihood that a module can be reused, as it’s boundary is better defined making it easier to extract.
Nanos gigantium humeris insidentes  – By creating, sharing and using modular code we may all stand on the shoulders of giants.
- http://se.ethz.ch/~meyer/. Retrieved 17/07/2011.
- http://en.wikipedia.org/wiki/Bertrand_Meyer. Retrieved 17/07/2011.
- http://www.amazon.co.uk/Object-Oriented-Software-Construction-Prentice-Hall-Resource/dp/0136291554/. Retrieved 17/07/2011.
- http://en.wikipedia.org/wiki/Object-Oriented_Software_Construction. Retrieved 17/07/2011.
- http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants. Retrieved 17/07/2011.