Beim Clean Coden an den Schnittstellen geschnitten.

[Fischkralle]

Hey Leute,
Wie dem Titel zu entnehmen geht es bei meiner Frage um Clean Code. Um genauer zu sein um den Teil der losen Kopplung im Roten Grad.

Für die Wiederverwendung von Funktionalität kennt die Objektorientierte Programmierung (OOP) zwei sehr bekannte Kandidaten: Die Vererbung (whitebox – reuse) und die Komposition (blackbox – reuse). Verwendet man Funktionalität wieder durch das Ableiten von einer Klasse, so ist die Subklasse abhängig von der Elternklasse. Dies macht ein System in vielen Fällen unnötig komplex, schlechter testbar und erschwert das Austauschen von Funktionalität zur Laufzeit. CCD hat für das korrekte Ableiten das Liskov Substitution Prinzip (LSP) bereit, das es dabei zu befolgen gilt.

Bei der Komposition verwendet eine Klasse eine andere. Verwendet man dazu eine klar definierte Schnittstelle, fördert das die Entkopplung. Auch können verschiedene Implementationen einfach ausgetauscht werden. Bevor man sich also der Liskov Substitution stellt, fordert Favour Composition over Inheritance, sich die Frage zu stellen, ob man der Komposition nicht Vorrang geben kann.

„Because inheritance exposes a subclass to details of its parent’s implementation, it’s often said that ‚inheritance breaks encapsulation„. (Gang of Four 1995:19)

Leider fehlt mir noch der Sinn hinter dem ganzen. Aber lasst mich mal meine Ansicht an Hand eines Beispiels erklären:
Ich möchte mehrere Tiere (Warum auch immer) in einem Programm abbilden. Nehmen wird den Hund, die Katze und die Maus. Alle Tiere sind in der Lage zu Fressen. Ich könnte mir nun eine Klasse Tier schreiben, in der ich die Methode eat() unterbringe. In dieser Methode befindet sich ein Algorithmus, der mit Hilfe von vorgefertigten Variablen errechnet, wie lange das jeweilige Tier essen muss, bis es satt ist.
Diese Klasse wird von allen Tieren geerbt und aufgerufen sobald es ums essen geht.
Mit einem Interface könnte ich die Tiere zwar dazu bringen die Methode eat() anzunehmen, doch müsste ich diese, da sie ja nur abstract ist, in jedem Tier noch einmal ausformulieren.
Möchte ich diese nun ändern muss ich das beim Interace in jeder Tierklasse machen und bei der Vererbung nur in einer.
Ich habe mir schon einiges durchgelesen doch habe ich noch keinen wirklichen Vorteil der losen Kopplung gefunden (oder verstanden)
Ich hoffe hier kann ein wenig Licht ins dunkel der losen Kopplung gebracht werden.

 

[Joose]

Mit einem Interface könnte ich die Tiere zwar dazu bringen die Methode eat() anzunehmen, doch müsste ich diese, da sie ja nur abstract ist, in jedem Tier noch einmal ausformulieren.

Nein deine Superklasse "Tier" (von welcher die spezifischen Tiere ja dann wahrscheinlich ableiten) kann abstrakt sein und dieses Interface bzw. dessen Methoden trotzdem implementieren.
Die Subklassen können müssen diese aber nicht überschreiben

 

[Kababär]

Ein Interface ist ja nur ein Vertrag, der as Verhalten von Objekten sag ich mal, vorgibt.
Dabei ist es erstmal egal, wie die Klassen die Methode implementieren, hauptsache sie tun es.
Weite dein Beispiel mal aus:
Du hast eine Klasse Baum und eine Klasse Hund. Beide können sich ernähren und das geschieht auch auf total verschiedenen Wegen.
Vererbung würde ich einsetzen, wenn ich eine Klasse um Funktionen erweitern will.
Bspw: Lebewesen kann atmen
Hund extends Lebewesen weil ein Hund atmen kann und sich bewegen kann.
Baum extends Lebewesen ?
Kann ein Baum mehr als nur die 4 Bedingungen für ein biologisches Objekt?

Seltsames Beispiel aber ich hoffe ich konnte helfen.

 

[Fischkralle]

Hmm.....
Ich danke euch erst mal für die Antworten.
Leider sind das genau die Antworten, die ich auch im Internet überall gefunden hatte. Mir bleibt also immer noch der Vorteil der Interfaces verborgen.
Ich sehe die Dinger sogar als Nachteil an, da ich den Code,der hinter einer solchen Methode steckt ja immer noch selber tippen muss.
Was das jetzt mit der losen Kopplung soll ist mir immer noch nicht bewusst
Ich meine, wenn ich einen........ sagen wir Baum und einen Hund habe, die zwar beide wachsen können, sich der Baum jedoch mit einigen Eigenschaften des Hundes (wie springen oder bellen) schwer tut, und mir die Methode wachsen() über ein Interface rein hole, muss ich den Methoden Rumpf immer noch in jeder Klasse selber schreiben.
Möchte ich nun, aus was für Gründen auch immer, dass die Zeit rückwärts läuft muss ich jede Klasse anpacken, die dieses Interface besitzt. Auch alle x Hunde. Würden die Hunde nun von einer Klasse z.B. MasterDog diese Methode erben,
müsste ich für alle x Hunde nur diese eine Methode in MasterDog ändern und kann so auch keinen Hund vergessen.

 

