How do you explain OO to new programmers? [closed]

Question

My relative is studying programming and has a hard time understanding classes. He has trouble understanding for example that you need to instantiate it, that methods cannot access variables in other methods and if you change a variable in one instance of a class it doesn't change for other instances.

I've tried to use analogies like a class definition is like a blueprint of a house. And instances are houses made from that blueprint.

How do you explain classes and OO in general?

Answer 1

Seriously use Animals, it works great. And that's what nailed the concept for me years ago. Just found this C# code. It seems good

    // Assembly: Common Classes
    // Namespace: CommonClasses

    public interface IAnimal
    {
        string Name
        { 
             get; 
        }
        string Talk();
    }

    // Assembly: Animals
    // Namespace: Animals

    public class AnimalBase
    {
        private string _name;
        AnimalBase(string name)
        {
           _name = name;
        }
        public string Name
        {
           get
           {
              return _name;
           }
        }
    }

    // Assembly: Animals
    // Namespace: Animals

    public class Cat : AnimalBase, IAnimal
    {
        public Cat(String name) :
            base(name)
        {
        }

        public string Talk() {
            return "Meowww!";
        }
    }

    // Assembly: Animals
    // Namespace: Animals

    public class Dog : AnimalBase, IAnimal
    {
        public Dog(string name) : 
            base(name)
        {
        }

        public string Talk() {
            return "Arf! Arf!";
        }
    }

    // Assembly: Program
    // Namespace: Program
    // References and Uses Assemblies: Common Classes, Animals

    public class TestAnimals
    {
        // prints the following:
        //
        // Missy: Meowww!
        // Mr. Bojangles: Meowww!
        // Lassie: Arf! Arf!
        //
        public static void Main(String[] args)
        {
            List<IAnimal> animals = new List<IAnimal>();
            animals.Add(new Cat("Missy"));
            animals.Add(new Cat("Mr. Bojangles"));
            animals.Add(new Dog("Lassie"));

            foreach(IAnimal animal in animals)
            {
                 Console.WriteLine(animal.Name + ": " + animal.Talk());
            }    
        }
    }

And once he's got this nailed, you challenge him to define Bird (fly), and then Penguin (fly!?)

Answer 2

The best way I got it through to my wife (a chartered accountant) is as follows.

In 'regular' programming you have data (things that are manipulated) and code (things that manipulate) and they're separate. Sometimes you get mixed up because a certain piece of code tries to manipulate the wrong thing.

In my wife's case, I said a invoice arrived (which involves no physical money changing hands) and accidentally updated a bank balance, something she immediately saw as potential fraud (she used to do forensic accounting, everything is potential fraud to her, including most of my share trades :-).

You could just as easily say that a piece of code meant to wash a floor with a huge mop decided to do it with your toothbrush.

With OO programming, the manipulators and manipulatees are inextricably entwined. You don't apply the floor washing process to the floor, instead you command the floor to wash itself. It knows how to do this because the code is part of the object, not something external to it.

In the accounting case above, I think we ended up having the chart of accounts as the object and we told it to apply a invoice to itself. Since it understood the process, it knew which accounts were allowed to be updated (creditors liability account and an expense account if I remember correctly).

Anyway, that's irrelevant and I'm just meandering now. What I'm saying is to express it in terms your target audience will understand. I suppose that's the secret of most teaching.

Answer 3

Like all old farts, I'd like to answer this with a story from my own life.

I started programming basic on a VIC-20. Not knowing anything else, I though this was how all computers were programmed. I thought it was a bit hard to keep track of which variable names I had used and which were still free, (scope problem). I also thought it was hard to divide my program into repeatable chunks using gosub-return and setting and reading the variables that these would use, (lack of methods).

Then I got into Turbo C over MS-DOS. Now I could create my own methods and functions! I was no longer stuck with the old finite set of commands in basic. I felt like I was creating a new language for every program I wrote. C gave me more expressive power.

C++ was the first object oriented language I heard about. The big moment for me was when I understood that I could create my own data types, and even overload the operators. Again, it felt like I could create my own language containing both new functions and data types, complete with operators.

That's how I would sell OO to a new programmer. Explain that it gives expressive power because they can define their own data types. I always thought encapsulation was a better selling point than inheritance.