[Biococoa-dev] KVO vs. delegate
Alexander Griekspoor
mek at mekentosj.com
Sun Jul 10 04:23:31 EDT 2005
Yes, it's definitely a pity that they could come up with a kind of
standard delegate syntax you could use to catch the KVO
notifications, like KVC also picks up general things like setColor,
or isExtensible. It would have been nice if you could have the
according -colorChanged or extensibleChanged methods being called
upon a change in values. Alas.... I don't like the if if if if if's
either..
Alex
On 9-jul-2005, at 21:11, Charles Parnot wrote:
> I agree with you Alex, that there won't be too many cases where the
> BCSequence needs to notify about what it does. In the case of model
> objects, delegates and notifications are good for callbacks. For
> instance, IO and networking, when you want to be notified by the
> model object (e.g. a file handle, a server, ...) when something
> happens, asynchronously. In the case of BCSequence, there is
> nothing like that... at least at present. Maybe in the future, we
> will have tasks performed asynchronously, for instance alignements
> or lengthy calculations. In these cases, delegates and
> notifications are good. I am not even sure that would be BCSequence
> dealing with this, probably BCTools.
>
> So I am saying KVO should be enough for BCSequence.
>
> Now, just as a general discussion, I just want to emphasize the
> limitations of KVO, actually more the PITA aspect of it. I am
> fighting a lot with the Xgrid APIs (the fight is almost over, and I
> think I am winning). The reason is there is no delegate (except in
> 2 classes) or notifications. You are supposed to do everything with
> KVO. And you have all sort of asynchronous stuff happening: every
> action done on a job, a server, a grid, results,... is sent to the
> server, and you have to 'observe' a different key and a different
> object for all. The problem is: there is only one callback method,
> which is:
> - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)
> object change:(NSDictionary *)change context:(void *)context
>
> So all the event end up calling that method, and you have to go
> with a bunch of 'if' to test all the possibilities. Also, the
> method tends to be called very often depending how the code was
> written, and depending on what the bindings and UI is doing, which
> you can't control. For instance, I see the array of jobs of a grid
> go from empty array, then nil, then empty array, then half full,
> then half empty, then all the jobs are here.
>
> To avoid all the 'if's, you could have a different class for each
> event, each with their own code, but that is not feasible when you
> have 20 different things happening, because then you need 20
> classes. Conversely, with the delegate design, each event is
> dispatched to a different method, and the code is much easier to
> write, debug and maintain. The code for the Xgrid classes that have
> a delegate was a breeze to write and test.
>
> This is all to show you where the line between a delegate/
> notification design and a KVO-only design is, and what the user of
> the framework will potentially face.
>
> Of course, the BIG advantage of KVO is bindings. And this is really
> very cool. I am using it a lot now, together with Core Data, and it
> is really fun. BTW, John, we will have to talk about Core Data at
> some point ;-)
>
> charles
>
>
> On Jul 9, 2005, at 11:36 AM, Alexander Griekspoor wrote:
>
>
>> Wait!
>>
>> Ok, let me begin with Charles question what I'm talking about. The
>> answer is yes, the sequence can have a delegate and still be a
>> model yes.
>> BUT, let me try to convince what I meant with my remark and how we
>> can do it in a better way.
>> First, the model-view-controller (MVC) design pattern. BCSequence
>> is our model class, it contains the data. The idea behind this
>> pattern is that the model never has any idea about the view its
>> data is presented in, and is thus also not responsible for
>> updates, data changes etc. This is all controlled by the
>> controller which insulated both from each other and keeps both in
>> sync. So if for instance the users edits the sequence in the gui,
>> this should be picked up by the controller which makes sure the
>> edit is forwarded to the model object. Thus, it would not make
>> sense to have the model for instance being a delegate of the view,
>> hence bypassing the controller. Also, why should the controller be
>> the delegate of the model? The ONLY one changing the model is the
>> controller, so if it does it should know already right!
>> Now, I admit there are situations that this is not completely
>> true. Imagine a alignment controller A which aligns several
>> sequences and communicates this via an alignment view. Now the
>> same sequences could potentially be altered by a different
>> controller B which presents the user with a standard sequence
>> editing window. Now of course we would like controller A to redo
>> the alignment and update the view. According to the MVC pattern it
>> would be controller B's task to initiate the update of A (via
>> delegation or notification), so officially no problem and still no
>> need for the model to contain notifications/delegations. Still,
>> sometimes it would be handy to be able to monitor the changes made
>> to a model object if multiple controllers potentially edit the
>> same model object.
>> Now what, notifications, delegations. I don't like the idea of
>> sending "public" notifications into the air, and remember if we
>> create or edit sequences a lot (which you do with model objects),
>> this could create a lot of overhead, and could clog the
>> notification system). Now delegates is more direct, but then
>> again, you could only have one delegate, a severe limit for
>> situations as described above!! In addition, in both case to make
>> it work the code (most notable the accessors) will have to be
>> polluted with delegation invocations (plus a check whether there
>> actually is a delegate, plus a check whether the delegate responds
>> to that call) or notification dispatches. Aaaaaahhh!!!
>> Luckily there's something better, called Key-value-observing
>> (KVO), allowing exactly what you guys are looking for, available
>> in 10.3 or higher (now, did we all agree already that 10.3 is our
>> lower limit). It's part of the famous "binding" system, and allows
>> controllers to register themselves as observers for certain
>> properties of the model object and get notifications when these
>> changes so they can do their things. Sounds pretty good huh! How
>> does it work? We just have to be key-value-coding (KVC) compliant,
>> which we are already, hooray! NSObject provides automatic support!
>> If we decide that at somepoints we need more control, there are
>> additional methods that can be called to trigger observers like
>> didChangeValueForKey. I strongly suggest to not go for delegates,
>> not for notifications, but for KVO, which means we don't have to
>> do anything, nice huh! Here's more info on KVO:
>> http://developer.apple.com/documentation/Cocoa/Conceptual/
>> KeyValueObserving/KeyValueObserving.html
>>
>> Cheers,
>> Alex
>>
>>
>>
>>
>>
>> On 9-jul-2005, at 8:28, Charles Parnot wrote:
>>
>>
>>> On Jul 8, 2005, at 9:39 PM, Koen van der Drift wrote:
>>>
>>>
>>>
>>>>
>>>> On Jul 9, 2005, at 12:19 AM, Charles Parnot wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>> Hmm, although certainly nice to have a link between a view and
>>>>>> ultimately the sequence, this is the task of a controller
>>>>>> class, not the model... The model shouldn't know/care of the
>>>>>> view. It might be nice, if we add controllers to the framework
>>>>>> that do this though..
>>>>>> Alex
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> I am not sure what you both mean. Just to add to the confusion:
>>>>> BCSequence can have a delegate and still be a model, no?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> Why not let BCSequence post notifications when something has
>>>> changed? This way it is ot conected to a view, but and any
>>>> object (including a controller or a view) can respond to it.
>>>>
>>>>
>>>> - Koen.
>>>>
>>>>
>>>
>>> Yes, the standard in Cocoa seems to have both a delegate and
>>> accompanying notifications, which the delegate always get without
>>> subscribing.
>>>
>>> charles
>>>
>>> --
>>> Xgrid-at-Stanford
>>> Help science move fast forward:
>>> http://cmgm.stanford.edu/~cparnot/xgrid-stanford
>>>
>>> Charles Parnot
>>> charles.parnot at gmail.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Biococoa-dev mailing list
>>> Biococoa-dev at bioinformatics.org
>>> https://bioinformatics.org/mailman/listinfo/biococoa-dev
>>>
>>>
>>>
>>
>> *********************************************************
>> ** Alexander Griekspoor **
>> *********************************************************
>> The Netherlands Cancer Institute
>> Department of Tumorbiology (H4)
>> Plesmanlaan 121, 1066 CX, Amsterdam
>> Tel: + 31 20 - 512 2023
>> Fax: + 31 20 - 512 2029
>> AIM: mekentosj at mac.com
>> E-mail: a.griekspoor at nki.nl
>> Web: http://www.mekentosj.com
>>
>> Microsoft is not the answer,
>> Microsoft is the question,
>> NO is the answer
>>
>> *********************************************************
>>
>>
>
> --
> Xgrid-at-Stanford
> Help science move fast forward:
> http://cmgm.stanford.edu/~cparnot/xgrid-stanford
>
> Charles Parnot
> charles.parnot at gmail.com
>
>
>
> _______________________________________________
> Biococoa-dev mailing list
> Biococoa-dev at bioinformatics.org
> https://bioinformatics.org/mailman/listinfo/biococoa-dev
>
>
*********************************************************
** Alexander Griekspoor **
*********************************************************
The Netherlands Cancer Institute
Department of Tumorbiology (H4)
Plesmanlaan 121, 1066 CX, Amsterdam
Tel: + 31 20 - 512 2023
Fax: + 31 20 - 512 2029
AIM: mekentosj at mac.com
E-mail: a.griekspoor at nki.nl
Web: http://www.mekentosj.com
Windows is a 32-bit patch to a 16-bit shell for an 8-bit
operating system, written for a 4-bit processor by a 2-
bit company without 1 bit of sense.
*********************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bioinformatics.org/pipermail/biococoa-dev/attachments/20050710/084420b8/attachment.html>
More information about the Biococoa-dev
mailing list