Sign in to follow this  
suliman

most important with oo-programming?

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
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
Guest Anonymous Poster
Basically it is impossible to get people to agree on how object oriented programming should work; they have completely contradictory ideas about it. Therefore, design your system in a way that makes sense, and let the object oriented zealots (most of the programming world, unfortunately) look at it and complement you on how object oriented it is afterwards.

Share this post


Link to post
Share on other sites
Quote:
Original post by tompp
Large and complex systems were built well before the invention of OOP concepts and tools.

Were they, now? What's to say these systems to which you refer weren't large and complex merely *because* they didn't have a superior methodology like OOP to support them?

Quite frankly, I find this relativistic "all paradigms are created equal" notion to be quite cowardly and ridiculous.

It's interesting to note that Fred Brooks in "The Mythical Man Month" points out that moving to higher level languages (OS/360 was developed in assembler) would give the most benefits in moving towards faster development of complex systems. Also, in "No Silver Bullet", which looks back on the essays from TMMM, he points out that OOP is one of the things that have come closest to being a silver bullet.


Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this