Classes and objects

Classes and objects...

In this post I will be writing about classes and objects. If you are expecting accurate definitions I would advise you to Google, however if you are looking for easy to understand description with examples, this is the place!

According to me, best way to explain concepts is to link them with real world examples. Consider the following example.

Class as mold and object as toy...

Consider a toy shop making toys of different colors and materials.

They have a mold for making toys. Consider the mold as a Class, the Toy class.

The color and material are the attributes of toys. When you put clay inside the mold you get a clay toy. Similarly if you pour molten copper inside mold you get a copper toy. But the mold is the same.

In the same way you have certain methods for making a toy, like

·        covering the mold air tight

·        heating the mold

·        removing coverings

These methods are associated with the process of making a toy, and hence can be considered methods of the Toy class.

So using the class Toy different toys having different attributes can be created!!

Hope that example was clear enough.

Close to real life...

Usage of class and OOPS is recommended not because you cannot code the same in procedural way. You can code anything as procedural (remember the fact that machine language is procedural!!) It’s for the simple reason that classes and objects are closer to our real life objects.

In small programs any approach would be fine. However if you are writing complex code there is a need for code readability. Coupling data and methods as a single unit helps in modularity and code re-usability. Keep in mind that I never said you can’t write modular codes without using class. It’s just unnatural to write it that way and using class is easy once you learn how to use it and where to use it.

When and where to use...

There is no real hard and fast rule for usage of class.

Inheriting problem...

 One of the basic example you can see everywhere in Internet is the shapes example.

Shape is the base class. Rectangle is derived from it. Square being a special case of rectangle is derived from it.

The problem with this example is , can square be really derived from rectangle. If rectangle has a function called change height it cannot be applied to square since that would change the square property itself. So change height method has to be overridden and new definition had to be written for square. But the change height method would lose its meaning. So Shape example is not the best.

Another example you can easily find in Internet is the person example.

A student is derived from a male/female class.

In turn the male/female class is derived from person class.

The problem with this kind of derivation is that sometimes the derivations don’t really mean anything. A male/female class in between student and person class could be waste since only very few methods are going to be unique for male and female classes.

 Another problem is that a person is a living organism, so a coder may think why can’t we have organism as base class and derive person class from it. In this way if you keep on inheriting it simply leads to a completely messy code. Inheritance is to be used only when it’s needed. Creating a class for every real world object is not necessary.

One simple rule to be followed while creating a class is that... Check if there are enough methods to justify its creation. If you have only attributes they can be added as attributes to some other related class.

That's it for today..more about OOPS concepts in coming days...


Trained @ Sourcebits