Jump to content
  • Advertisement
Sign in to follow this  
suliman

most important with oo-programming?

This topic is 4768 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

Salutes I started programming in Pascal, which is procedure-based and moved to c++ later on. My q is weather im on the right track with oo or not. 1. I inherite classes only sometimes, but my games seldom seem to benefit from it. 2. I often let classes have their own member-function, rather then doing everything globally (as I did in pascal). Other then that, I guess I think pretty procedural. What is the most important thing with oo in your oppinion? What should you think about? Thanks for sorting me out Sulliman, Sweden

Share this post


Link to post
Share on other sites
Advertisement
OO shall hide the implementation for the user of the objects
although get/set functions are hardly used only for really critical implementations

i see the major benifit of oo in code reuse you build a baseclass and derive children classes

i suggest to get the book 99 C++ gotchas it has a good explanation of proper class hierarchy building

and a lot of other tips and tricks that make life easier

Share this post


Link to post
Share on other sites
Think of objects in terms what you can do with them, i.e. a sound can be played, or a door can be opened. Object oriented programming puts data and the functions that work on this data together, and calls it a class.

If you have two places where you wrote (almost) the same code, you should think about inheritance. If you can factor out that code easily, go for it; you will have only one place where an error could be, this simplifies debugging.

Virtual functions are nice to link your code at runtime. You provide different implementations for the same interface, then decide at runtime which one to use.

Share this post


Link to post
Share on other sites
If the objects in your system are not hierarchically related, don't create a class hierarchy. Inheritance is only one part of object orientation, and hardly the most critical. It is very often abused in C++ because of the static typing constraint which doesn't allow type-agnostic runtime dispatch (calling identically named methods on unrelated types, say, in a sequence or container).

Make it work. Make it right. Make it fast. Pick two.

Share this post


Link to post
Share on other sites
Don't get too hung up on inheritance. Encapsulation is a much more useful concept in many ways.

Many newcomers to OO design create hierachies 5-10 classes deep. The more I use OO design, the more often I find myself using hierachies only 2 classes deep (an interface class and several implementations, all direct children of the interface).

Also don't feel obliged to put everything inside a class - somethings just don't fit elegantly into a pure OO design.

Share this post


Link to post
Share on other sites
Quote:
Original post by sulimanWhat is the most important thing with oo in your oppinion?
IMO, the most important thing with oo is not how it is done at the technical level, but what it achieves at the high level.

Ask yourself the following questions about your oo design...

1. is it giving you a fairly accurate model of the real world items you are modelling in your software

2. is it allowing you to manage the complexity of building a large piece of software

3. are your objects smart or do they constantly have to be told how to do things by other parts of your software

4. is it giving you understandable and maintainable code

5. is it giving you any reuseability

Share this post


Link to post
Share on other sites
Quote:

Ask yourself the following questions about your oo design...

1. is it giving you a fairly accurate model of the real world items you are modelling in your software


Usually a very bad idea. Objects should not reflect real-world items - these are far too likely to change, and the world cannot be cleanly split into distinct objects. Trying to do this invariably leads to mulitple-inheritance maddness.

i.e.


EDIT: I've given up on the Ascii art for now




Quote:

2. is it allowing you to manage the complexity of building a large piece of software

3. are your objects smart or do they constantly have to be told how to do things by other parts of your software

4. is it giving you understandable and maintainable code

5. is it giving you any reuseability


The whole point of OO is that if it is done properly you get all these automagically.

Share this post


Link to post
Share on other sites
As for 2

Large and complex systems were built well before the invention of OOP concepts and tools.
Design your program well, and implement it well, no matter what methodology or tool do you choose. It is the will of the Ori.

Tom#

Share this post


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

Ask yourself the following questions about your oo design...

1. is it giving you a fairly accurate model of the real world items you are modelling in your software


Usually a very bad idea. Objects should not reflect real-world items - these are far too likely to change, and the world cannot be cleanly split into distinct objects. Trying to do this invariably leads to mulitple-inheritance maddness.

What I'm getting at here is model your software closely to the real world in terms of 'is a' relationships (inheritance) and 'has a' relationships (containment). As said earlier, if in the real world there are no hierarchies don't put them into your software model. A piece of fruit is not a piece of furniture, a chair is a piece of furniture, a chair has a leg. A closely modelled piece of software should be better suited to change, the same is true for a closely modelled relational database.

Share this post


Link to post
Share on other sites
Quote:
Original post by abstractworlds
Quote:
Original post by Nitage
Quote:

Ask yourself the following questions about your oo design...

1. is it giving you a fairly accurate model of the real world items you are modelling in your software


Usually a very bad idea. Objects should not reflect real-world items - these are far too likely to change, and the world cannot be cleanly split into distinct objects. Trying to do this invariably leads to mulitple-inheritance maddness.

What I'm getting at here is model your software closely to the real world in terms of 'is a' relationships (inheritance) and 'has a' relationships (containment). As said earlier, if in the real world there are no hierarchies don't put them into your software model. A piece of fruit is not a piece of furniture, a chair is a piece of furniture, a chair has a leg. A closely modelled piece of software should be better suited to change, the same is true for a closely modelled relational database.


If you do that then you'll end up hard coding spurious assumptions into your code, like this:
Quote:
a chair has a leg



Quote:

It is the will of the Ori.


Let's try to stay on topic :)

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!