[Biococoa-dev] Caching the NSArray of BCSymbol

Alexander Griekspoor mek at mekentosj.com
Sat Jul 9 14:36:32 EDT 2005


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

*********************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bioinformatics.org/pipermail/biococoa-dev/attachments/20050709/a051f490/attachment.html>


More information about the Biococoa-dev mailing list