Usage of accessor methods (was: Accessor methods and (auto)release: conclusion)
Usage of accessor methods (was: Accessor methods and (auto)release: conclusion)
- Subject: Usage of accessor methods (was: Accessor methods and (auto)release: conclusion)
- From: Ondra Cada <email@hidden>
- Date: Tue, 6 Aug 2002 20:12:13 +0200
On Tuesday, August 6, 2002, at 07:51 , Marcel Weiher wrote:
Sure, but using set-accessors is not a generally good pattern for doing
this. For this to be acceptable, you have to know that the accessor will
not have other side effects, which isn't a safe assumption to make. Of
course, you can have a coding style that makes sure of that, but that
doesn't make it a generally acceptable pattern.
Well, it seems we do use different design patterns ;)
My approach is quite simple:
(a) I know that the setter is the most correct way how to change an ivar's
contents. So, I write it that way (and, if there are some special
conditions, I comment on them in header);
(b) from this moment on, I forget how exactly I've written the thing (that
is what I call encapsulation)...
(c) ... and just use it whenever I want to change the ivar.
The (c) applies for internal usage as well. Like as if I want to set the
ivar for some unarchived thing (I believe Kirk Kerekes happened to solve
this mystery in the list a short time ago too), or -- and that's what we
are speaking about -- I want to set it to nil somewhere. Like in dealloc!
Now, I really do believe this pattern is "the right one" (means, most
robust and least error-prone of all alternatives known to me), and that it
should be taught to newbies (after all, experienced programmers would
create their own patterns).
I do agree that there are cases when internal usage of setter is
superfluous -- after all, ivar is accessible internally, so what?
Neverhteless, I do think that setters *should* be used *anywhere*, and
replaced by direct ivar usage only if it proves to be a real bottleneck.
---
Ondra Hada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
_______________________________________________
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.