Antipattern – code usability

Published by Lukas.Pupka.Lipinski on 30. Juni 2019

Schnittstellen zu fremden System werden explizit entworfen. Jede weitere Methode die angeboten wird ist genauestens auf dem Bedürfnis des späteren Nutzers abgestimmt. Oftmals sind diese Schnittstellen gut definiert bzw. Ein Dritter ist in der Lage diese zu nutzen. Nun warum wird dieses Prinzip nicht auf jedes Modul, welches intern genutzt wird, angewendet? Auch hier gibt es einen späteren Anwender, bzw. Ein Kollege der dieses Modul verwenden soll.
In dem folgenden Beispiel wird ein antipattern gezeigt. Dort ist ein kleiner Ausschnitt eines Settings Modul beschrieben. Dieses Modul soll ein Setting verwalten, das heißt in eine DB schreiben und lesen.

    // folgende schritte werden benotigt um ein menu punkt hinzu zu fügen
    // 1. Füge die enum hinzu
    // 2. Füge den typ hinzu
    // 3. Konverter bei komplexen typen
    // 4. Wenn der typ in der db nichz hekannt ist.
    // 5. Wenn der typ verandert wurde und konvertiert werden muss
    // 6. Menü punkt für die settings festlegen
    // 7. Default werte festlegrn
    class Settings{
        // zu 1.
        enum Typ{
            smtp-url,
            smtp-port,
            cachesize,
            temppath
        }
        // zu 2.
        Dictionary<Typ, Type> typelist = new Dictionary<Typ, Type>()
        {
            [Typ.smtp-url] = typeof(string),
            [Typ.smtp-port] = typeof(int) ,
            [Typ.cachesize] = typeof(int)
           
        };
        // zu 7.
        Dictionary<Typ, object> defaultvalues = new Dictionary<Typ, object>()
        {
            [Typ.smtp-url] = "localhost",
            [Typ.smtp-port] = 23 ,
            [Typ.cachesize] = 100000
           
        };
       
        // zu 6.
        Dictionary<Typ, String> menulist = new Dictionary<Typ, String>()
        {
            [Typ.smtp-url] = "E-mail",
            [Typ.smtp-port] =  "E-mail",
            [Typ.cachesize] = "System"
           
        };
    }

 Zu erkennen ist das der Entwickler keine richtige Schnittstelle definiert hat, in der eine Setting hinzugefügt werden kann. Stattdessen wurde ein Kommentar mit Anweisungen hinterlassen. Somit muss ein Entwickler genauestens diesen Anweisungen folgen, um eine Setting korrekt anzulegen. Beispielsweise muss er in einer enum eine neue Settingskey definieren und zu dieser den passenden objekttyp in einer dictionary eintragen. 

Dieses Vorgehen sorgt dafür das der nachkommende Entwickler entsprechende mehr Zeit investieren muss, um eine Setting anzulegen. Außerdem ist die Fehlerwahrscheinlich bei diesem Vorgehen größer, da es zu Missverständnissen kommen kann.
Ich lasse die Frage offen wie dieser Code refactored werden kann. Freue mich über die Kommentare und möglichen refactoring Möglichkeiten.