Re: semantics of init
Re: semantics of init
- Subject: Re: semantics of init
- From: Marcel Weiher <email@hidden>
- Date: Thu, 5 Jun 2003 17:40:09 +0200
On Thursday, June 5, 2003, at 11:04 Uhr, Hannes Friederich wrote:
While I do perfectly understand the reasons to use accessors in -init,
there
may be some very situations where this is inappropriate.
Of course! I don't think anyone said "thou shalt always use accessors
everywhere". However, these situations are probably much less frequent
than you would expect (just like eXtremos like to point out that
comments are needed far less than most people think...)
One case may be immutable objects. In that case, the variables will be
set
in the designated initializer. So why make a big effort and write
setters
when they will be used only once?
For the same reason as in other cases: future-proofing the class.
Furthermore, accessors are effectively no effort to write if you use
accessor macros ( idAccessor( var, setVar ) is all that's needed to
create the appropriate accessor).
Another situation would be when the setting of a variable is connected
with
some other action, as for example a notification being sent. Of
course, one
can in that case write a public and a private setter with the private
setter
setting the variable and the public setter calling the private setter
and
posting the notification (This is more a design problem)
That is exactly what one *should* do.
idAccessor( var, _setVar )
-(void)setVar:newVar
{
[self _setVar:newVar];
[self sendNotificationThatVarChanged];
}
And if it is a common pattern, I would create a new macro
idAccessor( var, setVar, notificationName / center? )
So far, I haven't encountered that one all that often, but one I really
should have written a Macro for long ago is the old 'lazy initialized
getter'
lazyIdAccessor( var, setVar, expressionToInitializeVar )
[Note: since I haven't written it yet, it probably has to look
different...]
The third situation are objects where the internal state does not
correspond
with the publicly provided accessors.
Accessor != public accessor. You should still provide a private
accessor and use that.
Just imagine the black box scenario
provided in may oo-tutorials and books.
May I suggest that the examples provided in books are often not exactly
relevant to real world coding practice?
I for example had written a class
which uses two NSMutableArrays to store some of the data and wrote an
interface for accessing the data within these two arrays. The arrays
itself
never reach outside the object, so why should I write accessors when
the two
variables only are set during init and accessed from withing the
objects
functions?
Why not?
Such "opaque" objects, where the internal state does not exactly
correspond with the public interface are harder to maintain anyway.
Why?
But as
long as the writer of the objects makes this one working perfectly
seen from
the outside, everything is ok
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
f0249ab8b1af193ef5addcf39fdff5ca
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.