Setting properties to objects in NSMutableArray [closed] - objective-c

Question

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
Ok - can't quite make sense of what's going on here. I'm building a simple card game. I created a Category of UIView that handles all the stuff a "Card" should be. I figure this is irrelevant, but perhaps it's not.
Anyway, in my view controller, I'm just creating 2 NSMutableArrays to hold the dealer and players hands. Then I'm calling a method to set the card value. In that method, I do an NSLog to see the particular card object's value - and it all looks good. But if I try to get that value from my view controller, it always comes back for ALL the objects with the value of the last object in the array.
some code:
playersCards = [[NSMutableArray alloc] initWithObjects:[[UIView alloc] init],[[UIView alloc] init],nil];
[[playersCards objectAtIndex:0] setCardValue];
[[playersCards objectAtIndex:1] setCardValue];
NSLog(#"1: %i",[[playersCards objectAtIndex:0] returnValue]);
NSLog(#"2: %i",[[playersCards objectAtIndex:1] returnValue]);
So when I get the NSLog after calling setCardValue (this is within the Category) - again, all is fine. But those NSLogs right there - they return the value of index 1 for both. What's happening here?

Answer 1

There is no way that the setCardValue method can know what index the Card is at unless you are doing something convoluted. Therefore, it is likely that you do have two cards, but they are identically initialized.
However, there is a bigger problem here. You really don't want to use UIView instances as data like this. You really want to separate the bits that render stuff on screen [View] from the bits that hold the state of the game [model]. Typically there is a layer in between that manages the model state based on user interaction with the view [controller].
See the documentation on Model-View-Controller for more information.
Hanging stuff off of existing classes with categories may seem convenient, but it really shouldn't be used as the primary pattern for encapsulating data, state, and/or logic in your application.
You really want to keep that data [the game state] isolated from how the data is drawn on the screen [the views].
In terms of your specific question in your comment, another question:
Imagine that your code was written like this:
Card *c = [cardArray objectAtIndex: 0];
[c doSomething];
How would c know what index it is at in that code? Now, note that said code is identical to [[cardArray objectAtIndex:0] doSomething];.
If I were designing some kind of a Card game, I would likely create a handful of classes:
a Card class that simply stores a suit and value. Supports NSCoding for archival purposes.
a CardView subclass of UIView which, given a suit and value, knows how to render a card.
a GameFieldView and GameFieldController set of classes that know how to draw the playfield (former, UIView subclass) and how to move CardViews about the playfield (latter, a UIViewController)
specific subclasses of GameFieldController that add logic for things like hands, stacks, piles, and/or whatever else you might need to create a card game.
.... etc ....
That is, I'd break the game down into a series of classes that fit into the iOS or OS X model view controller patterns such that I'm writing a minimal amount of code and letting the system do the heavy lifting it is designed to do.
This may seem like overkill, what with all those classes and all, but, really, the individual classes are relatively simple and quite flexible.