Re: Replacing objects
Re: Replacing objects
- Subject: Re: Replacing objects
- From: WT <email@hidden>
- Date: Tue, 23 Dec 2008 02:10:49 +0100
On Dec 23, 2008, at 1:55 AM, Mike Abdullah wrote:
On 23 Dec 2008, at 00:30, WT wrote:
On Dec 23, 2008, at 1:04 AM, Kyle Sluder wrote:
On Mon, Dec 22, 2008 at 6:03 PM, WT <email@hidden> wrote:
Of course,
the proxy object's class has to share the same interface as the
class of the
objects it represents so that your code doesn't need to know
whether it's
dealing with a proxy or with the real thing.
This isn't true in Objective-C. Take a look at NSProxy, the
canonical
implementation of the very pattern you're describing. To state
this
is to completely miss the characteristics that define Objective-C.
One is not obligated to use NSProxy to implement the Proxy
pattern. I must admit not being all that familiar with NSProxy,
but having the proxy and the object it stands for share the same
public API (by being instances of subclasses of the same abstract
class) seems to me to be a good thing since the object and its
proxy can be transparently swapped in code. If I understand
NSProxy correctly, you lose that transparency when you use it,
because NSProxy and NSObject are in different inheritance trees.
No, the whole point is that although the proxy descends from a
different hierarchy, no-one outside the proxy need know this. All
other code treats it as though it were a non-proxy object of the
expected class. Whenever one of the class's methods gets called, the
proxy object receives a -methodSignatureForSelector: call, followed
by -forwardInvocation:
This saves you having to re-implement and keep up-to-date the entire
API of your custom class from within the proxy.
Ahh... ok. I see the value in NSProxy now. And I now also understand
more clearly what Kyle meant by "missing the characteristics that
define Obj-C".
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden