I disagree a bit with @jiminaus' suggestion. I confess however that might misunderstand the direction of what your app is trying to do, but based on what I'm guessing you might be trying to accomplish I would take a somewhat different approach.
I would create a PlayerUnit class (or NPCUnit Class--I'm not quite sure what you're using these fighter objects for exactly). This class would have methods like setLevel:, and setHitPoints:, basically setting all of attributes and behaviors that all of your classes will have in common. Next I would create a Fighter class that would inherit from the PlayerUnit class, as well as a Mage class, a Thief Class (etc.) or whatever other classes you're planning on implementing. All of these classes would inherit from the PlayerUnit Class. The individual Fighter, Mage, etc. classes would each implement the items SPECIFIC to just those classes that make them unique. As an example, your mage class might have a mana bar with a maxMana property and a currentMana property. This wouldn't apply to all classes so it should go in the Mage Class instead of the generic PlayerUnit parent class that all of the other classes would inherit from. The Thief class might have a stealthRating property, and so that would be implemented in the Thief class only.
Here's why this system is good: if for example, you change the way ArmorRating is calculated, you only need to change that method in 1 place (the PlayerUnit Class), because all of the other classes inherit from it. If you were to instead, not have a common Parent class and copy/paste the ArmorRating calculation method into the Fighter class, Mage Class etc. Then you would need to make those changes in several places. When you're duplicating methods in multiple places, then there's a good chance that you can make a mistake somewhere. This is ALWAYS a sign that there's something wrong with the code and is an example of what is commonly referred to as a
Code Smell.
@jiminaus is correct that what you're doing falls into the constructor pattern and belongs in an init method, but I disagree that all of these stats should be set within the Fighter class. I would do something like this:
Code:
@interface PlayerUnit: NSObject
{
// properties that all units would have
NSString *_name;
BOOL _isEvil;
NSInteger _hitPoints;
NSInteger _level;
// etc. you get the idea
}
// This is the designated initializer
-(id) initWithName: (NSString *)theName Evil: (BOOL)isBadGuy hitPoints: (NSInteger)theHitPoints level: (NSInteger)theLevel; //etc. for all of the properties.
Now here's an example of the interface of a Mage class:
Code:
@interface MageClass: PlayerUnit //notice it inherits from the player unit class gaining all of it's ivars and methods so mages can do everything a PlayerUnit can do plus what we're about to add below
{
NSInteger _maxMana;
NSInteger _currentManaLevel;
NSMutableArray *_spellbook;
// notice how these attributes wouldn't make sense in a Fighter Class, or in the parent class. Because they're really only useful to a mage they belong here.
}
// This is an connivence constructor method below
+(MageClass *) mageWithName: (NSString *)theName evil: (BOOL)isBadGuy hitPoints: (NSInteger)theHitPoints level: (NSInteger)theLevel maxMana: (NSInteger)theMaxMana;
In the implementation of my mage class method I would do something like this:
Code:
@implementation MageClass
+(MageClass *) mageWithName: (NSString *)theName evil: (BOOL)isBadGuy hitPoints: (NSInteger)theHitPoints level: (NSInteger)theLevel maxMana: (NSInteger)theMaxMana
{
MageClass *newMage = [[MageClass alloc] initWithName: theName
evil: isBadGuy
hitPoints: theHitPoints
level: theLevel
maxMana: theMaxMana];
[newMage autorelease];
return newMage;
}
-(id) initWithName: (NSString *)theName evil: (BOOL)isBadGuy hitPoints: (NSInteger)theHitPoints level: (NSInteger)theLevel maxMana: (NSInteger)theMaxMana
{
// Calls Super's Designated Initializer--i.e. PlayerUnit's initWithName: evil: hitPoint: method and passes in the appropriate parameters
if((self = [super initWithName: theName
evil: isBadGuy
hitPoints: theHitPoints
level: theLevel]))
{
_maxMana = theMaxMana;
_currentMana = _maxMana; // New characters always start with full mana
//set up other iVars with initial default values.
}
return self;
}
To instantiate a MageClass object, you could either call alloc and our custom init, or use the the Class method constructor here are examples of both:
Code:
// in some code where you want to instantiate your MageClass object:
MageClass *goodMage1 = [[MageClass alloc] initWithName: @"Sloth"
evil: NO
hitPoints: 45
level: 2
maxMana: 120];
// or you can use the convenience constructor which means it saves you from calling the alloc and returns an autoreleased instance.
MageClass *evilMage1 = [MageClass mageWithName: @"Chunk"
evil: YES
hitPoints: 45
level: 4
maxMana: 120];
[evilMage1 retain]; // we might want to retain this because it's autoreleased and will go away if we don't take ownership of it
As far as books are concerned, I would read them in the following order:
1. Kochan - If you haven't mastered the concepts here, then the design patterns book will be much less valuable (because it's a bit tricky in some places).
2.
Clean Code This one is great for understanding why some code is designed/structured better than others. I wish that I had read this book much earlier in my studies than I did. It moves quickly, and you don't have to necessarily get too into the gnity-gritty. It's also available on the iBook store, so you can preview the first chapter or two for free.
3. Cocoa Design Patterns - It's an excellent book, but I think you'll be able to get more from it if you have a very solid understanding of Obj-C and have a general sense of the basic strategies for writing good, simple and clean Object Oriented Code. Once you've got that foundation, this book will click more for you.
To approach it more metaphorically, Kochan is like learning basic english grammar, and Clean Code is like learning how to write good paragraphs and understanding why one sentence is better structured than some other one even if both are grammatically correct. The Design Patterns book would be like learning the common literary techniques for writing some particular genre of writing.
This is just my opinion, so feel free to take it with a grain of salt. Everyone learns differently. I am by no means an expert.
