The gang – modular programming
Modular programming is the process of dividing a problem into smaller subunits and then making them interact with each other. Each subunit will revolve around a part of the problem. These subparts are quite easily reusable or replaceable. This designing technique gives a helping hand to the developers to develop their individual units and later combine them. Each subpart can be termed a module. The developers do not need to know what the other modules are or how they have been developed. Modularizing the problem will help the developers to achieve high cohesion.
The world of modules
The pluggable component which can be easily integrated into the application will provide the solution to a particular problem. For example, we want an Eclipse to support Subversion (SVN) (one of the versioning tools). Now, we have two choices. One, to start the development of Eclipse again from scratch or, two, to develop an SVN application. If we choose the first choice, it's very time-consuming and we already have Eclipse in a working condition. Then why start it from scratch? Yes, it's a very bad idea. But it would be great to have an SVN solution to be developed separately which is an SVN plugin; this plug-in can be easily integrated into eclipse. See how easily the two modules— eclipse, which was in working and the new SVN module—have been integrated. As SVN is a separate module, it can be integrated with NetBeans (one of the IDEs). If we had developed it in eclipse, then it would not be possible to integrate it in any other IDE. When we develop any application, from our point of view, it's always the best. But being a good developer, we need to be sure of it. How to check whether the application we have developed is working fine for the aspects or not? Yes, we need to test it, whether each part is working correctly or not. But is it really so simple? No, it's not. Not just because of complicated logic but due to its dependency. Dependency is a factor which is not under the control of the developer. For example, we need to check whether my credentials are correct or not when I am trying to login. We don't want to test the tables where the data is stored, but we want to check whether the logic of tracking the data is correct or not. As we have developed a separate data access module, the testing becomes easy. In Java, a single functionality can be tested with JUnit.
Testing helps the developer to test an application which processes the data and provides an output. If we are getting the correct result, we do not have a problem, but what if the output is wrong? The process of finding bugs in a module is called debugging. The debugging helps us to find defects in an application. That means we need to track the flow and then find out where the problem started. It's quite difficult to find the defect if the system is without modules or if the modules are tightly coupled. So it's good programming practice to write an application which consists of highly cohesive, loosely coupled modules.
There is one more fact which we need to discuss here. Sometimes, when the actual main development is progressing, we come across a point where we actually want to add a new feature. This new feature was not added while the basic discussion was going on; here, we want to do parallel development. In this case, we don't want to replace the previous development but we want to support or enhance it. As our application consists of modules, a developer can go ahead as most of these modules are independent and can be reused.
