• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
      • From: mmalcolm crawford <email@hidden>
    • Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
      • From: Charlton Wilbur <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>)

  • Prev by Date: Public Apology - was [Re: OT request: Shareware anti-cracking - need info]
  • Next by Date: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Previous by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Next by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Index(es):
    • Date
    • Thread