Handling Complexity by OOP

What is so important about object oriented programming?
What are the alternatives?
Why learning object oriented programming so important?

Developing systems based on object oriented approach can create extendable systems. Meaning that original system can be improved without changing the existing code. This leads to create reusable systems.

Software is inherently complex. This complexity arises due to various reasons.

Domain complexity

Software engineers think about the systems from their point of view and develop the systems. This may not be the system that the users are actually looking for. This problem arises due to the impedance mismatch of the users and the developers. And some times the problem is clearly understood only when the solution is created, this scenario is called wicked problem. And requirements may change over the life cycle of a software development project. Making changes to the code in the later stages may be more costly than doing it in the early stages in development.
Sometimes contradictory requirements have to be resolved before starting the development. Process.

Flexibility

Many people hesitate to consider a software as a product. Because it is intangible. And clients may ask to develop the system from the scratch as they don’t see any waste like breaking a building and rebuilding the same thing again. But this flexibility creates complexity for software people.

Project Management

Managing the development process is also difficult. As there may be several modules in a project and each module may be having sub modules. Separate teams may be developing their own modules. The major challenge is to maintain the integrity and utility of the design. So once all the modules are done they can be easily fixed into a single system that makes up the final system.

Addressing the complexity

But ultimately software engineers should hide the complexity of the system form users by providing simple attractive user interface to perform what is intended. The basic theory used is that
“Any complex system is made out of simple structures”
Like human body which is made out of cells. Set of cells creates tissues…. So complex systems can be structured into a hierarchy of components. But the primitive components may be different for different people. For example if one is structuring the human body he can consider the cell as the basic element but another can still take tissue as the basic element.

When considering the software systems as mentioned earlier which is inherently complex follows the same principles. In object oriented design, we model real world entities as objects. The complexity is handled by designing them as hierarchies of components. At this point several terms come into play.

Abstraction

Abstraction allows creating a template that represents a group of objects. But this is based on the perception of the system by the user. For example in a system where gender is not significant, system designers may design the person class to represent all the employees of the organization. But factors like maternity have to be considered abstraction in the person level is not adequate. Designers have to move a level down and design two classes to represent Man and Woman.

Encapsulation

Using this concept classes are designed by encapsulating properties and behaviors in to one compartment. And properties are not allowed to be manipulated from out side directly. This is some times called information hiding.. Encapsulation ensures independent implementation of each class. So internal implementation is independent from others.

Modularity
The best way to tackle the complexity is using the divide and conquer approach. Complex software system is sub divided into manageable modules and developed independently as they are loosely coupled. Each module define an interface to connect with other modules.

Hierarchy

We design real world entities as objects. We use abstraction to represent groups of objects. But to understand the system more closely we define relationships between these groups. These relationships create hierarchies. For instance if we are designing a car we can relate the tyre by a part of relationship. And then we consider tyre as another abstraction that represent set of tyres. And we can create automatic_gear car by extending the car. All these things create hierarchies that increase the understanding and the structuring of the system.

Charith Handagama(044015)