Prinzipfrage: Wie hält man's mit OOP

[Dax]

Ich würde in dem Fall auf jeden Fall OOP benutzen, für solche Fälle ist diese Art zu programmieren doch geradezu geschaffen. Um bei deinem Beispiel des Austaschs der Kommunikationsschicht zu bleiben (hier als C#-Code), fiele mir OOP-mäßig sofort das nötige ein:

Code:

interface IChannel {
  void SendString(string s);
  string ReceiveString();
  void WaitFor(int timeOut);
}

Dieses Interface würde ich für jede Art der Kommunikation implementieren und hätte ruck-zuck eine sofort austauschbare Kommunikationsschicht

Prozedural wäre das nicht nur viel schwieriger zu lösen, sondern dazu noch fehleranfälliger, weniger deskriptiv und (sucht's euch aus). Codeblöcke im Namensformat (z.B.) Channel_Method müssten x-fach geladen und ersetzt werden, und wenn es bei einem nicht klappt, geht eventuell nicht mal alles hoch... Was man bei dem OOP-Ansatz nicht hat, dort könnte der Konstruktor eine Exception werfen und alles wär gut. Gerade solche Situationen (viele Methode, die unabhängig voneinander existieren, aber im Grunde zusammengehören) haben bei mir schon häufig sehr schwer zu findende Fehler produziert.