I tend to think that a child class is really an instance of that class. A parent class is just a place to put information/capabilities that two separate and related classes will use. For example, If you have Games::Board::TicTacToe and Games::Board::Othello, the ability to place a piece on the board is going to be the same. The vector used to represent the board (barring size differences) is going to be the same. The fact that both use a size at all is the same. So, put that code in one place and have both inherit from it.
Now, I'm also a big fan of multiple inheritance, separating out functional areas. For example, Games::Board::Othello inherits from Board and Othello. Games::AI::Othello inherits from Games::AI, Games::Interface, and Games::Othello. And, so on.
Now, all of those superclasses are completely orthogonal, which is the only thing that makes this work. They do all inherit from Games::Base, but that defines things like BLACK, WHITE, and the like. (Granted, those definitions will actually be pulled out into other classes in the next iteration, but that's another story.)
Now, I've never worked on a "true" OO project in a "true" OO language. I know C++ and can read Java, but Perl is my major OO experience. (Just as it's my major functional experience, and I know that I have a bastardized idea of that, too.) The important thing, to me, is that it works (Criterion #1) and is maintainable (Criterion #2). It just may be maintainable only in my twisted mind. :-)
------
We are the carpenters and bricklayers of the Information Age.
The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
In reply to Re: subclass data clobbering superclass data
by dragonchild
in thread subclass data clobbering superclass data
by princepawn
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |