[Biococoa-dev] KVO vs. delegate

Sat Jul 9 15:11:59 EDT 2005

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