Defining OOP for a new programmer.

Question

In teaching a first language to someone with no programming background I am having a hard time defining OOP despite the fact that I prefer OOP, how can I define OOP to someone with little (or zero) programming experience?

Answer 1

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 2

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 3

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 4

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 5

Don't waste time "defining" OOP.

Just use an OOP language for all your examples.

Objects are trivially obvious. The real world is full of objects.

Don't "define" objects. Just show programming examples, the 'objectness' will be obvious.

People with no programming background don't have silly expectations based on procedural programming.

People who learned COBOL or Basic will have problems.

---

Parts of this depend on the language. Some languages make OOP hard.

For example, in C++, the "class" is just definitional. It doesn't exist as a discrete object at run-time.

In Java and C++, some things are objects, but a few "primitive" types are not objects.

Some languages make OOP easier.

Python and Smalltalk everything is an object. There are no primitive types to muddy the waters. When you learn OO in a language like Python, the objectness is clear and obvious because it pervades everything. Just like the real world, where objects are everywhere.

Answer 6

Whoever you are explaining this to needs to know what basic programming is before he can learn what OOP means, as it's a branch of programming languages. He can never understand what makes OOP special if he doesn't know its counterparts. So your question has two parts; how to explain what a programming language is and what separates OOP from other programming languages.

The easiest way to explain him what programming in general is about, is compare it to math operations. You can explain it by defining programming as a number of math expressions taking an input which results in an output. How far you wish to elaborate is up to you.

With this explanation we've done the ground work to make him understand what OOP means. Now we can define Objects as sets of mathematical functions and data. So instead of treating the logic as global chunks of code, we gather these chunks of code inside objects to gather relevant code pieces and get a way to isolate them. From this point on you can explain more advantages that come with the Object abstraction (e.g. polymorphism, loose coupling).

Answer 7

Let's say that you want to describe a family of Things that all share the same Attributes, but might have different names, colors, or other cosmetic differences.

For example, you want to describe the Vehicles that a family has in the garage. There are Attributes of each Vehicle of interest to you:

1. What is the Model and Year of each Vehicle?
2. How many Wheels does a Vehicle have?
3. Who are the People that drive a given Vehicle?

In this case, you might have a set of two Vehicles, such that the following is true:

Vehicle A's Model is a Toyota.
Vehicle A's Year is 2001.
Vehicle A has four Wheels
Vehicle A is driven by Mom, Dad, and Junior

Vehicle B is a Moto Guzzi
Vehicle B was made in 2004
Vehicle B has two wheels
Vehicle B is driven by Dad

In various languages, you might very roughly refer the two examples in the following equivalent way:

A = new Vehicle();
A.model = "Toyota";
A.year = 2002;
A.wheelCount = 4;
A.drivers = [ "Mom", "Dad", "Junior" ];

B = new Vehicle();
B.model = "Moto Guzzi";
B.year = 2004;
B.wheelCount = 2;
B.drivers = [ "Dad" ];

In OOP, you are Encapsulating the attributes of these vehicles, so that you can describe them by their Features. Your job is to write code to get and set the values of these features (as well as do other interesting things with these features).

Further, you can "subclass", which is a way to re-use an object in different contexts. For example, you could use more specific Vehicle object types, such as Car and Motorcycle, which inherit their features from the description of Vehicle:

A = new Car();
B = new Motorcycle();

Car and Motorcycle objects are more specific descriptions of a Vehicle. These two subclasses can have their own special attributes. A Car might have Childproof Locks, whereas a Motorcycle would generally not have such need for a thing.

Instead of setting the Childproof Lock attribute of a Vehicle, you can say that only a Car has a Lock attribute. This makes your Vehicle description cleaner and easier to write and maintain.

Answer 8

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?

Answer 9

Object Oriented Programming in lay speak:

1. Everything in your program is a thing (Object). This thing has properties that explain it (size, shape, color, etc.)
2. The programmer asks the thing to do stuff/answer questions: Make your size big (setSize) or What's your size (getSize)

