Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Izidor Jerebic <email@hidden>
- Date: Tue, 4 Jan 2005 08:14:07 +0100
I do not want to drag this further, since it is mostly clear to me now,
but there are some assumptions that prevent understanding of my posts,
and I would like to make them clear...
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? 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.
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.
There, this was it.
Everything is more or lesss clear, now.
Thanks all for your contributions, this discussion really cleared my
thoughts on the subject.
izidor
_______________________________________________
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>) |