Get these flashcards, study & pass exams. For free! Even on iPhone/Android!

Programmiere an eine Schnittstellen, nicht an eine Implementierung!

Programmteile (Modul) sollten nur die Schnittstellen voneinander kennen , nicht die Implementierung

"Baukastenprinzip"



Analogie:
USB-Schnittstelle an Computer
- alles mögliche kann angeschlossen werden
( Stcik. Drucker, Maus...)

- dem PC ist das egal
---> lose Kopplung

Gegenbeispiel:
Mikrofon-Eingang
- hier kann auch Lautsprecher angeschlossen werden
-> Schnittstelle passt !
- Lautsprecher realisiert Schnittstelle "Aufnahme" aber nicht!
- so kann nichts aufgenommen werden !

Modul Computer ist von Implementierung des angeschlossenen Gerätes (Mikrofon) abhängig
=> Enge Kopplung

- Software ist nie "fertig"
- Anforderungen können sich jeder Zeit ändern
- Software wird ständig erweitert/ verändert
- Enge Kopplung zwischen Klassen erschwert Erweiterbarkeit/ Veränderbarkeit
- kleine Änderung kann aufgrund enger Kopplung ganze Systeme lahm legen

     "Domino-Effekt"
- Lose Kopplung wünschenswert

-> Interfaces

Grad der Abhängigkeit zwischen Teilen eines Programms

entspricht einer engen Kopplung

- Klassen nehmen in vielen Details Bezug aufeinander

Problem: Änderungen an Basisklasse können Funktionalität von Subklasse beeinträchtigen.

- Klassen innerhalb einer Anwendung (fast) unabhängig voneinander
- Verzicht auf vererbte Funktionalität ermöglicht flexiblen Programmentwurf
- Implementierungen sind gezwungen, Interface-Methoden zu überschreiben, bleiben dabei aber austauschbar
- immer zu bevorzugen !!!

Objekte können oft mehr als einer Kategorie zugeordnet werden. Das ist mit extends nicht möglich, weil jede Klasse maximal eine Superklasse hat.

NEIN

Implementierungsvererbung mit bedacht einsetzen!
- bei wahrer Spezialisierung einer Klasse
- Wenn Programm nicht erweiterbar sein soll
- Wenn große Coderedundanzen vorhanden

zusätzliche Sprachfeature in Java
- "Klasse " ohne Daten und Implementierung

Sammlung abstrakter Methoden und (ggf.) Konstanten

enthält Keine Konstruktoren
-> keine Objekterzeugung möglich

Realisierung loser Kopplung

beinhalten ausschließlich öffentliche , abstrakte Methoden sowie Konstanten

können sich gegenseitig erweitern (extends)

können nicht erzeugt werden

Klassen können beliebig viele Interfaces implementieren

mit Schlüsselwort interface statt class

Konvention: Interface-Bezeichner beginnen immer mit Großem   "I" gefolgt von weiterem Großbuchstaben

Methoden sind implizit abstrakt und öffentlich
( public abstract)
- Modifizierer können weggelassen werden
- deklariert nur Kopf einer Methode ohne Rumpf
- Am Ende abgeschlossen durch Semikolon


Interface für strombetriebene Geräte:
public interface IStrombetrieben{
    <RÜCKGABETYP><BEZEICHNER> ( <PARAMETER>);
      void einschlaten (int spannung);
      void ausschalten();
}

mit Schlüsselwort "implements"

Beispiel:

Mixer hat (mind) selbe Schnittstelle wie IStrombetrieben

public class Mixer implements IStrombetrieben{
     private boolean istAn = false;
     private static final int
          MAXIMALE_SPANNUNG = 240;

     public void einschlaten(int spannung){
          if(spannung <= MAXIMALE_SPANNUNG) {
               this.istAn = true;
          }
     }
    
     public void ausschalten(){
          this. istAn = false;
     }
}

Interface kann als Vertrag betrachtet werden.

Interface-Entwickler legt einzuschaltende Schnittstelle fest

