[Biococoa-dev] Sequence factory

Koen van der Drift kvddrift at earthlink.net
Sun Dec 26 10:33:25 EST 2004

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.

> 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.

> 3. About BCSymbolListFactory
> At 1:31 PM -0500 12/24/04, Koen van der Drift wrote:
>> BTW, what is you guys opinion on adding a BCSymbolListFactory class 
>> as well?
> 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?

> 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 


- Koen.

More information about the Biococoa-dev mailing list