A good Object-Oriented analogy [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

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"]

---

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.

---

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.

---

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

---

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.

---

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

---

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.

---

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.

---

If you're going to think about it deeper, Industrialism says a lot about Object Oriented Programming. In Object Oriented Programming, one class is considered one Employee/Person. One method is considered one Process/Skill/Info owned by the Employee/Person. One package is considered one Company.

Important: Always think like it's your own Industrial Company. You're the Manager. The executive! You make Person/Employees/Class work! Then, if you are really good at this:

• You can use other Employee/Person/Class from different Company/Package. (Hire them! Pirate them!)

• If the Employee/Person/Class has no Skills/Process/Info/Methods to do it, delete them. (Fire them!)

• If the Company/Package that you built is growing. Add Employee/Person/Class. Then, you want to add Skills/Process/Info/Methods to do it, program them in how you want them to do it. (Hire them! Train them!)

• If you don't like the Company/Package you are working with, find other Company/Package that has great Skills/Process/Info/Methods. (Sign other contracts with other companies.)

• If you don't like the Person/Employee/Class, find other Person/Employee/Class that has better Skills/Process/Info/Methods. (Hire somebody else to do the job.)

• If your Person/Employee/Class is a good Salesman and he gets promoted, he becomes the Person/Employee/Class Sales Manager and he gets more Skills/Process/Info/Methods, but still is selling. (Give him more task!)

Just don't be too rude to your people, or else, they will rebel. (Of course, this is not going to happen.)

Read more...