HOME       >>       Programming

Why Must We Learn Object Oriented Programming help me to understand the benefit of OOP


.hack//GU

As a software laboratory assistant, I teach the class of Object Oriented Programming. Everything went well until one day a student of mine ask me a simple problem like this Q/A:

 

him : Why must we use Object oriented Programming? I thought the usual one could do almost everything.

me : Well, in Object Oriented Programming we could make a class, so basically eveything could be made to an 'object' in our mind.

 

him : That's why I'm asking, why must we made everything an object? What's the difference?

me : In Object Oriented Programming, Encapsulation is the basic part and because of that concept, we could make an object with parameters / data and methods / functions in just one object / class.

 

him : Are you saying the programming will be simpler?

me : Not really, but in our mind it is far easier when the class is made up and we just use the object freely in our program.

 

(okay, that's the intro, now the things I couldn't explain...)

 

him : Just in case I made the program in usual (not OOP), what's the difference?

me : well, you can hide the data in data hiding concept of encapsulation.

 

him : We hide data from our own selves as programmers, if we didn't let the user do something the data won't be shown and we don't need to hide any data.

me : I guess... that's how we put it... hmm, in OOP we could use spesific methods related to spesific class I think.

 

him : Instead of using like ball.animate() why don't we use animate(ball) (ball in struct)? It is easier right?

me : But, to make animate() for several class inhereted from one, we can use similar name.

 

him : Just use if... just like this void animate(struct ball ball) { if(ball.type==1) animate1() else if(ball.type==2) animate2(); } we could do it right??

me : ...

 

So I couldn't say anything to him, only to promise him to answer next time I teach them next Tuesday...

I've questioned the same ones to my friends but none of them can help. Please someone help me...


pointybirds

Hi,Certainly there are some things you can do adequately with good old procedural programming -- Turing even posited that you can simulate any possible computer with a few symbols -- it's just that certain types of programming problems lend themselves better to the OO way of doing things, and I'm thinking specifically of two of OO's main features: inheritance and polymorphism.To use your ball example, the code could become unwieldy when you start getting lots of different ball types, and you have to keep track of them all manually with a .type element in a struct, and select between them with IF statements. The OO folks would have you create an overarching "ball" class, with basic actions for a ball such as bounce(), rollI(), animate() etc. Then, for different types of ball, you subclass this into classes like Football and Tennisball and override the generic methods as required ... some balls bounce higher than others, that kind of thing. Now the code itself is taking care of what _particular_ subclass an object is, and you don't necessarily have to know or care. You can also code other objects with animate() methods, and call them in a loop:for object in (objects) { object.animate()}There's nothing invalid about the procedural way of doing it, it's just not as clean and maintainable for certain applications such as GUI programming where objects fall naturally into classes. Also, I think you'll find that if you do it procedurally you'll spend a lot of your time reinventing ways of dealing with objects that OO specifically sets out to solve.I would suggest reading up on some of the fundamentals of what makes OO OO (if that makes sense) before your next class so you don't get any more zingers. I've been there before and it's not comfortable. Good luck.


djole_home

OK I prefer use of strict C bat C++ have one advantage you forget! Code reuse! I make some class and do not have to write same code again if I need object like this with some more property or method, just inherit from parent class and code additional elements.


Tetraca

I don't personally like Object Oriented Programming. Procedural programming is what I like. I find that it has a better logical flow. Which one you want to program with is up to you. Rich Stallman actually hates OOP but other people actually like it. Whichever you can program more competently in is what you should use, and it is truly your option for many popular languages.


galexcd

I also dislike object oriented programming. When I have a choice between it and regular coding I always choose structured, regular coding. BUT it is sometimes necessary to use OOP (or at least OOP would make it WAY easier). For example if you are creating a game or a simulation where you must control many different instances of an object like an enemy or whatever the simulation is simulating. Instead of creating an array and hardcoding all of the objects into the program it is much easier to make a class and make instances of that class (for me at least). For your ball.animate example, what if the animate function changes ball in some way? that would be impossible using animate(ball) unless you are using pointers which is extremely annoying to me.


Tran-Gate

With Oriented-Object Programming (OOP), you can encrypt data making it safe with encapsulation? Can you also have an object access a general class of attributes/elements? I am confused on what an object is.... Game-wise, is it like an object in a game kinda like what pointybirds said where it has somewhat like characteristics?

To use your ball example, the code could become unwieldy when you start getting lots of different ball types, and you have to keep track of them all manually with a .type element in a struct, and select between them with IF statements. The OO folks would have you create an overarching "ball" class, with basic actions for a ball such as bounce(), rollI(), animate() etc. Then, for different types of ball, you subclass this into classes like Football and Tennisball and override the generic methods as required ... some balls bounce higher than others, that kind of thing. Now the code itself is taking care of what _particular_ subclass an object is, and you don't necessarily have to know or care. You can also code other objects with animate() methods, and call them in a loop:

