User:Douglas Wall
My actual Project, I think.
Before I made my design project decision, I considered the cards problem.See below.
Cards as a minor design study (project warm-up)
Someone asked me this question after they were asked it in a job interview: "Can you draw a UML diagram for a deck of cards including the Jokers". Sounds simple right? Well after my mind imploded while trying to deal with the Joker (no pun intended), which complicates everything, I have resolved to try and crack that nut in an OO manner. I have a loose context for the design, that being that it must be reasonably extendible/reusable and easily maintained. It should feature no game specific behaviour, and I will probably ignore graphic representation entirely.
Disclaimer: I make no claim to know what I am doing. Most diagrams will be missing details. Some may even cause dysentery.
The essence of a deck of cards:
Naturally, the solution could be as simple, yet horrific as this: 
To start with I have constructed an inheritance monster:
Problems/Observations:
- What does the abstract class Card actually contribute to its subclasses? If I ignore physical details (dimensions, materials etc) and visual items (symbols, images, colour) then there appears to be nothing else significant that it can have. The same thing applies to the Joker. The Joker card itself has no specific methods or fields that I can depict, a joker is simply a particular card with no suit or value. This problem also affects most of the other objects.
- There seems to be a need for a Strategy pattern in here, around ValueCard and its subclasses and possibly including the joker in some rework of the structure.
- It is seems huge and unnecessarily complex for something that should be simple. See above.
- Perhaps an approach from the point of view of suits would be better.
Hmmmmm... An interesting problem... I have some questions. Face cards may or may not have a value given their usage, can this be taken into account? Certain games require that Jokers be given an in game value or that they act like a wild card holding some suit/value. Does a suit need a subclass? Could you just use a enum? If I was going to subclass it, I would want to also take into account that two suits are red, two black. Why, in the first design, are the cards a set and in the second a list? Should they be either if their usage isn't know? why not just a collection... Looks good :) --Matthew Harward 04:04, 4 August 2009 (UTC)
- Regrading the face cards and their value, that is a game semantic/attribute and while you are correct, in certain context that would have to be taken into account, I am aiming (roughly) for a 'generic' deck of conventional cards. For the most part it would feature minimal behaviour. Yes, you're correct, I could just use an enum for the suit and also for the Ace, King, Queen, Jack and probably the Joker too. I have a design with enums, which I shall put up soon. The red/black issue is again, game behaviour, but a valid point. The choice of Set in the first (and I stress non-OO) design is incorrect as I think the Jokers are not unique cards (though they are unique instances), hence I changed to a List, but yes it could just be a generic collection. Now I think about it, the 2 Jokers (actual instances of) would have to have be unique in some way, so that when (for example) acting as wild cards they can independently represent different cards. Hmmm. Thanks for commenting Matthew. --Douglas 23:55, 4 August 2009 (UTC)
- This behaviour vs modelling the real world thing is something we should possibly all look at in greater detail :) --Matthew Harward 01:17, 5 August 2009 (UTC)
For this next design I stripped away all the classes of the previous design that did not seem to contribute anything useful and those that could be replaced by enumeration:
Problems/Observations:
- Enumeration, while compact, doesn't really allow extensibility beyond just a simple field, but this could be a context related trade-off. For my 'generic pack of standard cards' I think it is ok for the time being. If I needed to add a specialist suit, or if I wanted to start storing specific graphical information for a suit within a suit, then probably many things would need to be re-factored.
- I am not sure about removing the identity of the face cards and Ace, but as Wal pointed out, what defines a face card or ace is (in my current interpretation) its numeric value. Still, I can't help but feel this means that other classes using the cards would then have to know more about face cards etc than seems necessary. For example, rather than just identifying a card as an Ace by its class, the client object needs to know how to identify an Ace from its value. That sort of info could also be enumerated though.
It seems I misinterpreted what Wal suggested about the identity of face cards being removed. I removed them completely, however Wal pointed out that face cards don't have a numeric value themselves, I had only been assuming they do. So they will need to come back in an enumerated form. Also slated to return is the Ace and a new addition (suggested by Wal) is some form of wild-card class. At this stage I suspect I will use an abstract definition and somehow connect an adapter to the concrete instance cards so any cards can be wild-cards/special-cards. --Douglas 03:16, 21 September 2009 (UTC)
Naturally this doesn't seem at all right with lazy classes. Wal suggested that classes such as the Joker, even though it is lazy should exist, along the lines of reality trumping design theory. I am still not sure. I have tried to apply patterns to this problem, Decorator and Strategy, to try and modify the problem by adding the behaviour in at different place. It didn't work, I just end up with the same problem of the Ace and Joker not having any behaviour until they are attached to a game context. This maybe ok when used in a game, but it makes for questionable design on it's own.
