Doing Object Oriented Programming Right

Posted: November 13, 2011 in Chrome Extension, General, Programming, Tutorial
Tags: , , ,

As a tutor and coding help forum poster, I notice many instances of people using OOP, but using it incorrectly. Now, i don’t necessarily mean that they have errors in their code, or that it isn’t logically correct, but rather that the programmer in question has problems with their concepts of OOP. In this post I’ll be discussing the very basic and common problems I see, and ways to think about OOP such that these mistakes can be avoided. I’ll only be going over two of the simplest OOP concepts, encapsulation and inheritance.

Object Oriented Programming: The Why?

Many people simply use Object Oriented Programming because its the “latest and greatest” paradigm in the computer science field. The problem is that they learn the syntax and semantics of OOP, but never truely learn what OOP is. Let me start by giving a basic explanation of what OOP brings to the table as far as programming is concerned.

First, the basic concept of OOP is instead of programming procedurally, or functionally, you program in such a way that your entire program consists of discrete, separate objects that interact with each other in certain ways. This concept is fairly easy to understand, but doesn’t quite explain how to implement such a program that takes advantage of all OOP has to offer. However, lets take a simple example to further illustrate this concept. Lets say we are writing a program to model driving a car. Each car is a separate object of course, but these objects are instances of the same class (in the case, a car), but have different properties. Some are fast, some are strong, and some have great gas mileage. Each car, consequently, is composed of many other discrete objects. Like the rear view mirror, or the engine (which in turn could be composed of other objects) and the tires (and of course these each have their own attributes). Then there is the driver of the car which is another object that interacts directly with the car. The Driver tells the car to drive, and the car in turn tells the engine to turn on, and tells the wheels to spin. The Driver doesn’t ever interact with the individual components of a car, but rather the car itself. The car interacts with each individual components. In (very PHP-like) pseudo code, this interaction might look something like

$Honda_Accord =  new Car();
$Honda_Accord->addEngine(new Engine());
//add rest of components
$bob = new Driver();

//inside the drive method,


This is probably the most widely known but often misunderstood concepts that OOP brings to the table. The basic concept is that of data hiding. Each discrete object in your program has data inside of it, that it hides from the rest of the program. If we consider the example above, each car would have certain properties (like speed, gas mileage, etc.). These properties would only be changed or acted with by the car. The rest of the program cannot (and should not) have access to any of these properties. For example, the driver tells the car to start, but the car is the one that sends the signals to the tires to move. The driver doesn’t (and can’t) interact with each individual wheel.

Encapsulation is often widely misused though. I see misuse in many forms, but the most common are as follows. The programmer may completely forgo encapsulation (For example, he makes all data members public). The programmer also may take it too far (he makes every single data member private, even those that conceptual shouldn’t be). I also see many people doing a very curious thing. They make all (or most) of the classes data members private, but create mutators and accessors for all of them, essentially making them public, but writing a lot more code to do so. For example

class A {
private $some_int;
private $some_string;

public function get_some_int(){ return $this->some_int; }

public function set_some_int($i){ $this->some_int = $i; }

public function get_some_string(){ return $this->some_string; }

public function set_some_string($s){ $this-> some_string = $s; }


Now, trying to explain how to correctly use encapsulation is almost impossible, since it can be applied in so many ways. However, I often try to tell my students the following, which has mixed, but predominantly positives results: When deciding what data members to make public, which to make private, and which to make accessors or mutators for, consider the following. If we consider a data member, say int x, how is it going to be used? Is it only ever going to be accessed and modified inside the class. If so make it private. If it will be accessed outside of the class, but you only want to be able to change it inside, then make it a private variable with an accessor (like GetX()). If you are going to be accessing and changing it outside of the class without any restrictions (IE a programmer using this class can set the value of x to any reasonable value) Then make it public. If you want to make it so that the data member can be set and retrieved outside the class, but setting the variable has restrictions (Like x cannot be over 10 or below 0) then make the variable private, and use an accessor and mutator.

Lets take an example. Lets say we are creating a Person class. The name of the person would obviously be private (since no one can change someone’s name but the person) but with an accessor (people can still ask for their name). The amount of cash someone has would again be private, but would have an accessor (someone can ask how much money they have) and a restricted mutator (someone can’t just set the amount of money they have, but a store keeper can ask for a certain amount, or give a certain amount back as change.) The class could look something like:

class Person {
private $name;
private $cash;

public function getName(){ return $this->name; }

public function getCash(){ return $this->cash; }

public function giveChange($c){ $this->cash += $c; }//function to return change back to user

public function pay($price) { $this->cash -= $price; }//function to pay for something

Inheritance is one of the most commonly misused concepts I see. Sometimes even more than encapsulation (since its a bit easier to understand the implications of it in a conceptual sense, so its much easier to correct past mistakes). However, inheritance is slightly more complex than encapsulation. The basic concept is rather easy to understand. Inheritance in OOP models inheritance in real life fairly closely. You have a Base or Parent object, and you have a Derived or Child object that inherits from it. The child has all the properties that a parent has, and more.

The main problem I see many students and novice programmers trip up on is having children inherit from parents for no apparent reason. For example (and this is a real example) one of my students had a lab recitation to model a car (much like the example above, but much simpler). Cars were composed of Engines, and Wheels and had some basic attributes (like model name and number). This student decided to have the engines and wheels inherit from the car because they were part of the class, and he took this to mean that they had to inherit from cars. This shows two things. One, laziness, and two, a complete misunderstanding of the concept of inheritance.

When deciding on using inheritance, take the following into consideration:

Say we have a system where we have a few different classes. Lets say that these classes all have some sort of similarities. If they do, then I would take these similarities (generally in the form of the same attributes, or the same methods) , move them into a base class, and have my other classes derive from them. Inheritance can be used to avoid having to repeat code. However, inheritance is unnecessary or irrelevant if we have two classes that are quite different from each other, even if they seem to have some similarities. For example, if we are creating a GUI system, we may have a bunch of different shapes. Each shape would have some similar methods and attributes (Like the name of the shape, and a method for drawing the shape). Each shape should derive from some Base shape class. Another example would be a system where we have musicians and a music store. Each musician and each store would have a store of instruments (for example, a musician may have a guitar and drums, and a store may have a whole selection of guitars, basses, drums, etc.) Musicians and stores would also each have names, and other things. However, it really wouldn't make sense for either musicians to inherit from stores, or stores from musicians since each has unique data members that the other doesn't have.

Taking the shapes example, the code may look something like

class Shape { //base shape class
protected $name= "abstract shape";//protected so derived class can access of course

public function draw(){ ... }


class Triangle extends Shape {//triangle class that inherits from shape class

private $height;
private $base;

function _construct(){ $this->name = "triangle"; } //constructor to set name of this class to triangle



If you have any questions, comments or feedback, please let me know in the comments!

public function draw() { ... draw the triangle ... }

  1. You have a great weblog and I like your style of writing about this stuff. Keep up the good work!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s