[Kababär]

Betrachte das Ganze doch einfach mal anders rum:
Du arbeitest in einem Team und schreibt ein Programm, das FTP unterstützt. Während du dich mit der Applikation an sich beschäftigst (GUI etc), programmiert dein Partner die Verschlüsselung und stellt dir nun ein Interface bereit, das zwei Methode hat "encrypt" und "decrypt". Wie das implementiert ist, interessiert dich gar nicht, aber du kannst damit arbeiten. Du brauchst ja lediglich nur das Interface. So machen es auch viele Firmen: schreiben Programme und die Schnittstelle zum Kunden ist ein Interface. Der Kunde kann diese Interfaces benutzen ohne zu Wissen was wirklich dahinter steckt (interessiert ihn ja auch nicht, hauptsache es funktioniert). Sehr häufig findet man Interfaces im Server-Client Bereich.
Am Anfang tat ich mir auch schwer damit. Aber da ich jetzt "schon" aktiv ein Jahr programmiere, kann ich sagen, dass Interfaces schon ne gute Sache sind.

 

[Flown]

Lose Kopplung heißt, dass Teile leicht ausgetauscht werden können.
Wie schon beschrieben ist ein Interface eine Garantie für eine gewisse Schnittstelle. Nehmen wir als Beispiel das Interface "Savable":

public interface Savable<T> {
  public  void save(T t);
}

Jetzt kann ich diverse Implementierungen haben, wie ich ein Objekt speichere: XML, Serialisierung (bytes), Datenbank, ...
Aber was alle dann gemein haben ist die Methodesave(T t) und die dazugehörige Implementierung kann ich leicht austauschen.
Konkret heißt das, dass man das Implementierungsdetail außer acht lässt, was widerum folgt nennt sich dann eben: lose Kopplung.

 

[Kopak'rraf]

Mein Lieblings-beispiel zu diesem Dilemma ist "Frosch, Ente und Auto quaken lassen"

Vererben solltest du immer nur dann, wenn die Subklasse in einer "Ist ein Beziehung" zu seinem Super steht:

• Ente ist ein Tier.
• Frosch ist ein Tier.
• Aber: Die Ente ist kein Frosch.

Allerdings könnte man auf die Idee kommen, Die "quaken" methode in Tier zum implementieren. Dann hätte diese allerdings auch das Kamel.
Mann könnte auf die Idee kommen die Ente vom Frosch erben zu lassen (oder umgekehrt). Dann konnte der Frosch aber auch watscheln.
Möglich wäre auch eine abstrake zwischenklasse: QuakendeTiere
Allerdings haben wir dann immer noch das Auto model: Ford T. Welches eine quakende Hupe hat. Das kann man gar nicht in diesen Klassenbaum einfügen. Aber dieses Auto soll auch "quaken".

Also ist bei diesen Methoden das Interface Quackable doch besser als eine Vererbung. Um doppelten Code zu vermeiden kannst du dann Traits oder Mixins benutzen.

 

[Neumi5694]

Das einfachste "Interface" ist eine Funktion aus 1 Zahl.
Anstatt sin(x) oder cos(x) könnte man ja auch ein Interface bereitstellen mit einer Methode "berechne(x)".
new SinusKlasse().berechne(x)
new CosinusKlasse().berechne(x)

Je nachdem, was man dann haben will, wird eine andere Instanz zugewiesen, die aufgerufene Methode ist jedoch immer gleich, selbst bei einer neuen Implementierung muss in der aufrufenden Klasse - sofern sie die Berechnungsklasse von außen als Parameter kriegt - nichts neu programmiert werden.

 

[Flown]

Warum werden hier alte Themen ausgegraben, wo sich der TO schon lange nicht mehr blicken lassen hat?

 

[Fischkralle]

Hey,
erst einmal Entschuldigung das ich erst jetzt wieder schreibe aber vor Weihnachten und einem (ungestörten) Urlaub über die Festtage, laufen einige Vorbereitungen voraus.
Das mit der losen Kopplung habe ich nun doch kapiert. Keine Ahnung welchem Beitrag ich das nun zu verdanken habe. Irgendwann beim durchlesen euer Antworten hat es auf einmal klick gemacht und alles war klar.
Danke dafür.
Doch keine Klarheit ohne neue Frage.
Aktuell geht es um Reflection und das Mackieren mit Anotationen.

 

[Fischkralle]

Hey,
erst einmal Entschuldigung das ich erst jetzt wieder schreibe aber vor Weihnachten und einem (ungestörten) Urlaub über die Festtage, laufen einige Vorbereitungen voraus.
Das mit der losen Kopplung habe ich nun doch kapiert. Keine Ahnung welchem Beitrag ich das nun zu verdanken habe. Irgendwann beim durchlesen euer Antworten hat es auf einmal klick gemacht und alles war klar.
Danke dafür.
Doch keine Klarheit ohne neue Frage.
Aktuell geht es um Reflection und das Mackieren mit Anotationen.