Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Philippe Mougin <email@hidden>
- Date: Thu, 6 Jan 2005 04:22:12 +0100
Le 6 janv. 05, à 02:01, Tim Lucas a écrit :
On 06/01/2005, at 9:10 AM, Philippe Mougin wrote:
Here, we are already using the particular conceptual framework of
KVC, since "object attribute" is not a concept that is defined or
used by the OOP theory itself (as opposed as, for instance, the
concept of "object method").
The word "attribute" is synonymous with the word "property" when
discussing OOP theory. I think you may have confused the concept of an
attribute with the concept of an instance variable.
The core foundation of OOP is that an "object" is made up of
Properties and Methods.
There is no such thing as "properties" in the core foundation of OOP.
As far as OOP is concerned "methods" is the only thing that an object
expose. If this was not the case, Objective-C would not be an
object-oriented language, since it has no knowledge of the notion of
"property".
Of course a particular object can describe and expose itself as
"something having properties", in the same way as an object can
presents itself as something having a color, a speed, or something able
to produce some sound, or any other semantics specific to a particular
class. But OOP by itself is not more concerned by the concept of
"property" than by the concept of color or speed or sound.
The fact that some programming languages, like C#, support the notion
of property at the language level does not mean this is part of the
core foundation of OOP.
The following is how KVC technology relates to an Object's properties:
- KVC provides string based access to an object's properties using
'Keys'.
- KVO provides the ability to be notified as to an Object's property's
change in value.
- KVB provides the ability to bind a property of one object to a
property of another.
So how does KVC relate to OO. Let's look at some of the benefits OO
brings to the construction of software:
- Reusability
- Reliability
- Robustness
- Extensibility
- Maintainability
How does KVC affect our OO designs and, hence, which of the above
benefits are affected by using KVC?
From my experience KVC encourages:
- Thoroughly designed, simple object models (reusability, reliability,
robustness)
- Less controller code (reliability, maintainability)
- Use of more advanced abstractions, such as the upcoming core data
(extensibility, robustness)
- Unit test friendly model classes (reliability, maintainability)
I fail to see how KVC negates any of the benefits of OOP or goes
against OOP principles.
I'm considering a much lower, technical level. I'm just stating that
the programming model offered by KVC is not object-oriented and
consequently does not provides the benefits and drawbacks of an
object-oriented programming model, but its own particular sets of
benefits and drawbacks.
Can I advise you to have a look at the article I gave in reference in
an earlier post: "The early history of Smalltalk" by Allan Kay? It
gives a good sense of the power of objects as "sites of higher level
behaviors" and how this is different from other conceptual frameworks,
like the entity-relationship model supported by KVC.
Best,
Philippe Mougin
http://www.fscript.org
_______________________________________________
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