Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: mmalcolm crawford <email@hidden>
- Date: Tue, 4 Jan 2005 08:01:29 -0800
On Jan 3, 2005, at 11:14 PM, Izidor Jerebic wrote:
On Jan 3, 2005, at 10:40 PM, mmalcolm crawford wrote:
Then it sounds as if you're violating your own rule by not adhering
to the principle of encapsulation within the existing add: method?
(I.e. you're changing the instance variable value directly rather
than through accessor methods.)
If you want to change the instance variable directly, however, you
are free to do so, provided that you add two, very simple, method
calls before and after the change is made.
What if there is no 'value' instance variable ?
Why do you all insist that implementation must have instance variable
called 'value'? Like there is no other way?
Umm, on many occasions in the past (moreso in WebObjects courses than
here, but...) I have stressed the "equivalence" as far as KVC goes
between instance variables and methods -- KVC doesn't care if there is
a real instance variable or not, provided there's a method. So in
abstract I'm certainly not insisting there is a variable. The reason
for focussing on variables is that, since it seemed that you weren't
calling accessor methods, it seemed reasonable to assume that there was
a variable (mea culpa if this was not the case)...
Lets say that one of the instance variables of the calculator is the
array of objects, denoting operations, and when the value is
requested, it is always calculated on demand from this array.
This is perfectly OK implementation, hiding the complexities from
external world. Why did we choose this implementation? Well, maybe it
is suitable for other operations that we want the calculator the
perform, like getting the trace (for printed trail), whatever...
This example and various arguments clearly shows the problems -
everybody immediately assumed that there must be an instance variable
'value'. This is implementation detail and nobody can assume what the
implementation is, based on the object interface.
And of course I do not use getters/setters with this implementation.
Why would I? Internal implementation objects are not (should not be)
available to the external world, so there should be no getters/setters
for these instance variables.
It's not clear why you would not at least have the equivalent of a
"getter", even though it returns a derived value. This is a standard
Cocoa design pattern.
But then you say, "so there should be no getters/setters for these
instance variables," so it's not now clear to me whether there are
instance variables or not. Really, it doesn't matter. The simple fact
is that, to reiterate, Cocoa has existing patterns for accessing
values.
If, as *seems* to be the case, the derived value is dependent on
another value, so a notification should be sent if the other value
changes, then you can probably arrange for this to happen automatically
using setKeys:triggerChangeNotificationsForDependentKey:.
If I want to make this object KVC/KVO compliant, there is substantial
work to be done. And not because the object is badly designed. I can
change its implementation any time. This means its design is OK.
KVC/KVO is influencing its implementation, not design.
I suspect that for most applications the effort involved in ensuring
KVC/KVO compliance is minimal, and typically involves adhering to
patterns that have been encouraged for some time. Perhaps you could
give a concrete example to show why this is not the case here, as I'm
afraid it's still not completely clear to me? And again, typically it
should be the case that any effort expended in ensuring KVC/KVO
compliance is significantly outweighed by the effort that would be
expended writing the glue code.
mmalc
_______________________________________________
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
| References: | |
| | >Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Tim Lucas <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: mmalcolm crawford <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: mmalcolm crawford <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |