most important with oo-programming?

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

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 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.

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.

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 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.

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#

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.

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 :)

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.