Re: Q: how do you generate get/set methods?
Re: Q: how do you generate get/set methods?
- Subject: Re: Q: how do you generate get/set methods?
- From: mmalcolm crawford <email@hidden>
- Date: Tue, 20 Jan 2004 19:25:50 -0800
On Jan 20, 2004, at 5:01 PM, Karl Goiser wrote:
Without wanting to act like a wet blanket, I would like to point out
that one of the foundation principles of object oriented programming
is 'encapsulation'. This is the idea that one object should not know
about the internal state of another. This is a well established
design principle and is fundamentally important in writing large, well
behaved applications. For example, a driver of a vehicle is not, and
probably should not be appraised of every piece of information a
modern engine management system gathers.
Personally, I regard the automation of accessor method writing as
counter this principle. Large numbers of accessor methods, to me, are
an indication of poor design and a potential source of problems and
unnecessary complexity. For example, if a method in object A needs to
make many accessor calls to object B, that method may be better placed
in object B - and reduce the need for the accessor methods.
Umm, I think you fundamentally missed the point, and an important use
of accessor methods in Cocoa.
The virtue of accessor methods is precisely that they provide a
suitable API for changing the stage of an object. They do not say
anything about the internal representation of the state. (A good
example here are the new indexed accessor methods which provide a means
of representing some data as an array, even though the underlying
structures may not be an array -- see
<
http://homepage.mac.com/mmalc/CocoaExamples/Weapons2.zip> for one such
case.) What would be Wrong would be if external objects modified an
instance variable directly, or relied on the actual data structure --
*this* is what would be a violation of the principle of encapsulation.
There are many cases when object A needs to change the state in object
B and yet "the method should *not* be part of object A". A trivial
situation is where object A is a controller, and object B is a model
object. If object B is an instance of a Car entity, its 'price' ivar
and corresponding accessor methods certainly belong with the Car class,
and not with the controller that will be responsible for updating its
value.
The other important issue in Cocoa is memory management. Even if
accessor methods are not publicly exposed, they serve a very useful
purpose in facilitating memory management. If you litter your code
with calls to retain and release to ensure longevity of an instance
variable (in contrast to assuring that a locally-used variable does not
disappear), then you are likely to make mistakes. Calling your own
accessor methods to set instance variables significantly reduces the
likelihood of error.
mmalc
(I may as well take this opportunity to re-commend Kevin Callaghan's
Accessorizer application.
<
http://www.kevincallahan.org/software/accessorizer.html>
It covers a wealth of permutations not only for accessor methods, but
also for dealloc, indexed accessors, key-value dependencies, validation
stubs, and archiving. I regard it as a "must-have app" for Cocoa
developers.)
_______________________________________________
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.