Verschiedene Convert Klassen?

DocShoe

Hallo zusammen,

ich frage mich gerade, wie ich Klassen vernünftig benenne und bin mir mit meinen bisherigen Namen nicht sicher, ob das wirklich schlau ist. Ich habe zB. eine Klasse, deren Inhalt auf drei verschiedene Arten dargestellt werden kann, bzw. ich bekomme sie auf zwei unterschiedliche Arten:

als Liste von benannten Parametern (Key,Value), wobei der Key eine Hierachie bilden kann, in der verschiedene Hierachiestufen durch Punkte getrennt werden: "root.child1.child2.param1".
als Baumstruktur, wo jeder Knoten einen Namen hat und Kindknoten, die durch ihren Namen identifiziert werden. An den Wert von 1) käme ich also über root.GetChild( "child1" ).GetChild( "child2" ).GetValue( "param1" )
als konkrete Datenstruktur mit expliziten Variablen für jeden Parameter (nennen wir es mal Configuration)

Jetzt werden an verschiedenen Stellen die Parameter entweder als Liste, Baum oder Objekt gebraucht, d.h. ich muss die Daten in andere Darstellungen umwandeln (Objekt -> Liste, Objekt -> Tree, Tree -> Liste, etc, alle Kombinationen). Für Configuration kann ich mir noch vorstellen, dass man zwei Methoden ToList und ToTree anbietet, die die Konvertierung durchführt, aber List<T> und Tree<T> sind generisch, da sollte es keine Methoden ToConfiguration geben.

Also eine statische Convert-Klasse, und da fangen die Probleme an. Nenne ich sie "Convert" mit eigenem Namespace? Dann kollidiert sie möglicherweise mit System.Convert und ich müsste alle bisherigen "Convert"-Aufrufe vollständig qualifizieren (Convert.ToString( 17 ) => System.Convert.ToString( 17 ).
Oder gebe ich der Convert-Klasse einen eigenen Namen? Ich brauch vermutlich mehr als eine Convert-Klasse, und da wird´s wieder sperrig: MyDataType1Convert bis MyDataType7Convert?
Wie handhabt ihr sowas?

Th69

Wie wäre es denn, wenn du sie als Extensionklasse erstellst, d.h. eine statische Klasse z.B. "ConvertExtensions" und dort dann für die verschiedenen Typen per this als ersten Parameter angibst?
Dann wären die Aufrufe auch m.E. eleganter, anstatt über eine rein statische Convert-Klasse (was sich für mich auch nicht sehr objektorientiert anfühlt).

DocShoe

Danke für die Antwort, das habe ich mir auch schon überlegt und an den Stellen so gemacht, wo´s mir sinnvoll erschien. Allerdings sträube ich mich ein wenig, sowas in generische Klassen einzubauen:

public static class ConvertExtensions
{
   public static Configuration ToConfiguration( this Tree<string> tree )
   {
      ...
   }
}

Das erweckt iwie den Eindruck, dass man könnte alle Tree<string> in ein Configuration Objekt konvertieren. Andererseits ist ein Convert.ToConfiguration( Tree<string> tree ) auch nicht besser. Wenigstens macht mir die Erweiterungsmethode die namespaces nicht strubbelig. Bin von beidem nicht begeistert, finde aber auch keine Alternativen.
Und weil in C# generell keine freien Funktionen gibt sieht das halt manchmal merkwürdig und umständlich aus ..

firefly

Ne mögliche alternative wäre, wenn die "generatoren" kein generisches Tree<T>/List<T> erzeugen würden sondern eine instanz einer Klasse die dann von Tree<T>/List<T> abgeleitet ist.
Dann wären die namen sprechender.

z.b.

class ConfigurationAsTree : Tree<string>
{}