Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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?
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:
For trucks, we need:
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:
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:
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.