objective-c "generic" type for #property for use with multiple subclasses - objective-c

Question

i'm not sure of the most eloquent way to state this but i will give it my best. i have created a custom class that is a generic object with some properties. i have created a couple subclasses to extend that and make them more specific than the superclass. so for the sake of example i will throw out some generic example code that may or may not be proper syntax only to illustrate what i would like to accomplish.
#interface Vehicle : NSObject
#property (nonatomic) int wheels;
- (id)initWithNumberOfWheels:(int)wheels;
#end
from there i create some subclasses for same "car" & "truck" which give more detail to the class.
#interface Car : Vehicle
#property (nonatomic) BOOL convertible;
#property etc...
#end
and...
#interface Truck : Vehicle
#property (nonatomic) BOOL is4x4;
#property (nonatomic) int numberOfDoors;
#end
so here is where it gets interesting. i want to create another class that allocates those objects but i want the "type" of vehicle to be determined in the init method but use the same #property variable. so for example (and again, this is all garbage code just to give a visual representation)
Road.h
#import "Car.h"
#import "Truck.h"
#interface Road : NSObject
#property (strong, nonatomic) NotSureWhatToUseHereToMakeThisWork *myRide;
// doesn't work: #property (strong, nonatomic) id myRide;
// doesn't work: #property (strong, nonatomic) Vehicle *myRide;
- (id)initWithCars;
- (id)initWithTrucks;
#end
Road.m
#implementation Road
- (id)initWithCars
{
//standard init code...
myRide = [[Car alloc] initWithNumberOfWheels:4];
myRide.convertable = NO;
}
- (id)initWithTrucks
{
//standard init code...
myRide = [[Truck alloc] initWithNumberOfWheels:6];
//yes, some trucks have more than 4 wheels
myRide.is4x4 = YES;
}
#end
the bottom line is if i use the superclass in the #property it doesn't get the subclass properties obviously. basically i want to keep all this as generic and reusable as possible. it doesn't make since to make a special "road" class just for cars & one for trucks. a road is a road after all. is there anyway to do what i am after? is there a better way to do something like this? the primary purpose is to have objects that inherit specific properties for specific situations only. the reason i don't want to make extra #properties is i don't want those visible if they aren't applicable to the situation.
edit:
i added a couple extra snippets to show what i tried before even posting this question that didn't work.
answer: the correct "answer" if anyone is curious is located in CRD's response in the "Addendum". the reason this works is the type "id" can only call methods and does not inherit properties. so rather the workaround (i say it that way, as i was researching this, came to the conclusion this is not good programming and should probably be avoid if possible) would be to use the accessor methods to get/set the property.
id mySomethingObject = [[SomeClass alloc] init...];
[mySomethingObject setPropertyMethod]...; //sets value
[mySomethingObject propertyMethod]...; //gets value
rather than trying to use...
mySomethingObject.property = ; //set
mySomethingObject.property; //get
as stated in the correct answer, if your class you allocated "id" to does not respond to that method your program will crash.

Answer 1

