How do I describe Object-Oriented Programing to a

Question

My brother-in-law is a freshman engineering major in college. He has no prior programming experience. He is learning programming in his classes, but he seems to be struggling with the basic concepts. It doesn't help that he seems to be the only person in all his classes without some background in programming.

He did OK in Matlab (which I don't know), and then I helped him along when he was learning the basics of Python. Pretty soon his courses will start on C and C++. I'm worried that he will be left behind when Object-Oriented Programming comes up.

I tried explaining it to him with the analogy of a car.

Pseudocode:

Class Car 
{
    public string make;
    public string model;
    private string milesPerGallon;
    private float gasolineGallonsInTank = 0;
    private float tankCapacity;
    private float odometer = 0;

    public Car(maxGas, mpg) 
    {
        tankCapacity = maxGas;
        milesPerGallon = mpg;
    }

    public void fillTank() 
    {
        gasolineGallonsInTank = tankCapacity;
    }

    public void drive(float miles) 
    {
        if (miles == 0) 
        {
            print("You don't want to drive?");
            return;
        }

        if(miles < 0)
        {
            print("Ok, we're driving in reverse!");
            miles = Math.AbsoluteValue(miles);
        }

        float maxDistance = gasolineGallonsInTank / milesPerGallon;
        if (maxDistance >= miles)
        {
            odometer += maxDistance;
            gasolineGallonsInTank = 0;
            print("You've run out of gas!");
            return;
        }

        odometer += miles;
        gasolineGallonsInTank -= miles / milesPerGallon;

    }

    public float readOdometer()
    {
        return odometer;
    }

}

I said that the Car class was like a car factory, and var mySedan = new Car(12, 20) was like producing a new car with a 12-gallon gas tank and 20 mpg. Then I showed him how the methods could be run, and it was like things were happening to the car.

Then I made a second car: var myMiniVan = new Car(21.5, 14) and showed how running methods on one car didn't affect the other.

But he didn't get it. All of this went way over his head. Is there a better or simpler visual analogy I can use? Am I explaining it wrong?

Answer 1

Programming is best learned by doing.

Work with him on writing a simple address book application. (No need to save anything, as this is a OOP learning experience.) Make a class CEntry that would represent each record in the address book. It would contain things such as the person's name, street address, city, state, zip code, and phone number. The make another class CName, which would have members first, middle, and last. Finally, make a third class CPhone which would have members for country, area_code, prefix, and number. As he writes it, you can explain why the use of classes makes sense for this application, as well as the benefits and drawbacks of having CEntry inherit from CName and CPhone or contain new instances of those classes.

Answer 2

Maybe you should take a program he understands (in python for example). And show him the benefits of following a oo approach. This is how i learned C++ after having some basic C knowledge. But i thought your explanation was pretty clear already.

Answer 3

Another good analogy (especially for an engineering student) might be machine parts.

Take a carburettor. Carburrettor A is designed to meet certain spects for a certain motor, including the INTERFACE (usually sealed with a gasket which also conforms to the interface) between the manifold and carb.

There are certain holes on either surface which must line up just so, and fuel is expected to be delivered from the gas line to the carburettor at a specific pressure and volume rate. The Carb is expected to deliver a certain fuel-air mixture to the manifold for a certain vacuum pressure, etc.

This is a good starting perspective for the public interface. Carb Manufacturers dont need to know much about the motor other than the template for the interface between their carb and the manifold, and certain specs for fuel-air mixture and volume expected at the manifold. Likewise, the motor doesn't care HOW the carb does what it does, it simply needs to deliver fuel, at the proper pressure, to the proper hole in the manifold, so that the carb can perform some magic function, and deliver the proper fuel air mixture on demand. Different manufacturers may achieve this in different ways, but as long as the inputs and outputs are the same, everything works fine.

INSIDE the carb, there is all manner of stuff happening to better control the flow of fuel, and measure the vacuum pressure with pitot tubes, and such. These are akin to PRIVATE functions and methods. The means by which the carburettor knwos that, given Vacuum pressure of X, I need to supply qty of Fuel Y and air volume Z to the manifold.

While this does not necessarily do as good a job of describing Private member variables, getters vs setters, and the like, it MAY help with the concept to Interface, excapsulation, and Private vs Public methods. For me, this was initially harder to graps than private member variables and such (especially the "Interface" part . . .).

Answer 4

Does he like beer? http://keithchadwick.wordpress.com/2010/03/20/the-oo-beer-case-analogy/

Answer 5

Our teacher used:

• cars and their components - to explain classes, fields, methods, and to show what is aggregation and composition
• animals (man, tiger and cat, exactly :)) - to explain inheritance
• shapes - to explain more inheritance and polymorphism

Also, as far as I remember, there were some good examples in OOA&D book by Grady Booch.

On first OOP seminar we did rather unusual an interesting exercise: we implemented "classes" in C (not C++). We had to use structs and pointers to functions - this made us feel, what is state, what is behavior, what are class and objects. Then we proceeded to C++.

UPDATE

I just have remembered one more good and descriptive example of basic OOP concepts: GUI components (Buttons, TextBoxes, Captions, Dialogs). These examples are not as "abstract" as animals and cars, and they are rather descriptive - result can be seen immediately. There are many GUI frameworks, - you just can suggest your brother to play with one of them.