OO design need to satisfy IS-A/HAS-A relationship?
Monkey Archive Forums/Digital Discussion/OO design need to satisfy IS-A/HAS-A relationship?
| ||
| I'm going through the "Object-Oriented Thought Process" book and I'm beginning design of a card game app (not part of the book.) The card game can have a few players and one dealer. I started writing down all the attributes I foresee the Player class and Dealer class having. I noticed both classes have some of the same attributes so I put those attributes under a Person class expecting Player and Dealer would inherit from it. I then noticed all of Person class attributes were the same as the Dealer class attributes with no additional attributes. So I scratched the Person class and decided Player could inherit from Dealer. However, a Player IS NOT A Dealer in my card game. (NOTE: I have not considered the behavior in each class but lets assume the Player class will have all the behavior the Dealer class has plus more.) Should a class extend another class because it has the same attributes and behavior? Or should it extend another class because it satisfies IS-A relationship? |
| ||
| Well, don't overengineer that stuff. OO design is ONE possibility but not necessarily the best for all cases. ;) Not a helping answer I know but I've seen more fancy patterns than I ever wanted to. ;) |
| ||
| I have not considered the behavior in each class but lets assume the Player class will have all the behavior the Dealer class has plus more. If the Player had all the data attributes and all the behaviour of a Dealer then it would be a Dealer. This assumption seems more than a little shaky. |
| ||
| I don't think I'm over-engineering it; Monkey is an OO language and inheritance(IS-A) and capacitance(HAS-A) are basic OO features. And the only design pattern I know at the moment is Singleton taken from Mike Hartlefs book, "Monkey Game Development Beginners Guide". muddy_shoes, your two points are valid... 1) If Player class extends Dealer class then from an OO perspective a player "IS A" dealer but in my card game a player should never deal. So I take it, Player class should not extend Dealer. 2) It's likely Dealer will have some behavior that Player does not, such as a DealCards method. So again Player class should not extend Dealer. Do I go back to using a Person class having attributes and behavior that Player and Dealer have in common? Where Player and Dealer extend Person? |
| ||
| What about "dealer IS-A player" with enhancements? Or maybe, Person -> GameParticipant -> Player Person -> GameParticipant -> Dealer |
| ||
| Just because OO offers the "Is A" relationship doesn't mean that you have to use it. There's really no one answer to this question. Also, as you've not mentioned the nature of the card game, we can't really offer precise feedback. If a player can't deal then clearly they shouldn't extend Dealer. If a Dealer can play then maybe they could extend Player. Equally, you could just have an abstract concept of a GameParticipant as c.k. mentions but not inherit from it at all, rather provide it with a behavioural Role. It all depends on the nature of the game, and your needs in terms of flexibility/extensibility. |
| ||
| A dealer plays every hand in that the players try to beat the dealers hand. And most of the time the dealer does not bet on their hand. However, there's two conditions where the dealer can bet. Now the players bet every hand and they can make bonus bets which the dealer cannot. So the dealer cannot extend player. At the moment, I don't have a reason to use GameParticipant but I will change the name from Person to GamePerson. If this was a project where other developers were working on the code, GamePerson is less confusing than Person. Another developer might wonder why Person has attributes like... -bankroll:float -bet:int -bonus:boolean -bonusbet:int |
| ||
| My usual instinct would be to have a single player class which would act differently depending on whether it is dealing that particular game (in whuch case it is forced to follow special rules). But that would follow my general approach to card or board games in which any player can in principle be a human or an AI. If the dealer is always the computer, you have not much reason to make them the same as they may not have much in common except a bankroll and one or two functions. You might even consider making the dealer a function of the class that controls the game (and deals?) and arbitrates the legality of moves. There is never any perfect OO design - if you can't choose between two they are probably either both okay, or both too detailed. I find all that "is a - has a" stuff to be a bit too abstract as a criterion. I prefer to think about what will keep my data coherent and encapsulated, and put groups of related functions in one place. |
| ||
| I would make a human class to hold all the human at tribe I would then make a player and dealer class which would extend human. A human can the. Be a player or a dealer seems like a simple solution. Hope this helps. |
   |