Re: Newbie question: how to release an object that has been autoreleased
Re: Newbie question: how to release an object that has been autoreleased
- Subject: Re: Newbie question: how to release an object that has been autoreleased
- From: James Bucanek <email@hidden>
- Date: Wed, 22 Sep 2004 17:03:28 -0700
Glenn Andreas wrote on Wednesday, September 22, 2004:
>At 12:43 PM -0700 9/22/04, James Bucanek wrote:
>>Glenn Andreas wrote on Wednesday, September 22, 2004:
>>>This isn't all that different than the way a class cluster is
>>>designed, and works because "init" can return something other than
>>>"self". Thus there isn't a need to have a factory method to decide
>>>what to do - this logic can be pushed into the init method itself.
>>
>><clip>
>>
>>>By doing this, you avoid the "newBufferNotAutoreleased" method - if
>>>you don't want to create an autoreleased object, [[Buffer alloc]
>>>init] will work just fine.
>>
>>Except for the one important detail which I pointed out in my
>>earlier post: All of the details which Buffer would need to
>>initialize itself are @private or @protected instance variables in
>>BufferPool.
>>
>>Having the BufferPool produce Buffer objects was a matter of
>>encapsulation. For Buffer to initialize itself will require me to
>>expose all (or at least some) of the private data of BufferPool to
>>the world. At the very least, I'd have to pass BufferPool to Buffer
>>([[Buffer alloc] initWithPool:pool]).
>
>In general, I avoid any class that can't have objects created by
>[[Foo alloc] init...] (or perhaps a convience function [Foo
>fooWith...]) - after all, this is still going to be possible (and the
>compiler isn't going to warn you if you or somebody else later on
>accidentally does this), but the results will probably be something
>very inconsistent. It also just seems wrong to have to ask a
>different object/class to create it. I'd expect all the logic about
>how and when and what subclass of Buffer to belong to the Buffer
>class (though it may well ask an instance of BufferPool questions to
>help determine what kind of buffer to alloc)
In general, I agree with you. I don't like "high maintenance" objects that require lots of special steps to create and destroy. I want to create an object, use it, and throw it away. The object should take care of whatever details are required to behave itself.
However, what I'm doing here isn't particularly foreign. It's essentially the iterator pattern. You never create iterators directly; You always ask a collection to create an iterator for you. Only the collection knows what kind of iterator to create and how to initialize it.
>You could still hide away all this with something like:
>
>@implementation Buffer
<snippage of much good code>
>@end
You could design iterators that way too ([[Iterator alloc] initWithCollection:bag]) and have the Iterator throw itself away then delegate the correct construction to the collection. But you hardly ever see this in practice.
Like iterators, my Buffer objects are just lightweight "views" into the buffer pool. I don't seen anything unnatural about asking a BufferPool to please give me an accessor object that grants access to some portion of the pool.
I don't think there's a right or wrong (or even a "much better") here. Mostly it's a matter of style and what paradigms we're comfortable with.
--
James Bucanek <mailto:email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden