Ich lese aktuell das Buch "Clean code" in dem unter anderem die SOLID-Prinzipien vermittelt werden. Da ich noch nicht so der erfahrende Programmierer bin, wollte ich meine Aussage die ich einem Kollegen genannt habe bestätigen lassen.

Es ging um eine Case-switch Anweisung und dass er sie "liebt". (wahrscheinlich weil if else sehr mühsam wäre)
Ich entgegnete hingegen, dass case-switch eigentlich immer gegen das OpenClosed Prinzip verstoßen und dass er es über Dependency Injection lösen könnte, weil er dann das Open/Closed Prinzip respektiert.

Falls meine Annahme richtig ist, ergänzen die zwei Prinzipien sich sehr gut.

1. Lag ich mit meiner Aussage richtig?

2. Gibt es weitere Möglichkeiten geschickt case-switch Strukturen zu vermeiden?

Sowohl Dependenciy Injection als auch switch-case-Anweisungen sind mit die schlechtesten Methoden, die jemals in OO-Sprachen eingebracht wurden.

Dependency Injection fordert Bean Konventionen. Beans verstoßen gegen das Geheimnisprinzip. Dependency Injection verstößt somit gegen das Geheimnisprinzip. Beans sollten sowieso vermieden werden (http://www.javapractices.com/topic/TopicAction.do?Id=84)

Switch-Case-Anweisungen verstoßen meistens gegen das Open-Closed-Prinzip und zwar aus folgendem Gründen: Meistens gibt es mehrere Stellen im Code, die ähnlich Abfragen machen, aber unterschiedliche Abläufe steuern. Kommt nun ein neuer Fall hinzu, muss man mehr als eine Code-Stelle anpassen, nämlich jede Stelle, an der die Abläufe anhand des Prädikats gesteuert werden. If- und Switch-Case-Anweisungen besitzen immer einen Default-Fall, der explizit betrachtet werden muss. Strukturell bedeutet Default "alles andere, was ich noch nicht behandelt habe" und für zu einem schlechten, faulen Stil. Die Wohldefiniertheit bleibt auf der Strecke. In OO werden Switch-Case-Anweisunge durch Klassen-Strukturen substituiert. Klassifiziere die Aufgaben einer Anwendung angemessen, dann brauch man wesentlich weniger switch-case-Anweisungen

Anders als gfoidl sehe ich hier sehr wohl Zusammenhänge:

Ein switch-case ist schlecht erweiterbar, hier gibt es durchaus geschicktere Möglichkeiten, "guten" Code zu schreiben (Stichwort Polymorphie). Und wenn man die einzelnen polymorphen Objekte per IoC injiziert, wird auch das noch mal schön entkoppelt.

Ein Artikel, der genau das beschreibt (zwar ohne IoC im Sinne eines Microkernels, aber letztlich lässt sich das leicht darauf adaptieren): http://csis.pace.edu/~bergin/patterns/ppoop.html

IMHO haben switch-case und OCP also sehr wohl miteinander zu tun, und ich finde die Argumentation des Fragestellers seinem Kollegen gegenüber sehr gut.

Ich würde diese Switch Behauptung ein bisschen konkretisieren. Switch Anweisungen sind schlecht um große Flows zu steuern oder zwischen verschiedenen Verhalten zu wechseln, aber Switch Anweisungen können super für Algorithmen oder ähnliches sein.

Scala geht mit dem Pattern Matching da sogar einen Schritt weiter, was für einige Algorithmen, z.B. Merge Sort wirklich sehr nett ist und für asynchrone Programmierung über Aktoren und Nachrichten wirklich genial ist.

Polymorphie steht für manche Szenarien nicht zur Verfügung und da kann ein Switch, z.B. für einen Nachrichten-Typ oder ähnliches durchaus angebracht sein.

Sehr oft handelt es sich bei großen Switches um Mappingstrukturen. Einem Datentyp wird eine Formatierung zu geordnet; Einem Typ die zu validierenden Felder , Zu einem Feld die Methode wie validiert werden soll....

Z.bsp. sowas:

int getNextPrime(int start,string algo)
{
   switch(algo)
      case "Normal":
          algo = new NormalAlgo();
          break;
....
}

Gerade in solchen Fällen ist es deutlich einfacher wenn das Mapping in einem eigenen strukturiertem Element vorliegt z.bsp. in einem Dictionary<T,U>. Ob dieses element intern definiert ist oder von aussen kommt (z.bsp. Injection,Configuration,...) lasse ich mal aussen vor.

Wenn aber eine Komponente ein solches Mapping auswertet oder gar selbst aufbaut, stellt sich mir aber die Frage ob die Architektur an sich optimal ist.

Imo sollte es eine Stelle geben die Entscheidet was / wie etwas getan werden sollte und dann lediglich irgendwo hin delegiert.

Bei Switches welche sich auf eine Art Type Mapping beziehen z.bsp. System.DbType auf den .NET Type finde ich eine Injiziierung eines IEnumerable<TKey,TValue> am einfachsten udn verständlichsten z.bsp.

Type resolvedType = TypeMapping.FromDbType(DbType.String);

Halte ich nicht so viel davon, das ist auch nur ein verstecktes Switch. Bei Änderungen muss genauso die Enumeration geändert werden und eine neue Strategie registriert werden.