Posts
There is a point in every programmer's life when he asks himself a certain question. That question is, “what is the big difference between procedural and object oriented programming?”. To answer this question satisfactory, we first need to look at the problems associated with procedural programming that required people to start thinking differently.
Procedural programming can either be approached from a “top-down” or “bottom-up” view (Terrazas).
A top-down approach is “breaking down a system to gain insight into its compositional sub-systems” (Top-Down, Bottom-Up). Each sub-system is refined and broken down until you have reached it's base elements. The problem with this approach is that the data you are looking for is discovered very late in the process (Terrazas). Because of this if operational procedures changed, the entire data structure would have to change as well, which would be very expensive because it would end up costing the company many months of work to rewrite all of their code.
To address that problem, programmers started looking at writing code from the “bottom-up”. This idea was a break through in the programming community; the data you were looking for would be discovered first. The way that “bottom-up” programming works is that you start at the base elements and then you build sub-components on top of them. You keep stacking and stacking until you have built the task you set out to accomplish (Top-Down, Bottom-Up).
The bottom-up method of programming lead to very stable data being created, but both of these methods lead to something called “Paralysis of Analysis”. “Since the data had to serve so many masters and could never change, there was a great pressure to "get it right". Trying to get it right caused endless hours of second-guessing and trying to make things perfect” (Terrazas).
While the bottom-up method is better then the top-down one, both of them were still sub-optimal. The reason for this is because no matter how clean the code was, the programs were artificial, the data and the programs did not match the way people talked about the business (Terrazas).
As a result of this there was a widening gulf between the business analysts and the system designers. Object Oriented programming came about as a way to help close the gap between the two groups. To make the code and procedure more closely match the way people talked about it. This new way of coding “attempts to keep the programming close to the level of abstraction of the business” (Terrazas).
The objects in object oriented programming act closer like objects in the real world because they are responsible for their own information and their own operations.
These changes help to make the vocabularies of the business analysts and the software analysts much closer. Any change to the business requirements are easier to see how they would affect the software.
There are three key methods of object orient programming languages that allow for this idea to happen. They are encapsulation, inheritance, and polymorphism.
The first major pillar of Object Oriented programming is encapsulation. The idea behind encapsulation is to hide anything from the program except for interface functions. Dictionary.com defines encapsulation as “to place in or as if in a capsule”. To do that there are two different terms associated with the idea of encapsulation; they are Public and Private. A function or variable that is public can be called directly. For example if Bark was a function of the class Dog, and it was public, then anywhere in my program I could call dog.bark() and it would compile and work just fine. Everything in a class should be protected. A protected or private function or variable can only be called and used by functions within the class. The only functions that should be made public are ones called interface functions. Interface functions typically check incoming data for errors or validity before they pass them on to the internal functions and variables.
Another name of interface functions is to call them gatekeepers or guard dogs. As they are guarding the internal functions and variables from incorrect data.
It is typical to see a function called getAge() and setAge(). The function getAge() would be an interface function. This function is tasked with retrieving the data from the calling function and to check it for correct usage. It would be correct to see a call like boy.getAge(). That call says, for the class boy get the age. Once the data has been tested and is correct then the function getAge() would internally call setAge() which would ultimately assign a number to the variable age which is inside the class boy under the private or protected status.
The second major pillar of object orient programming is called inheritance. Inheritance essentially is the idea of building relationships between super classes and classes, or Parent classes and child classes. Any class that is the child of a parent class will “inherit” everything from the parent class. This allows not only for good code reuse, but it also make certain relationships make sense.
Inheritance in classes is not unlike it's natural counterpart in the real world. Every animal, person, plant, rock, tree, shrub, fish, insect and even bird: all inherit characteristics from their parents.
For every person, we come from two people, a male and a female. From those two people their genes that we inherit combine to shape what we look like.
Inheritance is defined as being “something, as a quality, characteristic, or other immaterial possession, received from progenitors or predecessors as if by succession: an inheritance of family pride” (Inheritance).
A good example of inheritance comes from an article called “Encapsulation vs. Inheritance” on the site Developer.com. In the article it showed an example of one parent class and two child classes. The parent class is called “Mammal” in this class there is the variable eyeColor, and then the function getEyeColor(). Then there are the two child classes. The first one is called Dog. It has the variable barkFrequency and then the function bark. The second child class is called Cat. It has the variable meowFrequency and the function meow. The reason why this is a good example of inheritance boils down to one of three categories. Is-a, has-a or neither. If a class “is-a” child of a super class then that is a good indication that one should use inheritance. Take for example the dog and the cat classes. They both are mammals. So they would fall under the category is-a mammal. If something is under the category of “has-a”, then inheritance is probably the not correct way to go. for example, a car “has-a” tire. But a tire does not inherit other things from the car.
Because of the way that inheritance works, the class dog would have everything from it's class including everything from the mammal super class.
Now that classes have the ability to inherit the traits of their parent classes, child classes now only have to have what makes them distinct from their other child classes in their “family”.
The third and final major pillar of object oriented programming is known as polymorphism. In order to understand what this word is, it requires us to break it down into its components parts. The first part is “poly-”. The unabridged version of Dictionary.com states that poly means “a combining form with the meanings 'much, many'” (Poly). The next section of the word is defined as “an individual of one particular form, as a worker ant, in a species that occurs in two or more forms” (morph). Lastly the suffix “-ism” is defined as “a distinctive doctrine, theory, system, or practice” (ism). When the words are put together we form the word polymorphism which is actually a form of the word polymorphous which means “having, assuming, or passing through many or various forms, stages, or the like” (polymorphous).
Now that we have defined what we are talking about, let us address what this term means in computer programming, more importantly. Just why is it a pillar of object oriented programming? Polymorphism allows for derived, or child, classes to override and change the information of a member in the base, or parent, class.
Say you have a base class of automobiles. In that class you may have things like body type, door count, engine type, gas tank size, and tire size. Well, a derived class of automobile would could be a car or an SUV. Both the car and the SUV type of classes inherit everything from the automobile class while bringing with them members of their own that are unique. For example the car class may have member such as “isHatchback” or “hasSpoiler” while the SUV derived class has the members “canOffRoad” and “cargoSpace” (Mains).
These different member functions are unique to their respective classes, however, both of these classes would have a function called “bodyType”. In polymorphism “anyone using the base class could, in fact, be using an object of the derived class that has been cast to the base class type” (Polymorphism (C#)). This allows for both the SUV class and the car class to both use the same bodyType member from the parent class automobiles but it would be different for both of them because their version of bodyType overrides the version in the base class.
This is what makes polymorphism so powerful. It is similar to the idea of the Latin names for plants or animals in the real world. The order of Latin or scientific names follows exactly the same pattern of inheritance and polymorphism. The order from “base class” to final “derived class” is: Kingdom/Class/Order/Family/Genus/Species. Take the common tree frog for instance, its full name is Phylum (for animal), Amphibia, Anura, Hylidae, Agalychnis calidryas (Red-eyed Tree Frog). Typically just the Genus and the Species is listed to save writing time. Each one of those hierarchy tiers, except for the species, branches out to cover many, many different types of animals. If we just look at the class Amphibia, then we go on to include: frogs, toads, tadpoles, newts, salamanders, mud-fish, anything that lives part of its life on land and part in the water.
By using the principles of polymorphism we are able to describe any subset of a class we want. Code reuse is one of the biggest ideas in good programming. This allows for that idea to flourish.
As stated before, object oriented programing was developed as a way to close the gap between business analysts and software analysts. Procedural programing was too artificial. It was not how people spoke about their code. The sheer nature of the three pillars of object oriented programming make the code so much more natural. Now with encapsulation, inheritance, and polymorphism. We can finally talk about code in the way we talk about anything else. It allows us to describe code in ways that other non-programmers can understand. A change had to happen, and it was successful.
Bibliography:
“Polymorphism (C#)” MSDN.com 14 Jan. 2010.
"encapsulation." Dictionary.com Unabridged. Random House, Inc. 14 Jan. 2010.
“Encapsulation vs. Inheritance”. Developer.com Jan. 14th, 2010
"inheritance." Dictionary.com Unabridged. Random House, Inc. 15 Jan. 2010. .
"ism." Dictionary.com Unabridged. Random House, Inc. 15 Jan. 2010. .
"morph." Dictionary.com Unabridged. Random House, Inc. 15 Jan. 2010. .
"poly." Dictionary.com Unabridged. Random House, Inc. 15 Jan. 2010. .
"polymorphous." Dictionary.com Unabridged. Random House, Inc. 15 Jan. 2010. .
“Red-eyed Tree Frog”. Honolulu Zoo. 15 Jan. 2010.
Terrazas, Mike. Personal Conversation, Primary representative of DECUS on C (ANSI X3J11). And alternate rep on C++ (ANSI X3J16/ISO WG21). 14 Jan. 2010.
“Top-down and bottom-up design”, 14 Jan. 2010 <http://en.wikipedia.org/>
No comments:
Post a Comment