Sample Question:

sdfsdfsf

JSR Notes:

Classes and Methods

Modularity means splitting a larger problem or work into smaller pieces or modules. So in the case of programming we can talk about this on two levels. Firstly, at the more macro level of a project, we can divide the work/problem into different classes. Though also, at a the class level itself, we can divide the tasks up into method modules.

Regarding modularity in the context of OOP, we are more concerned with the modularity of breaking a large problem into different class modules.

Do remember that upon division of a larger problem into classes, it is the OOP principle of encapsulation that, when properly followed, can lead to increased stability of the program. Refer to D.2.1 and D.2.4 for the distinct advantages offered by encapsulation.

 

Advantages of Modularity

(This is a reiteration, with some more details added, of what was mentioned in D.1.5, where decomposition/modularity was introduced.)

Modularity allows, generally:

A. A Divide and Conquer approach (which allows abstraction)

B. Abstraction, i.e. focusing in on individual problems, ignoring other details

Leading to, specifically:

1. Faster development
This is mainly because work can be divided between different programming teams. Each team can work on different modules/classes concurrently.

And furthermore, classes can be shared/re-used across projects. So for instance, a Student class could be used in a Grades project, and also in an Attendance project, etc.

2. Easier debugging
De-bugging takes less time, since it's easier to track down problems in smaller, less complex modules/classes.

By having data-focused template classes, other classes which make use of that data can be easily tested by simply providing them with dummy data values even before those “real” data classes are themselves available to be used for testing.

And when there are errors, they can generally be isolated to one class, so that means there is less code to look through to find the problem. This concept, in fact, can be extended down to the modularity of methods. When trying to isolate an error you can comment out a particular method to see if it's the one causing the problem.

(Consider the alternative where there is one big program with no methods, rather one big long chunk of code. If it ran with an error, you would have no idea where to start looking for the error.)

3. Easier updating in the future, i.e. Ease of Maintenance
For any one particular change, only one class needs to be modified. So the implications of those changes on other dependent classes will be minimal and clear. In fact, no changes at all may be required by dependent classes if the public interface of the edited class does not change (even though the hidden "inner workings" have changed.)

4. Re-usability
Modules/classes can be stored in libraries and reused for different programs. This in turn further speeds up development. (See also the Faster Development section above.)