Reusing NSObjects by Overriding release in Obj-C

I am implementing an object reuse scheme using a singleton class.

What I do basically is:

MyClass* obj = [[MyClassBank sharedBank] getReusableItem];

The bank is just an NSMutableSet tweaked for optimum reusability. When I was happily implementing this Singleton, I had in mind that I will just do the following when I am done with "obj":

[[MyClassBank sharedBank] doneWithItem:obj];

Currently, My code would work if I where to use it this way, but I later realized that I sometimes add "obj" to an "NSCollection", and sometimes I call:

[theCollection removeAllObjects];

At first I thought about making my own class that is composed of a collection, then I would iterate the objects within the collection and call:

[[MyClassBank sharedBank] doneWithItem:obj];

But, that's too much of a hassle, isn't?

A neat idea (I think) popped into my mind, which is to override: -(oneway void)release;, so, I immediately jumpe开发者_JAVA百科d to Apple's documentation, but got stuck with the following:

You would only implement this method to define your own reference-counting scheme. Such implementations should not invoke the inherited method; that is, they should not include a release message to super.

Ao, I was reluctant to do that idea .. basically:

-(oneway void)release{
    if ([self retainCount] == 1) {
        //This will increment retain count by adding self to the collection.
        [[MyClassBank sharedBank] doneWithItem:self];
    }
    [super release];
}

Is it safe to do that?

PS: Sorry for the long post, I want the whole idea to be clear..

EDIT:

How about overriding alloc alltogther and adding [[MyClassBank sharedBank] getReusableItem]; there?

Suggested method:

You're playing with the reference counting system. 99.9999999999999999% of the time this is a bad idea. I would highly recommend going with a different mechanism. Perhaps these objects could implement their own reference count that's independent of the retainCount? Then you could use that referenceCount to actually control when an object is ready to be re-used or not.

Not suggested method:

If, for some weird reason, you can't do that, then you could do the following thing that is still a bad idea and that i don't recommend you actually use:

You can override dealloc:

- (void)dealloc {
  [ivar release], ivar = nil;
  [anotherIvar release], anotherIvar = nil;
  somePrimitive = 0;
  // do not call [super dealloc]
}

- (void)_reallyDealloc {
  [self dealloc];  // clean up any ivars declared at this level
  [super dealloc]; // then continue on up the chain
}

Basically, the dealloc method would be the point at which the object is ready for re-use. When you're totally done with the object and finally want it to go away, you can use the _reallyDealloc method to continue on up the chain, eventually resulting in the object getting freed.

PLEASE don't do this. With things like Automatic Reference Counting, this is going to introduce you into a world of hurt and really bizarre debugging scenarios. A lot of the tools and classes and stuff depend on the reference counting mechanism to be working without alteration, so screwing around with it is usually not a Good Idea™.

For ppl who find this approach interesting/useful, Here is a cleaner way than calling [super dealloc]; directly (which is definitely bad)

//BAD!
//-(void)dealloc{
//  for some reason, the retainCount at this point == 1
//  if (![[BankStep sharedBank] purgeFlag]) {
//      [self resetObject];
//      [[BankStep sharedBank] doneWithItem:self];
//  } else {
//      [children release];
//      [super dealloc];
//  }
//}

by calling [[Bank sharedBank] purgeBank]; , set the flag to true, then remove all objects from the NSSet.

Adapted solution:

@Joe Osborn idea of using categories to implement a returnToBank Method!