We started looking at PB program as a collection of Objects in the last post. Yes, PB is now an object oriented language, but it sure did not start that way. Sure it has some objects like windows, buttons etc, but does that make it an Object oriented environment automatically? This topic itself is so huge, So, I decided to touch on these first before continuing further with PB.
What is an Object?
The simplest definition of an object is a thing, a noun or an entity. In the programming world, this has come to mean a self contained programming unit. By hooking different "objects" you can make a program. Objects themselves are not new. Remember the old C programs? When you compile individual C files in a program, they were converted to "object" file. Though it doesn't mean the same, it stands for a program unit. By linking different "object" files, we arrived at the final program (Executable). Then there were modules. Even though there is a subtle difference between a module and an object, in theory they are the building blocks of a program. Remember, COM (Microsoft .Net evolved out of this eventually)? The idea was to have bunch of OLE (eventually called Active-X) that would be glued together in a program. In fact, Visual Basic was invented for such a purpose originally. We will explore more about objects in the coming posts. But, while you are at it, think about another term frequently used in OO: a Class. Several authors allude this to a blueprint, cookie cutter, a mold for creating objects.
What is Object Orientation (OO)?
An object has several other characteristics that makes an object in an Object-oriented language different from earlier definitions of objects. If you Google for the word “Object oriented”, you will find a million links. If you sift through all those, you will come to the following conclusion:
Object Oriented is a new paradigm (though it's been around for 30+ years now) and it is difficult to learn and/or master. Yet you see, every programming language (PHP, Coldfusion, PERL, PYTHON, you name it) out there is joining the OO way. So, if you are going this route, you have to get the concepts right.
Object oriented is many different things to many different people. Even the languages that claim to support OO now, are not fully OO themselves. So, let us discuss fundamental definition of being object oriented. In later posts, we will continue to drill down this topic.
Several books talk about Object Oriented (OO) approach to contain the following four basic characteristics
- Abstraction
- Encapsulation
- Inheritance
- Polymorphism
We will analyze each of these below.
Abstraction
Almost anything we do with computer software is an abstraction of the real world. An ATM machine is essentially modeled after a real-life teller it came to replace. Abstraction itself is not OO. Cobol and Fortran programs abstracted business models and mathematical models respectively for about 50 years now. But the abstraction in OO, is much closer to the real life. After all, real life is full of objects: people, earth, machines, food, microwaves, books, TV, radio etc.
In OO, we try to call a Radio a radio and define it's properties and operations to emulate real life one (actually a radioObject is more appropriate name for it; of course, it's a software object not a real one, but you could make it to play music!). A software abstraction is context based. For e.g., when we abstract customers, shop owners and employers we are abstracting people. In such an abstraction, we definitely would like to know their names, but we don't need know their race, gender, height, weight etc. Where as, if the person abstracted is a patient, suddenly some of these characteristics matter!
A speedometer in a car is a good example for abstraction. We see the needle to get an idea as to how “fast” or slow the car is going. Abstraction in this case varies between MPH in the US to Kilometers in some other countries. A thermometer, similarly abstracts how "hot" outside temperature is.
Encapsulation
This is the next characteristic of an OO programming environment. Encapsulation, simply means hiding private data and showing proper (public) interface. We don't want to see inner-workings of a microwave or a car when we are using it to heat our pizza or driving to get one. When we shop for a car, we are happy if we find a steering wheel, something that looks like gear, brakes and of course, those 4 wheels that the car needs to “run”. Of course, some of us would like little more glossy finish, but none of these involve putting engines right next to you on the front seat! And of course, the way those engines come pretty well sealed these days, they are very well encapsulated themselves. There is one “interface” you see, the oil cap that lets you fill oil. The content, level of oil, is not immediately visible. If you open and use a dip stick, you can find out the actual level of oil!
Speedometer mentioned above is also a good example of encapsulation. To “see” speed one doesn't need to look at rotating gears, tires, road etc. They just look at the interface called “Speedometer”.
Encapsulation itself is not a new concept. It's been around since the early days of programming. In Pascal, you could achieve certain amount of encapsulation by proper function design. C of course, offered modular programming (file level – see post “Modular progamming in C” for more information).
Inheritance
The most common meaning for this English word is the property (read “Wealth”) inherited from ancestors when they pass on. And it's not just property that can be inherited. We also talk about some characteristics passed on (genetically). It's this latter mean that's adapted in the computer lingo. Inheritance in OO allows an object to acquire properties and behavior of some other. So, we talk of a Dog object inheriting properties of an animal object (actually class, we will discuss these shortly).
Of course, in real life we don't say Dog inherited from Animal. We say, Dog “Is A” animal. We also say Car “has a” engine. And we have access (reference) to computers in the hotel. These are different types of object relationships in OO. An “Is A” is considered to be inheritance. A “Has A” relationship is called composition. And a reference to an object out there, is an Association.
Of these, Composition and Association were possible is non-OO languages as well. Inheritance itself could be indirectly implemented through these 2. For e.g., in C, using plain structures and function pointers we could mimic any of the above relationships.
Polymorphism
This came from a Greek word. Poly means many, morph – form. For e.g., different forms of shapes. Circle, Square, Rectangle and Triangle are all shapes. Of these, Rectangle and Square are similar, in that they both have sides. Circles and Ovals could be similar.
Now, shape is a noun, an object. How about a verb – an action or behavior? Let's take the word “Play”. Try using this English word in sentences and you will see how many different objects can play in how many different ways. Like playing a piano, like playing Football, Playing cards, playing a part in a play, Play with a child, Playing with life! This is truly a polymorphic word. How about the word, “Talk”? “Talk” to a dog, barks, cat meows and the cow moos, not exactly talk in the human sense, but in the sense of “open your mouth and make a sound” it's the same operation, with various forms!
In this post, we tried to explain what OO is and try to understand the terminologies typically related to the OO. This wasn't totally a technical discussion. Now that we got some definitions out of the way, let's get down to business with the topic of Object Oriented. Try to remember some of the examples when we get to our next post.
Below picture summarizes all these terminology as they relate to a Microwave.
