A good Object-Oriented analogy

Question

I'm looking for a good way to describe OO to beginners, though an analogy.

Currently I'm likening a Class to a shopping list, and a shopping trolley full of items to an object. But I feel it's a bit confusing.

Preferably the analogy would be reflected well in the code example (Ruby), currently I have this, and it feels klunky.

# First we create a class
class Shopping

    # The items method gives us a list of items in the Shopping
    def items
    ["apple", "cereal", "flour"]
    end
end

# Create a new Shopping, called basket
basket = Shopping.new

# ask the basket what items it has
basket.items        #=> ["apple", "cereal", "flour"]

Answer 1

When I normally think about the distinction between class and object, I generally tend to think of the class as a blueprint. Perhaps you could compare a class to a blueprint and a object to a house?

class House
    def floor 
        @floor
    end
    def roof 
        @roof
    end
    //[etc]
end

Answer 2

I've seen it described as Man is a class, and Steve is an object (instance of Man). Steve has blonde hair, is 6', weighs 180lbs, etc.

You can then do inheritance, so Man inherits Person, Person inherits Animal, and onward.

Answer 3

I find the car analogy to work well for an introductory-level model. Automobile can be a base virtual class, with members like make, model, an array of Tire objects, start() and drive() as methods, etc. Derived classes could include Truck, Compact, etc.

The first chapter of "Thinking in C++" has a good object model introduction: http://www.smart2help.com/e-books/ticpp-2nd-ed-vol-one/Frames.html

Answer 4

When explain OOP to a beginner I find it useful to lead with the idea that the world we live in is composed of objects and those objects interacting with each other. I like to focus on a few key analogies that show what objects are, the different ways they can be composed and related, and how these objects ultimately interact with each other:

Analogy 1: I would describe a car engine and the different parts that make it up, this gets across the idea of how objects can be used to compose different object.

Analogy 2: I would describe something like a football team and show that in this case we may have objects that are not composed of other objects but instead interact with other objects (like other players, the football, the field, etc.). I find that this helps get across the idea of how objects are able to interact and influence on another. You could also throw in some inheritance concepts here if you like (for example how all player extend football players or athletes or something like that) but keep in mind you want to keep it simple.

Answer 5

I don't think you should be thinking in terms of an analogy, but rather an elucidating example. People already think in an object-oriented way; just tell them an object is a thing and a class is a kind of thing.

Show them that 2 is a Fixnum and "hello" is a String. Then show an example of how a class describes what that kind of thing is composed of and what it can do. Any of these simple examples, like Animals or Cars, will work fine.

Answer 6

I'm no mechanic, but I often use cars as a high level example for polymorphism and hierarchy.

We have Vehicles, things that can get us around and it'd have methods and properties like Move() or Park() or PassengerCount. Examples of Vehicles can be Sedans, Vans, Trucks, and Bikes. Sedan might have methods and properties like TurnOnLights(), GallonsOfGas, and such, but under Sedan might be PoliceCar. PoliceCar can have new methods and parameters and redefine some of Sedan's methods and properties, i.e. a PoliceCar's TurnOnLights() method can do much more than a Sedan can do.

As far as instances go, you can explain to them that your car is an instance of Sedan. It's blue, has 7 gallons of gas, and can turn on its lights. Just walk through a parking lot pointing out instances: "that's a van, there's a sedan, here's a bike." Don't treat them stupid, but show them how it's a definition and relate it to a definition they already know. On a side note, talk about how the parking lot is an array of Vehicle objects. The parking lot doesn't care what kind of Vehicle it is.

There are a lot of different ways to relate private and public methods to this as well. Such as if your car has no idea how much gas another car has, or something like that.

If they're catching on, you can describe Interfaces to them by saying every Sedan (let's it's automatic to simplify things for now) has the same interface. They all provide the same method for steering, accelerating, braking, displaying gas and mileage and so on. How these features actually work can differ from instance to instance, but the same methods are made available in all Sedans. The drive does not need to know how the engine works explicitly because of this interface.

Answer 7

I prefer to use an analogy of objects being people, that communicate with each other to accomplish some goal.

In this analogy, a class might be more like a role or a job description: Bob (object) is an Accountant (class).

This isn't the typical 'thing-centric' kind of design used for beginners, but I believe it goes a long way towards helping teach concepts such as Inversion of Control and proper assignment of responsibilities.