Showing posts with label Object Orientation. Show all posts
Showing posts with label Object Orientation. Show all posts

Monday, November 24, 2008

OOP - Basics of Object Orientation

OOP's, Its always too late to discuss about OOP. Its not mandatory that for any good design we follow OO. Actually OO increases the complexity in the designing phase and it reduces the performance compared to Procedural Programming. Having said that why do we follow OO. Its all for one word:
A good design is very simple like the nature. Its without any instuctions. Take Tree for example, we need not need any instructions, we see the nature and learn. We learn how to eat fruit or how to climb without any instuctions. So, in the process of representing the nature we started using OOP.

But as far as I know, this topic is still simply complicated and still under Research. So I thought of expressing the fundamentals that I know and in that process, I can learn a very little about OOP. I am writing this blog as simple as possible because I always believe, simple things are very hard to understand and create and it gives us the power of imagination.

The first question is, "What is an Object?".
Object has 3 things:

  • Identity
  • State
  • Behaviour

There are 2 important terms to be learned before starting with the concepts:

  • Invariable: The one that is known, that can be reused, abstract, which won't change
  • Variable: Which changes

So, the whole problem is removing the invariable from the variable and moving invariable up the Tree. This produces Shallow tree and which is more prefered than a Deep Tree.

For example:
WindowManager:

  • CreateWindow
  • EditWindow
  • SaveWindow
  • CloseWindow

Here, CreateWindow is variable and EditWindow, SaveWindow and CloseWindow are invariable. Because CreateWindow can be called many times, but the EditWindow, SaveWindow and CloseWindow can be called on a particular instance of Window.

For OOP there 4 mandatory concepts:

  • Abstraction and Encapsulation
  • Implementing Encapsulation using Inheritance or Composability.

Abstraction:

Abstraction is taking the Invariable part out of the Variable. A natural example may be Fruit. Apple exists and once eaten cannot be reused. But Fruit is something that cannot be eaten and that exists only in some form.

Encapsulation:

Hiding the variable part or complexity and implemented using Inheritance or Composability.

Composability:

Composability is very dynamic. Its Composing/Delegating/Ordering. Like someone asks you for time. You see a watch/clock/mobile and then tell time. Here you are encapsulating the implementation, i.e, you are not inbuilt with time functionality. But, you are delegating it to a watch/clock/mobile and telling time. Since there is delegation, its costlier. Most of the times, Composability comes along with Inheritance.

Inheritance:

Inheritance is static. It is Derivation. Let us take the same watch. You see the watch and look into the time. But for a watch mechanic, the encapsulation is different, he looks into the internal parts of the watch. He sees the implementation.

Implementing Encapsulation using Inheritance/Composability may seem confusing. So, let us take another example, say a Data Structure implementation.

Stack:

Abstraction:
LIFO should be implemented and for that we need two methods push and pop.

Encapsulation:
Providing push and pop hiding the implementation.

Implementing stack using Inheritance:
Extend LinkedList and then provide push and pop and implement them using LinkedList methods.

Implementing stack using Composability:
Provide push and pop and then call/use some other methods for implementing the same.

Composability is more global. Hence the reusability is more. Let us take an example:

Sale: log()

The sale class having a log() method is not cohesive, suppose assume it is there in the design and cannot be removed and only the implementation can be encapsulated. A better way is to call and external API for the log() implementation.

AbstractLog:log() <- SalesLog:log()

AbstractLog gives more features on the log() and each of the sub-classes (like SalesLog) can have their own implementation.

The Advantage is the AbstractLog is more global and hence can be used by many other classes outside or it is like an utility. But the abstraction comes via Inheritance. So sometimes Composability comes along with Inheritance.

A good programming need not follow OOP. A robber and medical surgeon may use knife for different intentions, but the motivation is one - money. In the same way, The Intentions may be different for using OO, but the Motivation should be "REUSE".