Portal und Domäne trennen

[ralfw]

Derzeit vermischt die Assembly ForceFeedback.Rules.dll zwei Verantwortlichkeiten:

• Zum einen ist sie Schnittstelle zur Umwelt; sie kapselt den VS Extension API. MethodTooLongTextAdornment{} ist der Handler für Ereignisse, die in VS ausgelöst und wo Veränderungen am DOM vorgenommen werden.
• Gleichzeitig wird im Handler aber auch entschieden und getan, was der Domäne entspricht.

Beide Verantwortlichkeiten sollten auf unterschiedliche Klassen oder noch besser Assemblies verteilt werden. Gerade wenn die Domäne in einer eigenen Assembly gekapselt ist, sind Veränderungen daran möglich, ohne Kenntnisse des VS Extension APIs zu haben.

Für eine solche Trennung ist natürlich eine geeignete Schnittstelle zu finden. Beispiel:

interface IForceFeedback {
  void Configure(Configuration config);

  Coloring Determine_method_coloring(string methodname, int numberOfLinesOfCode);
  Noise Determine_typing_noise(string input, string methodname, int numberOfLinesOfCode);
}

struct Coloring {
  public RGB BackgroundColor;
  public int Transparency; // 0..100
}

struct Noise {
  public string Input;
  public int Delayms; // 0..1000
}

Zweierlei würde in dieser Schnittstelle fixiert: dass es um Colorierung und Eingabestörung geht sowie dass die Metrik LOC ist.

Ersteres lässt sich kaum vermeiden. Finde ich aber auch nicht schlimm.

Letzteres ließe sich vermeiden, wenn in die Domänenmethoden der Quelltext hineingereicht würde. Dann könnte die Domäne eine Analyse nach Belieben darauf anwenden.

Aber ich denke, im Moment können wir mit der Vorgabe LOC leben.

[ralfw]

Das Portal (alles das, was vom VS Extension API abhängig ist), sollte sogar in einer eigenen Sln gekapselt sein. Der Rest kann in einer Sln stecken, die völlig unabhängig von den VS Extensions ist und somit von jedem ohne zusätzliche Installationen bearbeitet werden kann.

[ralfw]

Das könnten wir auch mal zusammen in einer Teamviewer Session machen. Ich schaue bei dir mit drauf, denn du hast alle nötigen Tools installiert.