Where should the game multipliers be located? These methods should be public
and only dependent on a list of cards and a rule set. There shouldn't be a
dependency on a complete SkatGame.
They could be moved either to CardList:
getJackMultiplier()
--> from SuitGrandRules
getBaseMultiplier(AbstractSkatRules rules)
--> from various dependents of AbstractSkatRules
Or they could still be part of the AbstractSkatRules subclasses, but then with
a different signature and (possibly?) as part of the BasicSkatRules interface:
Sure we can reduce the methods for finding multipliers to a card list. The
card list must contain the declarers hand and the skat cards to calculate the
multipliers correctly.
I've read the international skat order again on the weekend and found out that
there is a destinction between multipliers and win levels (see chapter 5 for
details).
I would get rid of getJackMultiplier() and getBaseMultiplier() and rather have
two methods getMultiplier(CardList) and getWinLevels(SkatGameData) for each
game type. GetWinLevels() can be implemented in AbstractSkatRules because it's
always the same. GetMultiplier() must be implemented in each rule class.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmmmm. The new method signatures seem to solve my problem concerning the ai
player. In addition, it seems to be clearer about the source of the points. In
theory, ai players might want to bid in such a high range. For practical
puposes, your suggestion should be sufficient.
I'll take a look if I can do it this way without to many changes in dependent
classes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Where should the game multipliers be located? These methods should be public
and only dependent on a list of cards and a rule set. There shouldn't be a
dependency on a complete SkatGame.
They could be moved either to CardList:
--> from SuitGrandRules
--> from various dependents of AbstractSkatRules
Or they could still be part of the AbstractSkatRules subclasses, but then with
a different signature and (possibly?) as part of the BasicSkatRules interface:
--> from various dependents of AbstractSkatRules
Ramsch or null games would return 0 as their multiplier.
Sure we can reduce the methods for finding multipliers to a card list. The
card list must contain the declarers hand and the skat cards to calculate the
multipliers correctly.
I've read the international skat order again on the weekend and found out that
there is a destinction between multipliers and win levels (see chapter 5 for
details).
I would get rid of getJackMultiplier() and getBaseMultiplier() and rather have
two methods getMultiplier(CardList) and getWinLevels(SkatGameData) for each
game type. GetWinLevels() can be implemented in AbstractSkatRules because it's
always the same. GetMultiplier() must be implemented in each rule class.
Hmmmm. The new method signatures seem to solve my problem concerning the ai
player. In addition, it seems to be clearer about the source of the points. In
theory, ai players might want to bid in such a high range. For practical
puposes, your suggestion should be sufficient.
I'll take a look if I can do it this way without to many changes in dependent
classes.