[BlackGriffen]

Is OO programming top down, or bottom up (bottom being least complex, top being most). I remember reading something about classes, and how objects inherit the attributes of the class they are a part of, and of every class for which that class is a sub-class. Is it possible to start with the simple building blocks and build up to the most general class? I think that this may be what was confusing me so much about OO in the first place. The impression I get from reading books is that OO programming is like sculpting: start with block of wood (most general), and refine down. Problem is that I think legos: start with simple, easily understood parts (most specific), then build up (making new more general classes as needed to differentiate between similar reused parts).

Which is correct OO, or is it possible to do either?

BlackGriffen

[00101001]

I guess that by your definition, OO is bottom up. You begin with a general class and subclass that into more specific objects. The classic example is the polygon. You may have a general polygon class, subclass that into a quadrilateral and a triangle class -- subclass the quadrilateral into a rectangle class, and subclass the rectangle into a square class. No, it's not really like legos when you are building objects by subclassing.

[int69h]

I would have to say both. 00101001 is halfway right. That covers inheritance and polymorphism, or "is a". You also need to think about aggregation and composition or "has a" ie. a Shape might have Vetrtices, Coordinates in a plane, etc. This part of the process would follow your definition of top down.

I really wish I could wave a wand over you and make it "click", but the truth is understanding object oriented design requires time and practice. When it does click you will notice it for sure.

[ 01-31-2002: Message edited by: int69h ]

[Mactoid]

I see top down vs. bottom up to be a matter of design preference, not really an attribute of a language.

In any language, you can do top down by designing an interface first, then filling in the details, or you can do bottom up by writing some methods and classes and then putting them together after.

However, I think that languages with higher layers of abstraction probably lend themselves to top down design more then others.

[graffix]

I think the easiest way to gain an understanding of OO programming is just to think of the Taxonomy of the Species (if you remember Biology).
You start out at the most basic, and get more refined as you 'extend' the classes.
Here's a derived class example:
Base class: Animal
First derived classes: Fish, Bird, Mammal, Reptile, Amphibian, Mollusk, etc.
Secondary derived classes (further derived from the First generation of derived classes:
(derived from Fish) Shark, Tuna, Mackerel, etc.
(derived from Mammal) Dog, Cat, Human, etc.
(derived from Reptile) Iguana, Basilisk, etc.
(and so on...).
The basic idea is that the base class holds all the commonalities present in the derived classes (such as age, weight, etc, in this example), and as you go further out the chain of derivation, you eventually get to the point to where the derived class only contains data and methods unique to it's class (there's certain criteria separating humans from tuna-fish, but I've forgotten them at the moment... ).
Hope that helps.
g.

[00101001]

Yeah, that's what I said... but I like your example better

[larkost]

I think that we can do even better by using the leggo image:

Each individual leggo piece (in OO programming an 'instance') is a type ('class' or 'sub-class') of leggo. It could be a run-of-the-mill 2x8 full block, or it could be a 42x36 flat piece. All of these pieces have a few things ('class member attributes') that they share in common, such as the knobs on top, the grid array, and the receptacles on the bottom (ignoring smooth pieces for the moment).

So, looking at leggos, we can say that there is an 'abstract class' from which all leggos derive. This class defines the size and spacing of the knobs and recepticals, and gives a sense of up and down. It would define a few generic attributes, such as:

width (in knobs)
length (in knobs)
height (full piece, 1/3, etc...)

From there you could then start sub-classing leggos, either all directly off of this one leggo, or in a hirachical way, choosing some attribute, such as height.

Then, when you finally come to build something with your leggos you will immediately notice that you have to use many different types (classs) of leggos together to put something (a program) together.

[Detrius]

The thing you have to remember about the polygon example is that in the polygon class, you have certain functions defined. You may have a function called draw() that is defined, and you may have a setcolor() function defined. However, in the polygon class, these will not actually be implemented because they mean nothing in the polygon class (at least draw doesn't, color will). You will never actually have an instance of polygon. When you define quadrilateral and triangle, each of those will actually implement the draw() routine. In most OO languages, you can make a variable which is a reference to the base class, but let it actually refer to a subclass. Then, the draw() function is defined for that object. You tell it to draw and it actually calls the subclass routine... you see a quadrilateral or a triangle.

From the other perspective though, you may have a completely different class that defines what a color is or how a point is defined on a plane. These will be used in your definitions of the different polygons.

[AirSluf]