Comment écrire un code clair et élégant pour une application basée sur un modèle de stratégie?

Question

J'écris une application pour composer des freizes musicaux, mais je m'inquiète un peu de la structure des classes et des interfaces au sein du code. Ici, il y a les signatures de quelques classes I écrivaient:

Interface IGuidoFormattable 
Class Note : IGuidoFormattable, ICloneable 
Class Pause : IGuidoFormattable, ICloneable 
Class Chord : List<Note>, IGuidoFormattable, ICloneable 
Class Key : IGuidoFormattable, ICloneable 
Class Tempo : IGuidoFormattable, ICloneable 
Class Meter : IGuidoFormattable, ICloneable 
Class FretPiece : List<IGuidoFormattable>, ICloneable 
Class Fret : List<FretPiece> 

FretPiece représente une phrase muscial, un morceau de la freize complète. Il expose comme propriétés Key, Tempo et Meter, qui sont homonymes avec leurs types. Plus de phrases réunies créent un freize, représenté par la classe Fret. Chaque élément dans une seule expression doit être formatable conformément à la notation standard GUIDO, par conséquent, il doit implémenter l'interface IGuidoFormattable. Dans un autre espace de noms, certaines classes de mutation sont définis et ils héritent tous d'une des deux classes abstraites:

Class FretMutation 
Class LambdaFretMutation : FretMutation 

Enfin, il existe une classe appelée FretMutationGenerator qui a la seule tâche d'appliquer des mutations sélectionnées sur un thème musical et affiche la totalité de freize en tant qu'instance de la classe Fret. FretPiece doit pouvoir contenir plusieurs éléments différents (notes, pauses et accords dans ce cas), qui doivent néanmoins satisfaire à deux contraintes: ils doivent être formatables avec la notation GUIDO et donc transformés en chaînes significatives; ils doivent être clonables. Dans le code tel qu'il est maintenant, chaque classe implémente ICloneable, mais la syntaxe et la sémantique du code actuel ne permettent pas de cloner tous les membres de la collection. J'ai besoin de trouver un moyen d'exprimer les deux contraintes sans appliquer d'héritage à IGuidoFormattable et de préférence sans définir de méthode Clone dans l'interface IGuidoFormattable.

Deuxièmement, et le plus important, le problème. FretMutation définit une méthode abstraite, "Apply", qui doit être surchargée dans chaque classe dérivée. Par conséquent, toute classe de mutation définit sa propre version de cette méthode, qui a la signature suivante:

FretPiece Apply(FretPiece originalTheme) 

Il accepte en entrée un FretPiece et envoie une copie de cet objet, muté selon tous les autres paramètres spécifiés en tant que membres de la classe. Je pense que c'est une implémentation du modèle de stratégie. Cependant, seulement du fait que cette méthode crée une copie de l'entrée, cela signifie que l'argument lui-même (et donc tous ses membres) doit être clonable. En outre, FretPiece est déclaré comme une liste de IGuidoFormattable, mais chaque classe de mutation se comporte différemment des autres et peut agir sur des notes, des pauses ou des accords en conséquence: cela signifie que je dois vérifier le type de chaque élément et écrire un code différent pour chaque type avec "beaucoup" (en effet, 3 au plus) si déclarations. Et cela me semble très peu orienté objet.

Comment puis-je organiser les classes et l'interface de sorte que tous deviennent plus orientés objet et moins dépendants des hypothèses et des vérifications de type?

Answer 1

Je dois trouver un moyen d'exprimer à la fois contrainte sans appliquer l'héritage à IGuidoFormattable et de préférence sans définir une méthode Clone dans l'interface IGuidoFormattable

Et la troisième option?

public interface ICloneableAndGuidoFormattable : IGuidoFormattable, ICloneable { } 

Ensuite, votre FretPiece est Liste des ICloneableAndGuidoFormattable

Sinon, vous pouvez essayer une telle construction:

public interface ICloneable<T> 
{ 
    T Clone(); 
} 

public class FretPiece : IEnumerable<IFormattable>, ICloneable<FretPiece> 
{ 
    private List<IFormattable> items = new List<IFormattable>(); 

    public void Add<T>(T value) where T : IFormattable, ICloneable<IFormattable> 
    { 
     items.Add(value); 
    } 

    public IEnumerator<IFormattable> GetEnumerator() 
    { 
     items.GetEnumerator(); 
    } 

    IEnumerator IEnumerable.GetEnumerator() 
    { 
     return GetEnumerator(); 
    } 

    public FretPiece Clone() 
    { 
     return new FretPiece { items = new List<IFormattable>(
      items.Cast<ICloneable<IFormattable>>().Select(c=>c.Clone())) 
     }; 
    } 
} 

Et ailleurs par exemple sur votre mutateur:

public T Apply<T>(T fretPiece) where T : IEnumerable<IFormattable>, ICloneable<T> (...) 

Ceci vous assurerait que vous ne pouvez ajouter que des éléments implémentant les deux interfaces. l'énumération suppose uniquement que les IFormattables sont renvoyés. Cela vous permet de transtyper en ICloneable en toute sécurité, car il doit avoir passé la contrainte de type sur "Ajouter". Vous pouvez voir l'implémentation de clone. Même si vous avez un casting là-bas, il est sûr à moins que quelqu'un fout avec items basé sur la réflexion;)

Answer 2

Je voudrais rendre plusieurs d'entre eux immuables. De cette façon, vous n'avez plus besoin de les cloner. Une note est toujours la même note, peu importe où elle apparaît. Il est donc naturel de le rendre immuable. Par exemple Note, Pause, Chord semblent fonctionner comme des types immuables. La plupart de vos autres noms de classe sont charabia pour moi puisque je ne connais pas assez la théorie musicale, donc je ne sais pas lequel d'entre eux pourrait être immuable aussi.