Why Object Oriented Design means less maintenance cost?

What is Maintenance cost?

Maintenance cost generally includes all effort (and the more importantly the financial resources that go along with effort) expended post the final release.

These generally include

1. Effort involved (ease or pain) in isolating defects (given a defect, how fast can a support person tell that this particular component(s) only has the problem)
2. Effort in fixing the defects (How many lines of code change is required to fix a defect)
3. Future enhancement has 2 dimensions.
1. Scope of tomorrow’s requirements that can be accommodated by today’s design. Given an application, the future requirements of that application can be split into 2 sets. Set 1: requirements that the current design can accommodate. Set 2: requirements that can be accommodated only upon a design change. A design is as good as the size of set 1.
2. Given Set 1 in the above point, how quickly can the requirements in this set be accommodated? This defines the agility of the business to adopt to changing business environments.
4. Time taken by a new support person in internalizing the application design (this is of much significance given the attrition rates in India)

Given this understanding of maintenance cost, how does an OOD reduce maintenance cost?

Reason 1: Ripple effect is least.

Good OOP design practice suggests that you program to interfaces. Programming to interface means

1. You take the publicly exposed interface (method signatures of all public methods of a class)
2. Understand the service offered by the public interface as published by the author of that public interface
3. Make use of the services offered by the public interface (bearing in mind the scope of service offered).

Now a requirement change might necessitate a change on your side or on the side of the author exposing the public interface. Presuming the author of the public interface followed sound OOD principles; he would change his code, do a build and give you the new libraries. Your code needs no change (so less effort). The same can happen the other way (you doing the code change and the public interface remaining intact).

Other reasons follow.

These are lessons learnt from other sources. Not my own by any chance.

Difference between traditional libraries and Java framework

Came across a very interesting difference between traditional C style libraries (e.g. stdio.h, string.h) and Java style frameworks (e.g. Struts, JUnit).

In traditional libraries you write the main driver code and invoke the library code to access the features offered by the library. For example, In c you write the main() function and call, say strcpy from your main.

Java style frameworks work the other way around. In java style frameworks, the framework does the driving and expects your code to be plugged into the framework.

Nice resource on java source examples

This site provides some nice resources on java source code examples:

http://javaalmanac.com/