How to model an arbitrary number of types

Question

I'm currently in the process of modelling a generic form of RNA and RNA transcription and I'm having difficulty finding a proper OO modeling of this area.

Human RNA has 4 types of Nucleotides (A, G, U, and C). An RNA strand is just a string of these 4 types. eg, AAGACAUUCUA...

What I'm trying to model is more generic in the sense that I want to be able to decide the number of Nucleotide types at runtime. So, my object model needs to be able to represent an arbitrary number Nucleotide types.

Initially, I thought I'd just have a Nucleotide class which had a int TypeId member. This way, I could have a sequence of Nucleotide instances of arbitrary types... but this doesn't feel right.

I'm not a huge fan of storing type in a variable. I'm also not comfortable with what is essentially definition information being set on every instance (instead of being defined in the a class).

So, how do I get around this? Here's what I've come up with so far:

• On a previous project, we would have Singleton objects which represented another object's type. The other object would simply reference the singleton and that was it. It prevented us from having multiple instantiations of the "definition" of our types. Not too great IMO.
• I remember Entity Framework generating Dynamic Proxies at runtime. I could so something similar. I could have a NucleotideBase base class and, at runtime, define derived classes. I believe this is possible through reflection. I'm not sure what the performance impact is with this approach, but I would assume it's all just one-time overhead when defining the classes.

Are there better, more OO, approaches?

Answer 1

If a nucleotide has no significant behavior, and if its type information can be represented compactly (for example, a single character), then it doesn't deserve a separate class at all. Simply represent each nucleotide as a character (or whatever).

If, however, a nucleotide has behavior, then I would model this with singletons, one instance per nucleotide type.

Since there is no difference in behavior in nucleotides, they are simple value objects. A nucleotide instance should be immutable, so that all nucleotides of a given type can be represented by a single instance.

I would like to use the nucleotide's symbol as its type; this would be the sole instance variable of a Nucleotide.

A nucleotide factory can keep track of the singleton instances of nucleotide, creating a new instance when a new nucleotide type is asked for, or returning an existing instance otherwise. Depending upon the language, it may be convenient for this factory to be implemented in static methods of the nucleotide class.

Answer 2

• I would use byte TypeId instead of int TypeId, because when you make RNA strands with long lists of Nucleotides, you don't want to waste 4 times of the memory you really need. The TypeId should be the only member attribut of that struct. If you need additional information for some operations, try to use the Flyweight pattern. So a List<Nucleotide> with 1000 elements will need almost exactly 1000 bytes in memory, with neglectable overhead (in C#).

• if you don't expect different behaviours for different Nucleotide types, it feels complety wrong for me to use different derived classes for representing the types. Don't overcomplicate things - only because different derived classes can technically be used for distinguishing types, it is not always the best solution.

Answer 3

How about an enum for the Type?

[Flags]
public enum Nucleotide : byte {
    undefined =0,
    A = 1,
    G = 1 << 1,
    U = 1 << 2,
    C = 1 << 3
    . . . 
    Z = 1 << 25   // of course a byte can't handle this
}

• Easily extensible as shown. The notation keeps me from having to actually write out the value of 2^25 for Z

• I can see manipulating List<byte> or List<Nucleotide> or Stream as needed and casting if/when necessary.

• Handy for passing to a Factory to build Nucleotide-specific behavior objects
• A Nucleotide Property in some other class effectively makes sub-classing unnecessary.
• The Flags attribute will allow us to define simple Nucleotide combinations, or even separate enums of those. You can go kinda crazy abstracting bit manipulation via enum I suppose. Direct bitwise manipulation could mitigate execution time issues and make the code expressive in Nucleotide terms.
• enums are essentially constants and compile to constants in IL, i.e. good performance. Casting is quick.

.

[Flags]
public enum Pairs : byte {
    AC = Nucleotide.A | Nucleotide.C,
    GC = Nucleotide.G | Nucleotide.C, 
    . . .
}

EDIT

@MichaelT comment got me thinking about structure vis-a-vis classification; that, and I'm with DocBrown's comment "..don't over complicate things." It seems to me that structure is classification.

Tuple class may be useful. It is intended as a generic data structure.

var Phenylalanine = 
   Tuple.Create(Nucleotide.T,Nucleotide.T,Nucleotide.T);

"there is no practical limit to the number of components a tuple may have ... you can create tuples of eight or more elements by nesting tuple objects in the Rest property "

Tuple is immutable so it can be treated kinda like a singleton.

Implement IStructuralEquatable for those codons. The 3-Tuple class explicitly implements IStructuralEquatable.

It is Typed of course so this seems to fit the need to create types at runtime. Perhaps use a Factory to encapsulate a specific Tuple object with its IStructrualEquatable implementation.

Answer 4

I would try the following for starters.

A, G, U, and C should all derive from a base class nucleotide - they are specific instances of the abstract class that nucleotide represents. In OO modeling parlance "A is a nucleotide"

This gives you the ability to extend all 4 classes of nucleotides at once, or just the individual nucleotide.

You'll need another class to model the Strand as a strand is composed of a series of nucleotides. "Strand has a (list of) nucleotides". You can likewise extend the Strand class to perform operations that a strand would be responsible for but that a nucleotide would not be responsible for.

I also added an interface for "just in case" purposes. For the immediate uses, the base nucleotide class should be sufficient, but if not, then an interface is there to help guarantee behavior.

Likewise I used a List collection in the Strand so I don't have to worry about particulars such as the strand length when first modeling. Most OO languages should have an equivalent generic collection to use.

class Program
{
    static void Main(string[] args)
    {
        Strand myStrand = new Strand();

        myStrand.Add(new A());
        myStrand.Add(new G());
        myStrand.Add(new U());
        myStrand.Add(new C());
    }
}

public interface INucleotide 
{
}

public class Nucleotide : INucleotide
{
    public byte TypeID;
}

public class A : Nucleotide {}
public class G : Nucleotide {}
public class U : Nucleotide {}
public class C : Nucleotide {}

public class Strand
{
    private List<INucleotide> Nucleotides = new List<INucleotide>();
    public void Add(INucleotide nuc)
    {
        Nucleotides.Add(nuc);
    }
}

The above sample is in C#.

Singletons really aren't appropriate for this modeling exercise - there isn't anything "single" about what you're modeling. You'll have potentially many instantiations of A, G, U, and C as well as the Strands.