[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
More information about the Biococoa-dev