Object-Oriented Programming

vs.

Non Object-Oriented Programming

I am not sure what Gordon's colleague means by "structuring method for procedural programming."  Nevertheless, I will  throw in my two cents on this (exciting) subject of Object-Oriented Programming (OOP) vs. Non Object-Oriented Programming (NOOP).  I will respond to Gordon's colleague by presenting to him two concrete examples that I use in my class to illustrate to my students the differences between OOP and NOOP.  My class is basically a CS2 course where the students are taught OOP using Java.  My students were taught "program design" using Scheme in CS1 and are assumed to know something about functional programming, but nothing about OOP and Java.

Example 1: I am dealing with people and need to know their genders.  Write a program to model people and the fact that they know their genders and can respond to my inquiry about their genders.

NOOP model: A person is either a man or a woman.  I will model person with a class called Person.  It has a boolean gender flag to record its gender.  Whenever it is asked for its gender, it checks its internal flag and return "male" (or "female") accordingly.

public class Person {

    private boolean _male; // true means male, false means female.

    public Person (boolean genderFlag) {
        _male = genderFlag;
    }

    public String getGender () {
        return _male? "male": "female";
    }
}

I suspect the above model would correspond to what Gordon's colleague coins as "structuring method for procedural programming."  But in my own opinion (IMOO), this model is not object-oriented at all.  What is "wrong" with this model?

Suppose I create a male person called bill:

Person bill = new Person (true); // bill is a male person.

And then I ask bill a thousand times for bill's gender in many statements like this one:

if (bill.getGender ().equals ("male")) { //do something }

Each time I ask bill for his gender, he has to check his internal flag before he can answer me.  If the fact that bill is a male has a ready been made once at construction time, then why does bill have to keep checking his flag each time somebody ask him of his gender?  I present this example to my class in the first lecture.   I tell my students, "I ain't no Bill Clinton!  I don't have to examine myself every time Hillary asks me if I am a man!"  I think my students appreciate that.

OOP model: A person knows intrinsically how to respond to a gender inquiry.  A man is a person and knows specifically how to respond to the gender inquiry.  A woman is a person and knows specifically how to respond to a gender inquiry.  I model person as an abstract class called APerson with an abstract method for responding to the gender inquiry.   I model a male person as class called Man and make it a concrete subclass of APerson.  I model a female person as class called Woman and make it a concrete subclass of APerson.

public abstract class APerson {
    public abstract String getGender();
}

public class Man extends APerson {
    public String getGender() {
        return "male";
    }
}

public class Woman extends APerson {
    public String getGender() {
        return "female";
    }
}

Now I will play God and create monica.

APerson monica = new Woman ();  // monica is a female person.

if (monica.getGender ().equals ("female")) { // go smoke a cigar with bill }

monica will answer directly my inquiry on her gender without hesitation, without any ifs, buts, nor conds, no matter how many times I ask her.  The decision for monica to be a female has already been made at construction time.  monica need not and should not check for anything else to respond to the gender inquiry. 

The key to this design is the representation of the abstract notion of a person as an abstract class with an appropriate abstract behavior.   This abstraction of behaviors together with polymorphism allow us to hide away explicit state checking control structures in our code, reducing code complexity.

Writing a program using classes does not automatically qualifies it as object-oriented as the above two designs illustrate.  It is the object-oriented thinking (OOT) behind the design of a program that makes it object-oriented.  The OOT that goes into the design of the class APerson and its concrete variants in the above can be summarized as follows.

• There is an abstract notion of a person that knows how to respond to a gender inquiry.
• A man is a person and knows how to respond to a gender inquiry in a very specific way.
• A woman is a person and knows how to respond to a gender inquiry in a very specific way.

This way of thinking puts the emphasis on first identifying the abstract behaviors of a system instead of the data it must have.  After the abstract behaviors are identified, we then encapsulate each concrete variant of the abstraction into a separate concrete subclass.  When I talk about about encapsulation in OOT, I mean behavioral encapsulation, not data encapsulation.  Data abstraction, IMOO, plays a secondary role in OOT.  Data exist as attributes to help implement the concrete behaviors.  The above formulation of an abstract person class and its concrete variants offer another subtle point: it allows me to add new concrete variants (e.g. eunuch?) to the model without changing any of the existing code.   This is what code-reuse and extensibility is all about.  Whereas if I formulate the problem as "a person is either a man or a woman,"  when I need to add a new "gender", I have to chase down all the switch statements in all of my code that are used for distinguishing the type of gender and make the appropriate modifications.  That's another reason why I would characterize the first design as NOOP, and the thought process that goes into this design as NOOT (non object-oriented thinking).

OOP is a translation of the (mental) model OOT creates into the form of a program .  In theory, OOP can be done via a Turing machine, :-).  But I prefer to use a convenient object-oriented language (OOL) to implement object-oriented designs (OOD).   Employing modern visualization tools makes it much easier for me to get my points across to the students.  For example, with BlueJ I can visually create bill and monica, point to each object, and ask for its gender.  What I would like to see is "object-oriented hardware" that can execute object-oriented code in the most effective way.  (Perhaps, my friend, Stephen Wong, would care to share some of his thoughts on this.)

Now that my students have seen an illustration of OOP vs. NOOP, I send them home with the following problem and ask them to come back the next lecture with their best solutions using their most favorite programming language in order to compare notes with mine.  Perhaps, Gordon can ask his "structuring method for procedural programming" colleague to do the same.  I will present my solution in another post should y'all are curious to know.

Example 2: The Best Little Pizza House in Texas is having a special on its pepperoni and cheese pizza. The special pizza comes in two shapes: rectangular (4" by 6") for $4.49 and circular (5" in diameter) for $4.69.   The pizzas all have the same thickness.  Which one is the better deal?   Write a program to solve this problem.  Why do we want to write a program to solve something as simple as this one anyway?

Have a great day!

Zung