Objects like cars, houses, people, creatures, etc.?

xpress

With Oriented-Object Programming (OOP), you can encrypt data making it safe with encapsulation? Can you also have an object access a general class of attributes/elements? I am confused on what an object is..

Objects like cars, houses, people, creatures, etc.?


No No No...Encapuslation is not Encryption. Even they have no relation at all. Encapusulation is hiding data. It is the mechanism that binds the code and the data it manipulates.... OK, I will make it clear with an example.

 

First let us see what is a class, object etc...later we will see these definitons relate to our example. Later we will go to encapsulation.

 

Class: A class is a logical construction. It defines the structure and behavior (data and code) that will be shared by a set of objects.

 

Object: Object is the physical reality of the class.

 

For example, As you said, we can call cars, houses etc....as Objects. Then what is a class? It is logical construction of the object. That is for example, A Four Wheeler is a class. It is logical. Four wheeler can be anything. A car, a bus, a jeep.

 

So The Class FourWheeler defines that a FourWheeler has Four wheels, It has a steering, it has breaks. This is the structure of the FourWheeler.

 

And, The behavior of FourWheeler is, it runs when you press accelerator. It stops when you apply break. So we can call accelerate and pressingBreak as methods(or functions).

 

And A Car is one Object of FourWheeler. It has 4 wheels, it has steering etc...It runs when you press accelarator.

So the Object Car has all properites of its Class FourWheeler. A bus is also an object of FourWheeler class. It has the same properites. If you change the behavior or structure of the class, all of its objects will be affected.

I think, it is clear to you now, what is object and what is class.

 

OK, lets move to Encapsulation. I already told you, encapsulation is hiding data. But how? With encapsulation, data in a

class can be kept private and cannot be accessed directly outside by its class. So, with encapsulation data can be kept safe from corruption. You can access this data only by well defined methods(or functions).

 

Lets see it by taking our Forum as an example. As a normal member of this forum, you can make a new post. You can also edit your post. But, can you edit other's posts? No. Why? That is encapsulation. Your posts are private to you. Others have no access to edit your posts. Edit button( simply Edit function) is well defined function for your post(data). But Editing to your post is visible to you only. Others cannot see it. So the data is hidden from them.

 

I hope you understand it now. Ask any doubts you have, if you don't understand this.

 

And about our concept, Why must we learn Object Oriented Programming....

Object oriented programming is meant to manage the complexity easily. For small programs, the procedural programming (structured programming) looks easy, but as the program grows longer and logner (complexity increases) it is very difficult to

write and manage the program. Object oriented programming makes it easy. And also with OOP it is very easy for teams to work on a single project. Procedural programming is based on flow charts and top down approach. OOP based on Objects.

Pesonally I prefer Object Oriented Programming.


Sandeep Singh

Hi,
Certainly there are some things you can do adequately with good old procedural programming -- Turing even posited that you can simulate any possible computer with a few symbols -- it's just that certain types of programming problems lend themselves better to the OO way of doing things, and I'm thinking specifically of two of OO's main features: inheritance and polymorphism.

To use your ball example, the code could become unwieldy when you start getting lots of different ball types, and you have to keep track of them all manually with a .type element in a struct, and select between them with IF statements. The OO folks would have you create an overarching "ball" class, with basic actions for a ball such as bounce(), rollI(), animate() etc. Then, for different types of ball, you subclass this into classes like Football and Tennisball and override the generic methods as required ... some balls bounce higher than others, that kind of thing. Now the code itself is taking care of what _particular_ subclass an object is, and you don't necessarily have to know or care. You can also code other objects with animate() methods, and call them in a loop:

for object in (objects) {
object.animate()
}

There's nothing invalid about the procedural way of doing it, it's just not as clean and maintainable for certain applications such as GUI programming where objects fall naturally into classes. Also, I think you'll find that if you do it procedurally you'll spend a lot of your time reinventing ways of dealing with objects that OO specifically sets out to solve.

I would suggest reading up on some of the fundamentals of what makes OO OO (if that makes sense) before your next class so you don't get any more zingers. I've been there before and it's not comfortable. Good luck.


Notice from serverph:
copied from old Xisto post


Tran-Gate

xpress.....I LOVE YOU~!!! I always find you helping me with questions or doubts. So Encapsulation is hiding data. Encryption is transforming information using an algorithm. A class is a set of properties. Objects of a class are like things that contain properties of the class. THANKS XPRESS~!! Oh, and if I misunderstood, please PM me. =)



VIEW DESKTOP VERSION REGISTERGET FREE HOSTING

Xisto.com offers Free Web Hosting to its Members for their participation in this Community. We moderate all content posted here but we cannot warrant full correctness of all content. While using this site, you agree to have read and accepted our terms of use, cookie and privacy policy. Copyright 2001-2019 by Xisto Corporation. All Rights Reserved.