[Biococoa-dev] Sequence factory

[Charles PARNOT]

>On Dec 25, 2004, at 6:56 PM, Charles PARNOT wrote:
>
>>Or the cached stuff could stay inside the class implementation, using the equivalent of 'class instance variables' that can be created with static variables private to the implementation file. Actually, a relevant case is that of enzymes. If the user tries to create an enzyme that has already been created, the factory method (a class method such as '+(BCEnzyme *)EcoRI') or even the 'init' method (an instance method like '-(id)initWithName:(NSString *)name') would return the cached BCEnzyme instance that has already been created. The the BCEnzyme.m implementation file would have a static NSDictionary with the current instances already created.
>
>I guess this is what we already do for BCNucleotide and BCAminoAcid. Only in those cases all possible instances are created at once. For enzymes though, I would keep all info in a plist, and not hard-code any name in BioCocoa. Just because there are much more enzymes than nucleotides, and amino acids.

Yes, BCNucleotide is a much better example... I am not familiar enough with the framework, I should be ashamed of myself... and I am a little bit! At least, it is true that you can cache stuff outside of instances, at the level of a class, which was my point... Pfiou!



>>Of course, this is a way to go and keep the existing pattern. It is not exactly the best of the two worlds, though, because now you have some code dependency. Each of the BCSequence factory methods have to have a counterpart in BCSequenceFactory. If you change the name of one BCSequenceFactory method, you have to change the code in BCSequence. Ah, ah! ;-)
>
>Why? No need to change the name in BCSequence, just call the existing method in BCSequence.

What I meant is you have one method A in BCSequenceFactory that is being called inside a method B in BCSequence. So if you change the name of method A, you have to edit the code in method B. Or maybe more relevant: if you add a method in BCSequenceFactory, you need to add one in BCSequence too, e.g. if you add -(BCSequenceET *)extraterrestrialSequenceWithString in BCSequenceFactory and you want the factory method in BCSequence, you have to also write it (and it will call the method in BCSequenceFactory). The bottom line: more code!

I just want to conclude about BCSequenceFactory. Sorry I have been pushing this so far. I am OK using it if you feel it is safer, I just want to make sure I am not missing something more subtle about it. Thanks Alex and Koen for taking the time to answer my questions :-)



>>Do you mean replacing BCSequenceFactory with BCSymbolListFactory, or do you mean having two separate classes? Having two separate classes seems a bit too much, no?
>
>I meant having two separate classes. We recently introduced the BCSymbolList as a class that only holds an NSArray of BCSymbols, no other info such as name and features. And it has an identifier for the sequence-type. The BCSequence class used to be like this, but it was changed to a subclass of BCSymbolList allowing it to have features, etc. We could have kept the original BCSequence, and create a new class BCAnnotatedSequence, but we found that would result in too long names, such as BCAnnotatedDNASequence. Therefore we introduced the intermediate class BCSymbolList. Actualy a symbol list class can be very handy when doing calculations and manipulations of the sequence itself, without all the other info.
>
>>Having all the members of a class tree created in the same entity seems more appropriate to me.
>
>What do you mean by this?

I know and understand about BCSymbolList/BCSequence. What I call the class tree is the whole family BCSymbolList-->BCSequence-->BCSequenceDNA/Protein,... And I was just saying that maybe one factory for all of them is enough.

BTW, one thing is not clear to me: is BCSymbolList an abstract class (like BCSequence apparrently was) and just used to separate code, or is it going to be instantiable? In my previous emails, I was a little confused about it (and probably confusing).


>
>>To avoid having factory methods spread out in the superclass and the subclasses, you could keep them all in the superclass (they could still return instances of the subclasses). Actually, maybe this would be a bit extreme, and that could confuse the user of the framework, but it is something to think about. That would actually be one step closer to a 'class cluster' pattern... (read below)
>
>The idea of using a class cluster pattern is intriguing, and definitely worth more thoughts. Thanks for bringing it up, Charles.  To clarify it more, could you post some code snippets here using real BioCocoa examples?
>

Wow, now I need to write some real code, and not just be super-theoretical without  having to think about the real world? I am in trouble ;-)
I will try to do something a little later. Kids waiting...

Charles



-- 
Charles Parnot
charles.parnot at stanford.edu

Help science go fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford/

Room  B157 in Beckman Center
279, Campus Drive
Stanford University
Stanford, CA 94305 (USA)

Tel +1 650 725 7754
Fax +1 650 725 8021