most important with oo-programming?
Author
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
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
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
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.
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.
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.
Make it work. Make it right. Make it fast. Pick two.
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.
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.
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
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 nowQuote:
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.
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#
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#
Quote:Original post by NitageQuote:
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.
Quote:Original post by abstractworldsQuote:Original post by NitageQuote:
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 :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
