既然有two-card-game,作业里也有拓展要求three-card-game，why don't we just implement A N-card-game？原文问题摘抄如下：
Just wondering what everyones thoughts are on the best way to implement both a 2 and 3 card game from an OO perspective.
The obvious approach might be to create a CardMatchingGame superclass (e.g. turn the existing CardMatchingGame class into an abstract class), and two concrete subclasses TwoCardMatchingGame and ThreeCardMatchingGame that override the flipCardAtIndex method to do the "right" thing in each case.
Alternatively it would be easy to have a property in the CardMatchingGame class which stores the game type, and then case the logic in flipCardAtIndex according to this property.
As another alternative would be to write the function flipCardAtIndex in a more generic fashion which works for an n-card flipping game (and perhaps do the same in the PlayingCard match function).
Great questions. A lot of this really boils down to your specific style and the specific needs of your program, because I don't think there's really a prescribed answer here - each of the options you proposed embody certain trade offs, and this type of OOP design can really boil down to an art more than an exact science.
Personally, in this type of situation I'm a fan of making abstract classes, because it separates the code and its easy to layer on features without worrying about breaking old code that works. On the other hand, making one class that supports multiple game types and writing methods generically without hard coding assumptions about the game are also great tactics, and its really just a matter of style.
Keep in mind though, if you make things too generic it can be easy to over complicate things quickly and end up with a lot of extra code that you really didn't need. Try to strike a balance between getting things working and anticipating how you might want to expand the functionality of your program later.
cardButton setImage:(card.isFaceUp ? nil : cardBackImage) forState:UIControlStateNormal];
So . I forget the nil pictures and faceup things.
Because, I thought like this: If the state is Normal , just show the backImage. How the faceup effect on it? Maybe I still don't understand what the UIControlStateNormal mean ?
could you tell me more about it?
The normal, or default state of a control—that is, enabled but neither selected nor highlighted.
The button will be in the normal state both when the card is face up but also if the card is face down.
The only time the button is in selected and/or highlighted is when we tap on the button and the card is being 'flipped over'.
I only set the backImage for the normal state.
and I didn't set any other images for the other states.
Why when I selected the button. The button is not in the NormalState , but still show me the backImage ?
Great question, and the answer is given here
In general, if a property is not specified for a state, the default is to use the UIControlStateNormal value. If the UIControlStateNormal value is not set, then the property defaults to a system value. Therefore, at a minimum, you should set the value for the normal state.