Abstrake Kopplung von Klassen zur Kommunikation

[Dey]

Hallo.

ich habe kein konkretes Problem, sondern eine eher allgemeine Frage, die das Thema "Software Engineering" betrifft.

Zurzeit befinde ich mich in meiner Ausbildung und bin in meiner Projektphase. Während dieser habe ich eine Schnittstelle zur Kommunikation zwischen Client-PC und Server von Java nach .NET migriert.

Als Schwäche der bestehenden Programmierung habe ich in meiner Dokumentation die Tatsache angesehen, dass die Klassen zur Kommunikation (diejenigen, die die Socket-Funktionalität implementieren) nicht an Änderungen der Netzwerkinfrastruktur anpassbar sind, weil sie eine konkrete Implementierung verwenden.

Deshalb habe ich in in meinem Programm die Schnittstelle für die Kommunikation durch Verwendung eines Interfaces abstrakt gekoppelt, sodass im Falle einer Änderung nur eine neue Klasse geschrieben werden muss, die das Interface implementiert und seine Methoden "Read" und "Write" überschreibt.

Somit würden sich künftig neue Socket-Bibliotheken nutzen und auch spezielle Parameter nachträglich ändern lassen.

Irgendwo sehe ich jedoch auch ein, dass ich an dieser Stelle mit "Kanonen auf Spatzen schieße" und frage mich, ob die Nutzung einer abstrakten Entität an dieser Stelle sinnvoll/möglich ist.

Was denkt ihr darüber?

 

[skiperr]

Hallo,
bin zwar auch erst in Ausbildung (studium Wirtschaftsinformatik) und auch kein Programmierer. Wir hatten grade letztens eine sehr aehnliche Aufgabe - die Lösung des Dozenten benutzte auch abstract klassen, aus genau den Gründen die Du erwähnst. Das Programm wird dadurch ja in keiner Weise beeinträchtigt - bliebe also nur die Wirtschaftlichkeit der Änderung, welche wohl nur lokal zu beurteilen ist (wie oft und wie viel "hilft" die Erweiterung vs. wieviel es kostet).

 

[Vibrationz79]

Ich persönlich nutze solche Implementierungen gerne und viel - vor allem dann wenn es die Möglichkeit geben könnte später auch mal andere Wege einzuschlagen und das ist gerade in puncto "Datenaustausch" immer wieder mal möglich. Datenaustausch kann auf vielerlei Wegen statt finden und gerade dann halte ich es für sinnvoll, dass man sich ab einer gewissen Ebene überhaupt nicht mehr damit auseinandersetzen muss ob die Daten nun per Netzwerk, Festplatte, Datenbank, Pipes, Shared Memory oder Brieftauben übertragen werden UND dass man zusätzlich noch eine Wahlfreiheit hat über welchen der Wege die Daten nun zum Ziel kommen sollen.

Nachtrag:
Gerade in diesem Punkt ist so eine Abkoppelung über ein Interface ne feine Sache. Ein einzelnes Verfahren zum Datenaustausch fest in den Code integriert zu haben ist natürlich etwas ganz anderes als 5 Verfahren ausprogrammiert bereitzustellen, die man über eine einzelne Variable oder Benutzerabfrage einfach umschalten kann. Ob man später ein Verfahren oder 5 verschiedene Verfahren braucht, sei dahin gestellt - aber man hat später zumindest die Möglichkeit einfach eine Klasse dazu zu programmieren ohne sich den kompletten Code nochmal vornehmen zu müssen und das ist ein enormer Vorteil, finde ich. Natürlich steht und fällt das mit der "Qualität" des Interfaces. Mit 2 Funktionen für SEND und RECEIVE wäre ich persönlich nicht glücklich, denn da würden mir die asynchronen Mechanismen und Events fehlen, aber das ist immer auch eine Frage wie das Projekt aufgebaut ist und was es leisten muss.

 

[antred]

Ich halte diese Einteilung des Programms in klar voneinander gretrennte Module, die nur über sauber definierte Schnittstellen interagieren auf jeden Fall immer für eine gute Idee. Selbst wenn du niemals mehr als nur eine Implementierung für eine Schnittstelle schreibst, kann diese Modularisierung der Robustheit (Wartbarkeit, Debugbarkeit und Erweiterbarkeit) des Codes nur zuträglich sein.

 

[7H3 N4C3R]

Definitiv sinnvoll. Am besten holt man die Kommunikationsklassen auch noch über eine Factory oder über Injection.

So ist der Code, der die Aufrufe macht, frei von jeglichen konkreten Abhängigkeiten und eventuellen Socket-Spezialitäten. Die Frage wäre ja z.B. schon, ob man ein IPv4 oder ein IPv6 Socket erstellt. Vielleicht möchte man aber auch einfach mal eine Pipe oder eine Datei haben. Diese sinnlose Abhängigkeit würde sich dann in deinem Clientcode befinden.
Außerdem kannst du in einem Unit-Test hier einfach einen Stub einbauen.

Damit solltest du insbesondere in der Arbeit deine Entscheidung sehr gut begründen können.