At 11:02 PM +0200 29/7/08, Torsten Curdt wrote:
Especially for a framework I don't want to expose implementation
details to the interface.
Others have pointed out that you cannot add ivars in the implementation.
However, if you can control the creation of your objects via a
factory function or other means, then you can have a private subclass
that has ivars and never actually create the published class per se.
For example (typed in email)
.h file:
@interface MyClass
-(void) publicMethod;
+(MyClass*) allocate;
@end
.m file
@interface MyRealClass : MyClass
{
int privateVariable;
}
-(void) privateMethod;
@end
@implementation MyClass
-(void) publicMethod { }
+(MyClass*) allocate
{
return [MyRealClass alloc];
}
@end
@implementation MyRealClass
-(void) privateMethod { }
@end
I've used this technique a fair amount in C++, but, being a novice,
not much yet in Objective C, but it should work. I'm not sure
whether it would be a good idea to for the method named allocate to
be named alloc or not. Possibly that would mean it would work even
if you couldn't control the creation of the class, I'm not sure.
One downside is that Interface Builder does not seem to read .m files
(even if you actively drag them to it), so you can't have any
IBOutlets in MyRealClass unless you put it in a (potentially private)
header file.
Hopefully this makes as much sense in Objective C as it does in C++,
otherwise I'm sure someone will correct me.
Enjoy,
Peter.
--
Keyboard Maestro 3 Now Available!
Now With Status Menu triggers!
Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your Mac
<http://www.stairways.com/> <http://download.stairways.com/>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
