Defining OOP for a new programmer [closed]

Answer 1

I would explain it as a way of modeling real world information. There's a common analogy using cars and vehicles to show type hierarchy. I think it's simple enough for most people to understand, if you explain it correctly.

Perhaps you should begin by explaining primitive types, then talking about composite types like structs, then show how such types can be related as classes using inheritance.

Edit: After thinking about it, the animals example is much better. See Explaining OOP without Mentioning Classes and this SO thread about the same subject.

Answer 2

A sports team. The players of the field/court at any one time may be specified in terms of the positions they play. However the entire team may have multiple members who can play a given position.

Each position is like a class in OO; it specifies a set of responsibilities. The team members are instances of those classes.

Plays in the playbook are patterns. Each one specifies how to achieve a specific result through the interactions of (instances of) positions (classes).

Answer 3

Well, you should use examples. One example most people understand is in reference video games. So, you have monster objects and monsters have certain attributes like color, size, shape, number of arms, and so forth. Then some monsters have different "abilities" like breath fire, shoot guns, so on and so forth. These are silly examples but easy to understand. I think it is easier to explain to a novice than all this business about "squares," "circles," and so forth.

Answer 4

As far as I know, object oriented programming originally means that you organize all the concepts of your program into objects and then define all the logic flow as messages between those objects. I think that in order to understand the original intent, you have to learn Smalltalk.

Answer 5

You might try something like the following approach, which I modified slightly here from a post on a forum I made a while ago:

The most basic set of vocabulary for OOP is a class, a method, and a parameter.

A class is a set of functions that work together to accomplish a task. An instance of a class is considered an object.

A method simply refers to a function that is encased in a class.

A parameter is a variable that is passed into a function that instructs it how to act or gives it information to process.

If you do a bit of digging, you'll find a wealth of information about design patterns. Some of these might be useful to look at, though I'd be careful about getting into them too much at first because they can be overwhelming. There are two helpful (and somewhat overused) acronyms you might keep in mind when trying to get yourself into an OOP mindset: DRY and KISS.

DRY stands for Don't Repeat Yourself and it means just that. If you write some code, you shouldn't have to repeat that particular code ever again. In practical terms, it means thinking more abstractly and planning a little better at the outset. I'll give an example shortly.

KISS stands for Keep It Simple, Stupid and means that you should try to write code that accomplishes its goal in the simplest manner possible. Simpler means fewer possibilities for errors and easier maintenance. In the context of OOP, this usually means making sure that each method or function has only one task. If you find that a method does more than one thing, it usually means that it can be refactored into several smaller methods, each dedicated to a specific task.

Now for a simple example (someone might be able to come up with a better one, but go with me on it for now):

Let's say that you need to program two different forms, one that processes information about cars and one that does the same for trucks.

For cars, we will want to record the following info:

• Color
• Engine Size
• Transmission Type
• Number of doors

For trucks, we need:

• Color
• Engine Size
• Transmission Type
• Cab Size
• Towing Capacity

In procedural programming, you would write the code first to process the car form and then the code for the truck form.

With object-oriented programming, you would write a base class called vehicle that would record the common characteristics what we need from both trucks and cars. In this case, the vehicle class will record:

• Color
• Engine size
• Transmission type

We'll make each one of those characteristics into a separate method. The color method, for example, could take the color of the vehicle as a parameter and do something with it, like storing it in a database.

Next, we will create two more classes: truck and car, both of which will inherit all of the methods of the vehicle class and extend it with methods that are unique to them.

The car class will have a method called numberOfDoors and the truck class will have the methods cabSize and towingCapacity.

Okay, so let's assume that we have a working example for both procedural and OO programming. Now, let's run through a few scenarios.

Scenario 1: Suppose that we suddenly need to add a bus form, that records the following information:

• Color
• Engine Size
• Transmission Type
• Number of passengers

Procedural: We need to recreate the entire form, repeating the code for Color, Engine Size, and Transmission Type.

OOP: We simply extend the vehicle class with a bus class and add the method, numberOfPassengers.

Scenario 2: Instead of storing color in a database like we previously did, for some strange reason our client wants the color emailed to him.

Procedural: We change three different forms: cars, trucks, and buses to email the color to the client rather than storing it in the database.

OOP: We change the color method in the vehicle class and because the car, truck, and bus classes all extend (or inherit from, to put it another way) the vehicle class, they are automatically updated.

Scenario 3: We want to move from a generic car to specific makes, for example: Nissan and Mazda.

Procedural: We create a new form for each make, repeating all of the code for generic car information and adding the code specific to each make.

OOP: We extend the car class with a nissan class and a mazda class and add methods for each set of unique information for that car make.

Scenario 4: We found a bug in the transmission type area of our form and need to fix it.

Procedural: We open and update each form.

OOP: We fix the transmissionType method in the vehicle class and the change perpetuates in every class that inherits from it.

As you can see from the above scenarios, employing an OOP style has significant advantages over procedural programming, especially as your scale increases. Consider the savings we would receive from OOP in terms of repeated code, flexibility, and maintenance if we also had to add forms for boats, motorcycles, planes, go-karts, ATVs, snowmobiles, etc.

Objects and methods are also far easier to test than procedural programming by using unit testing to test results.

Does this mean that you should never use procedural programming? Not necessarily. If you're doing a mockup or a proof-of-concept app, you might not have the time to make everything object-oriented and so I think it might would be better to use procedural programming for a prototype, but it would be best to make the production product in an OO-manner.

Answer 6

I use the 'bouncing balls'example. Imagine you have a box with one bouncing ball inside it.

You can program it in 2 ways:

One way is to run a loop, keep track of the current position of the ball, calculate the next position, check for collisions, erase from the current position, draw it in the new position. repeat.

The other way is to let the ball keep track of its own position and orientation and teach it to calculate the next position and how to move there and how to handle collisions. Then, run the loop and tell the ball to keep updating itself.

Now imagine you have 100 balls. Then there are heavy balls and light balls and exploding balls. These are basic balls with added characteristics. Would you still use method 1?