-1

Currently I have a large ontology like this: enter image description here

There are different categories of variants and each can be somatic or germline. There are more common behaviours between same variants, like somatic CNVs and germline CNVs have more common behaviours due to the fact that they are both CNVs. But there also are a few behaviours common between small somatic and somatic fusions due to them being somatic (this design doesn't account for that kind on reuse).

So I'm thinking of changing it to something else, a strategy pattern with a factory, like this: enter image description here

But this runs into the issue that I have too many behaviours and they are quite specific to a class of variant. Example of behaviours:

  • calculate_position()
  • calculate_gene_location()
  • calculate_log2foldchange()

All these do something different depending on variant type. And they are quite short functions. So I'll end up creating a lot of small behaviour classes and end up with a more extensive ontology.

Not all variants have the same behaviours: some have a protein_prediction() or split_reads(). At the end of the day I want to be able to get 8 classes with the behaviours that I need.

Any ideas of a better way to organise my code?

Claudiu Creanga
  • 298
  • 1
  • 10
  • 2
    Possible duplicate of [Choosing the right Design Pattern](https://softwareengineering.stackexchange.com/questions/227868/choosing-the-right-design-pattern) – gnat Oct 18 '19 at 14:21
  • 3
    One way to go about it is to create the 8 classes independently first, then write some client code, examine how these classes are actually used there; and if you identify some truly common behaviors, or if there's a way to generalize (from the perspective of the client) some group of related behaviors, extract those into a separate class. – Filip Milovanović Oct 18 '19 at 14:41

1 Answers1

3

Are you sure you need design patterns at all ?

Sorry for this provocative counter-question. But all too often, we see questions looking at design patterns, like they were a catalogue of raw material for a proper design.

Design patterns are only predigested solution for common design issues. Instead of looking for patterns that could help to solve problems that you have not yet, first clarify what you want to design first. Use patterns only if there are some helpful match with your own intents.

What is your intent ?

Unfortunately, I'm not biologist and have only little clue about genome and mutations. With google's help, I learnt a little more on somatic and germline cells, stomatic and gemline mutations, fusions and diruptive mutations and CNV. But still, I'm not able to give specific advice about what to inherit and what to compose.

Your narrative suggests that the challenge is to combine the behaviors and master the combinatorial explosions.

It is however not clear how strongly the behavior is related to the kind of variant, how much behavior can be shared across several variants, and how much a separately defined behavior has to know about the variant.

At least three approaches could be considered:

  • inheritance with specific overrides for specific variants. This might result in a deeply nested class hierarchy and some redundant code, looking at redundant characteristics in the ontology. Here, the decorator pattern could help to add behavior that is not common to all kind of variants. The advantage is that behaviors have full access to all the variant's attributes.
  • composition, delegating some behavior to specific component. If several components define together the behavior, multiple dispatch could be considered. This works very well if all atributes of the behavior can be migrated to the component. If behavior is only influenced marginally by some components, the template method pattern combined with delegation could be a better option.
  • composing behavior. The strategy pattern belongs to this category. If works well if parts of behavior can be encapsulated. You may also use the entity component systems approach. It is popular in the game industry, since it allows to keep class hierarchies flat and avoid combinatorial explosion.
  • any combination thereof.
Christophe
  • 74,672
  • 10
  • 115
  • 187