In software development world, the Object Oriented Design (OOD) is one of the most popularity technology. It has been widely adopted almost on every programming language, for example, C, C++ , Java and C#. They are all tending to be OOD. However, this legacy structure has its advantages and disadvantages on web development. The advantage is that it makes codes reuse easier but the disadvantage is that at same time it brings us the codes coupling problem. In this essay, I will be addressing the issues and solutions of OOD on web application development.

The Code Coupling is the twin sister of Code Reusing. When an object is reused, it creates a sharing object at same time. When many objects are reused then it creates many sharing objects. When time passes by, a function/class would be shared by many other classes eventually. It is nothing wrong to sharing objects but it may cause the maintenance issue. The maintenance of a spaghetti sharing program is difficult and time consuming. Most time, a big complicated project is not well documented because it is impossible to write down all details in terms of functions. It will be losing understanding on logic flow to new programmers. Code dependency structure of OOD becomes a problem - modifying a function that could effect many relating functions and classes that new programmers may not be aware of them. (The same issue is happening to DB coupling design. One table is shared by many other tables, Stored Procedures and functions that makes things too difficult to modify/update.)  

A problem is always coming up with a solution. So, the Modular Object Oriented Design (MOOD) comes in place - It is introduced by WUSIT. In MOOD, we still use OOD, but we split big application into many small standalone programs. Each program has its own classes and they are not sharing to other applications. We program applications in a vertical dimension, not the horizontal. The program will likely be stand alone and it will avoid to reuse any non-related classes. If two programs are not in same category, then they will not share the same functions and classes. That means we program an object as a modular which is not (or less) depending on other classes/objects. The dependency of programs are limited in a minimum interacting status. That is the key of this improvement.

The advantage of MOOD is that the individual program can be taken out and without affecting other programs or in any rates it has a very limited affection on others. So, in that case, we can minimize the coupling issue of OOD. MOOD is a good sample of Decoupling Programming. It is tidy and clean. It is developed from OOD but it has less OOD coupling matters. It makes codes easy to manage and maintain  - Any application can be "added on or dropped off" at any circumstances. When time is passed by, the MOOD codes can easily be upgraded and maintained because they are all stand alone. It saves maintenance times. Does that sound good? The story is not finished yet. 

With this technique, a big application is possible to be programmed by many programmers at same time because each sub program is stand alone; That makes the work extremely efficiency! All of them can be integrated easily. Several versions of website/web applications can be released at same time and all of them are running and interacting perfectly with each other. That makes coding different from legacy OOD.

:)

Happy Programming...