in reply to When are packages the right design choice?

My biggest gripe with most OO tutorials/books/whatever is that the example is usually something trivial that fits into an OO model neatly, such as types of animals or geometric shapes. In the real world, you're likely to encounter data that is not so clear.

For instance, if a person can be a member of a committee, and there can be one president per committee, should the president be considered a type of member with special status, or should the president be completely seperated from the member class? I don't think there is a right answer to that, at least not with the data provided. There may even be a completely different solution I haven't thought of. Even after getting more details, the "right" answer may not be clear.

I suggest "Object Oriented Analysis and Design" by Grady Booch. It's one of the few OO books I've seen that gives you examples that are small enough to be understood, but large enough to reflect the way a real program could be structured.

----
send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.

  • Comment on Re: When are packages the right design choice?

Replies are listed 'Best First'.
Re^2: When are packages the right design choice?
by samtregar (Abbot) on Jun 03, 2004 at 22:42 UTC
    My biggest gripe with most OO tutorials/books/whatever is that the example is usually something trivial that fits into an OO model neatly, such as types of animals or geometric shapes. In the real world, you're likely to encounter data that is not so clear.

    I agree. I worked hard to avoid using "a square ISA rectangle" type examples in my book. My primary OO example class is a logger called BOA::Logger for the fictitious Big Ol' Application. Instead of talking about inheritence as a way to express "natural" relationships, I tried to present it the way it's really used - as an extension mechanism to enhance an existing class. I also tried to give equal time to composition, an alternative to inheritence which often results in simpler code with equal or greater flexibility.

    -sam

[reply]
      I worked hard to avoid using "a square ISA rectangle" type examples in my book.

      And that while that's a great example to explain why MI is so useful. A square is both a rectangle and a rhombus, but a rectangle that isn't a square isn't a rhombus, and a rhombus that doesn't have square corners isn't a rectangle. And both a rhombus and a rectangle are parallelograms.

      Abigail

[reply]
        That sentence just about sums up why I try to minimize on inheritance :-)
[reply]
        I don't think that's a good example of MI, and the big problem with "square ISA rectangle" is that it's often exactly backwards. If a square has just a width, but a rectangle has a width and a height, and the rectangle is mutable, then rectangle should be a subclass of square, not the other way around. Otherwise, there's nothing sensible to do if someone calls setHeight on your Square. Again, depending on your application. If you're trying to prove theorems about your geometric objects instead of draw them on the screen, square should indeed be some kind of a specialization of rectangle.
[reply]
Re^2: When are packages the right design choice?
by adrianh (Chancellor) on Jun 07, 2004 at 10:36 UTC
    I suggest "Object Oriented Analysis and Design" by Grady Booch. It's one of the few OO books I've seen that gives you examples that are small enough to be understood, but large enough to reflect the way a real program could be structured.

    I'd recommend Meyer's "Object-oriented Software Construction" for similar reasons.

[reply]

In Section Meditations