You appear to be confusing a number of issues.
First there is the type of an instance vs. the type of variables which hold references to instances. When an object is created is it of some specific type and that types does not change[*]. Variables also have a type, and that does not change either. Subtyping/inheritance allows you to store a reference to an object of some type, T, in a variable of some other type, S, provided S is a supertype of T.
Second there is static vs. dynamic typing. While Objective-C uses dynamic typing, where the actual type of objects used in some operation is determined at run time, the compiler itself uses static typing, where types are determined during compilation, to aid in writing correct programs. Sometimes the compilers static checking will just produce warnings, but in other cases the compiler will refuse to compile something. In particular property references are compiled based on static typing.
In your example this means you cannot directly reference a property of Car on an object referenced by a variable of type Vehicle *, even if you know the referenced object is a Car - as at compile time all that is known is that is it a Vehicle.
The solution is to first test the actual type of the referenced object and then introduce a local variable of the more precise type, or use a lot of casts. For example:
// (a) create an object of type Car (for a Reliant Robin ;-))
// (b) create a variable of type Car and store in it a reference to the created Car
Car *myCar = [[Car alloc] initWithNumberOfWheels:3];
// Create a variable of type Vehicle and store in it the reference stored in myCar
// The created instance is *still* a Car
Vehicle *myRide = myCar;
// See if myRide is a Car and then do something
if ([myRide isKindOfClass:Car.class])
{
// create a variable of type Car to avoid having to continually cast myRide
Car *myCarRide = (Car *)myRide; // due to if above we know this cast is valid
if (myCarRide.isConvertible) ...
To do this without the intermediate variable you use a cast:
...
// See if myRide is a Car and then do something
if ([myRide isKindOfClass:Car.class])
{
if (((Car *)myCarRide).isConvertible) ...
Which shows why the intermediate variable approach is better!
As a final example, you write your initWithTrucks method like this:
- (id)initWithTrucks
{
//standard init code...
Truck *myTruck = [[Truck alloc] initWithNumberOfWheels:6];
//yes, some trucks have more than 4 wheels
myTruck.is4x4 = YES;
// Store the reference to the created Truck in myRide
myRide = myTruck;
}
HTH
Addendum
From your comments it seems you may be looking for dynamic typing and do not wish to the compiler to perform any static typing. This is (partially) supported, but not using the dot notation for properties - you must use the getter and setter methods directly.
First, in Road you declare myRide to be type id:
#interface Road : NSObject
#property id myRide;
The id type means two things (a) any object reference and (b) do not statically check a method exists on the object. However the compiler must know that a called method exists on some object, and it will still perform static type checks on the arguments to the method - so its not complete dynamic typing (however you could pass id typed expressions or declare your methods to take arguments of type id of course...).
Second you make all references to properties use the getter or setter methods directly and do not use the dot notation (for non-property methods you just call them as usual). E.g.:
- (id)initWithTrucks
{
//standard init code...
myRide = [[Truck alloc] initWithNumberOfWheels:6];
//yes, some trucks have more than 4 wheels
[myRide setIs4x4:YES];
}
If you make a call such as [myRide setIs4x4:YES] and myRide is referencing a Car object then you will get a runtime error.
The general recommendation is to stick as much as possible with the compiler's static typechecking.
[*] We will ignore any runtime magic, there be dragons. In normal code objects never change type.

Answer 2

You have to use the type "Vehicle" and then cast your object with "Truck" or "Car" to get the specific properties

Answer 3

the most generic architecture would be to create a VehicleProtocol, that any class could implement. you still could have a Vehicle class that implements the protocol and subclass from it (similar to NSObject implementing the NSObject protocol), or let independent classes implement it. the road would have a property #property (strong) id<VehicleProtocol> myRide.
A complete example of the later architecture: no vehicle super class, but all a VehicleProtocol
#import <Foundation/Foundation.h>
#protocol VehicleProtocol <NSObject>
#property (nonatomic) NSUInteger wheels;
#end
#interface Car : NSObject <VehicleProtocol>
#property (nonatomic) BOOL convertible;
#property (nonatomic) NSUInteger wheels;
-(id)initWithNumberOfWheels:(NSUInteger) numberOfWheels;
#end
#implementation Car
-(id)initWithNumberOfWheels:(NSUInteger) numberOfWheels
{
if (self = [super init]) {
_wheels = numberOfWheels;
}
return self;
}
#end
#interface Truck : NSObject <VehicleProtocol>
#property (nonatomic) BOOL is4x4;
#property (nonatomic) int numberOfDoors;
#property (nonatomic) NSUInteger wheels;
-(id)initWithNumberOfWheels:(NSUInteger) numberOfWheels;
#end
#implementation Truck
-(id)initWithNumberOfWheels:(NSUInteger) numberOfWheels
{
if (self = [super init]) {
_wheels = numberOfWheels;
}
return self;
}
#end
#interface Road : NSObject
#property (strong) id<VehicleProtocol> myRide;
#end
#implementation Road
#end
int main(int argc, const char * argv[])
{
#autoreleasepool {
NSArray *vehicles = #[[[Car alloc] initWithNumberOfWheels:4], [[Car alloc] initWithNumberOfWheels:3], [[Truck alloc] initWithNumberOfWheels:10]] ;
for (id v in vehicles) {
if ([v isKindOfClass:[Truck class]]) {
[v setIs4x4:YES];
}
}
Road *road = [[Road alloc] init];
road.myRide = vehicles[0];
NSLog(#"%#", road.myRide);
road.myRide = vehicles[2];
NSLog(#"%#", road.myRide);
NSObject *obj = [[NSObject alloc] init];
road.myRide = obj; // warning in this line
NSLog(#"%#", road.myRide);
}
return 0;
}
Sure it might have more lines of codes than with "classical subclassing", but there are less dependencies. Instead the classes agree on a contract to fulfill. Here the contract only requires the objects to have any number of wheels.
Note that I create a Road and assign first a car and than a truck (I also show how to identify cars and trucks via -isKindOfClass:), both works without any warning or error, as Car and Truck completely fulfill the contract. Than I assign a plain NSObject. Here the compiler warns, as he recognizes that NSObject does not implement the protocol. Though it is not an compiler error, as the compiler does not know, if you will use any protocol specific method on that object.
In case of a plain NSObject assigned to myRide, this line
NSLog(#"%# %ld", road.myRide, (unsigned long)road.myRide.wheels);
will lead to a runtime crash (as an NSObject instance does not respond to wheel) — but at compile time it will not even trigger a warning.

Answer 4

Storing a Car in a variable of type Vehicle * does not remove the object's Car properties — the Car will still be able to access all of its state normally — it just means that you can't access the properties through that variable.
But that's the basic idea here, isn't it? You want this class to be able to handle all Vehicles, and that's what it's doing — it's only showing you the functionality available to all Vehicles. So you can have the interface necessary for interaction with a generic Vehicle in the Vehicle class, and implement the methods in your subclasses to do the class-appropriate behavior when called, and everything will work.
If the issue is specifically creating new instances of a specific class that you want to treat generically from that point on, you can use a statically typed local variable and assign to the generically typed variable once it's set up.
For example, let's say we have a game where there are human players and AI players, and the human player can give himself an advantage by making AI players take more damage. We could do this:
#interface Combatant : NSObject
#property(nonatomic, strong) NSString *name;
#property(nonatomic) int hitPoints;
- (void)takeDamage:(int)damageAmount;
#end
#implementation Combatant
- (void)takeDamage:(int)damageAmount {
self.hitPoints -= damageAmount;
}
#end
#interface HumanCombatant : Combatant
#property(nonatomic, strong) UserID *userID;
- (id)initWithUserID:(UserID *)theID;
#end
#implementation HumanCombatant
- (id)initWithUserID:(UserID *)theID {
if ((self = [super init])) {
_userID = [theID retain];
}
}
- (void)takeDamage:(int)damageAmount {
[super takeDamage: damageAmount];
NSLog(#"Human took %d damage, has %d health remaining", damageAmount, self.hitPoints);
}
#end
#interface AICombatant : Combatant
#property(nonatomic) double damageMultiplier;
#end
#implementation AICombatant
- (void)takeDamage:(int)damageAmount {
int modifiedDamage = damageAmount * self.damageMultiplier;
[super takeDamage: modifiedDamage];
NSLog("AI took %d damage, has %d health remaining", modifiedDamage, self.hitPoints);
}
#end
Then, in most of our game code, we can use a variable typed as a Combatant *, and when you send it takeDamage:, it will do the right thing for the type of combatant it is. Our external code that calls the object a Combatant * will not be able to directly access an AICombatant's damageMultiplier property, because the other code doesn't know whether the Combatant is an AICombatant, but the object will still have that property and will behave correctly for its class.

Answer 5

Make it a Vehicle* and make each class implement type to return a constant indicating that class's type.
#property (nonatomic, strong) Vehicle* yourRide;
...
if (yourRide.type == VehicleConstant_Truck) {
Truck* yourTruck = (Truck*) yourRide;
NSLog(#"This truck %s a 4x4", yourTruck.is4x4 ? "is" : "isn't");
}
To make #vikingosegundo happy, an alternative approach is to do:
if ([yourRide isKindOfClass:[Truck class]]) {
instead of the if statement above.