Jump to content
  • Advertisement
Sign in to follow this  
bytecoder

OOP examples

This topic is 4866 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Does anyone have some examples where the OOP version is distinctly better than than the procedural version? Better, in this case, is based on the following characteristics: readability, flexibility, and maintainability. EDIT: I'm just curious, because OOP seems to be so popular, yet I haven't seen any reason why. [Edited by - bytecoder on July 24, 2005 3:14:53 PM]

Share this post


Link to post
Share on other sites
Advertisement
Well, one example is the ability to operate on a set of loosely realated objects through a common interface. Say for some reason you have a class that represents a text string, a class that represents a 2d rectangle, and a class that represents a 3d mesh. You want to be able to draw all objects of these types in your drawing/render system. You could have them all inherit a Drawable interface that has a draw operation. Your render system could maintain a list of Drawable objects that it could traverse while calling the draw operation for each object in the list.

You can do the same thing in a procedural language, but it requires more hand crafted code. Since inheritance is a language feature of OOP, it just works. The Win32 API has some good examples of the interface idiom executed in a procedural language.

That was really a poor explanation. Maybe someone else can word it better.

Share this post


Link to post
Share on other sites
I think the prime examples of the advantages of OOD are the GUI classes found in various frameworks. Check out Swing (Java), AWT (Java), Qt (C++) for some examples. Such big and complex beasts would easily become unwieldy, unmanageable and simnply clumsy had they been done in a procedural style/language.

Share this post


Link to post
Share on other sites
Quote:
Original post by microdot
Well, one example is the ability to operate on a set of loosely realated objects through a common interface. Say for some reason you have a class that represents a text string, a class that represents a 2d rectangle, and a class that represents a 3d mesh. You want to be able to draw all objects of these types in your drawing/render system. You could have them all inherit a Drawable interface that has a draw operation. Your render system could maintain a list of Drawable objects that it could traverse while calling the draw operation for each object in the list.

You can do the same thing in a procedural language, but it requires more hand crafted code. Since inheritance is a language feature of OOP, it just works. The Win32 API has some good examples of the interface idiom executed in a procedural language.

That was really a poor explanation. Maybe someone else can word it better.

Dynamic function dispatching (in my pet language):

def draw(rect:Rectangle):
...

...

def draw(str:string):
...

...

def draw(mesh:Mesh):
...




Quote:

A good starting point might be C++'s STL and Boost libraries.

Actually, I don't think the STL makes use of very much, or any, OOP features. I seem to recall hearing somewhere that its creator, who's name I can't remember, didn't particularly like OOP.
Quote:

I think the prime examples of the advantages of OOD are the GUI classes found in various frameworks. Check out Swing (Java), AWT (Java), Qt (C++) for some examples. Such big and complex beasts would easily become unwieldy, unmanageable and simnply clumsy had they been done in a procedural style/language.

Could you give a specific example, please?

Share this post


Link to post
Share on other sites
Quote:
Original post by bytecoder
Quote:
Original post by microdot
...

Dynamic function dispatching (in my pet language):
...

In my example, there is a kind of "is-a-type-of" relationship shared by the classes. Being able to dymically select a particular operation based on type isn't quite the same thing. The particular language I know can do both but they are different mechanisms.

Share this post


Link to post
Share on other sites
Quote:
Original post by bytecoder
Quote:

A good starting point might be C++'s STL and Boost libraries.

Actually, I don't think the STL makes use of very much, or any, OOP features. I seem to recall hearing somewhere that its creator, who's name I can't remember, didn't particularly like OOP.

Er, it uses objects, inheritance, templates, operator overloading and exceptions. What more do you want? (And that's just off the top of my head).

Share this post


Link to post
Share on other sites
bytecoder: Can you give me specific definitions of functional, procedural, and object-oriented paradigms? And how does dynamic dispatch via generic methods in your example stray from the OO paradigm?

Share this post


Link to post
Share on other sites
Quote:
Original post by OrangyTang
Er, it uses objects, inheritance, templates, operator overloading and exceptions. What more do you want? (And that's just off the top of my head).


Exceptions aren't OO, they are functional.

I think the issue (the point I was trying to make in my prior post) is that people get caught up in categorizing things when really, there is alot of overlap. There is a difference between object oriented programming and an object system. But alot of functional programming tends to take bits and pieces of OO ideas. And OO "design patterns" are mainly just ways to achieve the flexibility that functional programming offers but applied to an object system.

Share this post


Link to post
Share on other sites
Quote:
Original post by microdot
Quote:
Original post by bytecoder
Quote:
Original post by microdot
...

Dynamic function dispatching (in my pet language):
...

In my example, there is a kind of "is-a-type-of" relationship shared by the classes. Being able to dymically select a particular operation based on type isn't quite the same thing. The particular language I know can do both but they are different mechanisms.

That's correct, but such a relationship could be easily reverse-engineered by the IDE and displayed to you. In any event, sticking the draw routine inside the class violates a very important OOP principle: each class should support only one abstraction. Rendering is a different abstraction than that of string manipulation, rectangle operations, and mesh handling.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!