The thing takes care of adjusting its properties only when you ask it to (call a method). You cannot directly examine or change thing's properties. You can only examine or change the properties thing lets you see. Therefore, thing can ensure properties are viewed and changed properly.

This prevents the programmer from telling thing its size is red. If you directly tell thing to make its size red it should refuse (red isn't a valid size). Additonally, it allows things to manage the side effects of changing its properties.

Suppose thing's originalSize is big. If I just change thing's size to small, I have to remember to tell thing that it is no longer its originalSize. If I ask thing to change its size to small it will change its size to small AND change the originalSize to false. Now when I ask thing if it is its originalSize it will respond with a no.

Essentially this allows you to package your data and functions together making things more modular/compartmentalized. This allows you to better organize code and more easily reuse code. OOP isn't anything super special, just a way to better organize your code. Not critical at the beginner level, but critical to larger projects. Within an Object's functions things generally become more procedural like a beginner is used to.

Answer 10

Any explanation of OOP depends strongly on the explainer's interpretation of the concept. My interpretation of the concept goes something like this.

The real world is largely understood as a set of actors. Each actor has a collection of properties and behaviors. In most cases, the properties of an actor is expressed in terms of it's behaviors, in relation to its interaction with other actors.

A computer program is usually a simulation of some real-world process, so it usually helps the programmer to build the program based on a actors-behaviors-properties model. That is, each element of the whole program can be divided into smaller programs that represent single actors.

Of course you can only take that so far. Not everything we want to model is a single actor. For instance, currency is conserved, but in many ways infinitely sub dividable.

Also, other ways of modeling the real world may offer more rigorous correctness guarantees at the cost of a greater abstraction, such as a relational model, which derives from set theory. OOP has no such mathematical foundation.

Answer 11

It's strange. You're asking about teaching OOP to people who know nothing about PROGRAMMING and everyone is answering "How to teach OOP?"

The answer is, you do not. How do you teach functional programming to someone who has never programmed? You don't. You have functions, code is crammed into them, they get reused, etc. In Java, all of your code must be in a class. What is a class? It's, first and foremost, a place to put your code. Programs start at the Main method. Later on, you can instantiate it, and each class has its own methods and properties. And then you talk about static methods and variables. And then sometime later you talk about polimorphism and inheritance. And sometime in there they begin to design their own APIs and use servlets and persistent classes or whatever the latest thing to implement is (snervlets? IHibernate?)

But if you've never seen programming before, there is no need to sit down and have the big OOP chat. That is only necessary if you're saving someone from non-OOP programming. Just teach programming. OOP programming? Is there any other kind? Yes, but we're not teaching that today, so let's not worry about it.

[By analogy: when you go to a martial arts class, they don't usually spend a lot of time explaining. First you stretch, they make you work out, and then they teach you some techniques. If you're interested in figuring just which martial art you're studying, you head to the library.]

Answer 12

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 13

Here's a simple definition.

Gun gun = new Gun(new Bullet);
gun.Aim = Appendage.Foot;
gun.PullTrigger();

;)

Answer 14

An object is a just a thing with a bunch of named properties. The values of these properties define the state of an object. Interaction between objects is done via message passing. A message consists of a name and a bunch of parameters. When an object receives a message, the message gets processed by the object. Processing a message may result in a change of the state of the object and messages being sent to further objects.

Answer 15

its as easy as pie spelled backwards. the 3 basic principles of oo are:

encapsulation inheritance polymorphism

show the newbie the code for the standard draw shapes example that is found in most oo programming books. also show them the non-oo code using lot's of switches with global data.

they should get some feel for oo based on the organizational differences between the two sets of code.

Answer 16

yes , thank you for your valuable web site , it's really very helpful to any one looking to be smart .

my question is do i have to be familiar with oop before getting zend certificate ? there are many frameworks for php like joomla durbal zend pear and many others which one can i pick and keep it in my pocket .?

thanking you sayed ali - cairo - egypt