Interface-Nutzer ist verpflichtet, alle Methoden des Interfaces zu implementieren
- falls nicht, gibt Compiler Fehlermeldung aus
- Interface-Entwickler kann sich frühzeitig auf Schnittstelle verlassen -> Polymorphismus

Objekt kann zu Laufzeit Verhalten ändern

Wir unterscheiden:

Überladen von Methoden (statischer Polymorphismus)
z.B.
- beim Überladen von Konstruktoren (VL05)
- Überladene Funktionen in java-API oder GraphicIO

Überschreiben von Methoden (dynamischer Polymorphismus)

- Methoden eines Objektes tragen gleichen Namen und gleichen Rückgabetyp
- müssen unterschiedliche Parameterliste haben
- Methoden befinden sich in gleicher Klasse oder Subklasse.
- Methodensignatur unterscheidet sich lediglich in Parameterliste
-Compiler vergleicht bei Aufruf übergebene Parameter mit Methodensignatur und wählt die am besten passende Methode
- Methoden können beliebig oft überladen werden
-GraphicIO setzt stark auf Überladen von Methoden!
=> Gute Quelle!

Beispiel für unterschiedliche Parameteranzahl:



Beispiel für unterschiedliche Parametertypen:

public void print(int intValue) {
     ...
}

public void print(String stringValue) {
     ...
}

public void printTest(){
     print(137);                    wählt erste "print"-Methode
     print("TEST");              wählt zweite "print"-Methode
}

Polymorphismus im engeren Sinn

beruht auf 3 Prinzipien
- Überschreiben von Methoden
- Substitutionsprinzip
- späte Bindung/ dynamische Bindung

- Subklasse erbt Methoden der Superklasse
-Methode, welche in Superklasse definiert ist, wird in Subklasse überschrieben
- komplett gleiche Signatur (Name und Parameterliste), nur Rumpf wird geändert
- Subklasse blendet geerbtes Verhalten aus.

Verhalten kann so genauer an Subklasse angepasst werden.

Ausnahme :
Methoden nicht überschreibbar, wenn sie mit private, final, oder static definiert wurden.

Objekttypen:
polymorphe Referenzen - können potentiell verschiedene Typen annehmen .
- den deklarierten Typ und alle seine Subtypen

Objekt von Typ kann also zur Laufzeit substituiert (ersetzt) werden
- Figur kann Kreis, Rechteck, Dreieck oder Kugel sein
- Figur kann sich also entsprechend unterschiedlich verhalten

Erlaubt, weil Subklasse das Verhalten der Superklasse erbt!

‐ statischer Typ legt Zugriffsmöglichkeiten auf Methoden fest

‐ Methode einer Klasse kann nur von Objekt mit statischem Typ dieser Klasse aufgerufen werden

Beispiel
Kugel kugel;  Deklaration legt statischen Typ fest
kugel = new Kugel() ; Definition legt Laufzeittyp fest

‐ Kugel ist statischer Typ und Laufzeittyp

Figur andereKugel; statischer Typ ist Figur andereKugel
= new Kugel(); Laufzeittyp ist Kugel
andereKugel.rolle(); NEIN! Figur kennt "rolle" nicht!

Aufruf der Methode eines Objekts stößt Methodensuche an

Fall1
Klasse des Objektes hat KEINE Superklasse -> in Klassendefinition des Objekts beschriebene Methode wird ausgeführt.

Fall 2
Klasse des Objekts hat Superklasse
a) Klasse des Objekts hat gewünschte Methode überschrieben
-> überschriebene Methode (und nur diese!) wird aufgerufen

b) Klasse des Objekts hat gewünschte Methode NICHT überschrieben -> Methodensuche wird bei Superklasse fortgeführt, usw.

Bessere Abbildung der Wirklichkeit:
ermöglicht variable Anpassung des Verhaltens von Methoden an Kontext

ermöglicht hohe Wiederverwendbarkeit

lose Kopplung

Austausch von Objekten führt zu Verhaltensänderung
- ein und derselbe Code kann unterschiedliche Aufgaben abarbeiten
- für Entwurfsmuster sehr wichtig