7. Objektorientierte Softwareentwicklung/3. Informatik II für Verkehrsingenieure

Transkript

1 7. Objektorientierte Softwareentwicklung/3 Informatik II für Verkehrsingenieure

2 Überblick FOLGENDE BEGRIFFE/PRINZIPIEN SOLLTEN BEKANNT SEIN Objekte Klasse Attribute Fähigkeiten ZIEL DER HEUTIGEN LEHRVERANSTALTUNG Vererbung-Vertiefung Abstraktion Polymorphie Objektorientierte Programmierung Abstraktion Vererbung Kapselung Beziehungen Persistenz Polymorphie 2

3 Vererbung

4 Vererbung 4

5 Vererbung Technisch Wiederverwendung von Variablen und Operationen Konzeptuell Spezialisierung bzw. Verallgemeinerung (Generalisierung) von Klassen erben von 5

6 Vererbung Technisch Wiederverwendung von Variablen und Operationen Konzeptuell Spezialisierung bzw. Verallgemeinerung (Generalisierung) von Klassen erben von Man sollte der Versuchung widerstehen, Vererbung zu benutzen, wenn keine konzeptuelle Spezialisierung gegeben ist (nur um einzelne Operationen wiederzuverwenden) 6

7 Umsetzung in Java UMSETZUNG KLASSE MITARBEITER VERERBUNG IN JAVA class SubC extends SuperC { PUBLIC CLASS MITARBEIER { STRING FAMILIENNAME; DATE GEBURTSTAG; VOID BERECHNEKOSTEN() {.. SubC enthält alle Methoden + Variablen aus SuperC Java erlaubt nur eine Ober-Klasse ( Einfachvererbung ) UMSETZUNG ANGESTELLTER PUBLIC CLASS ANGESTELLTER EXTENDS MITARBEITER { VOID ERLEDIGEAUFTRAG() {.. 7

8 Zugriffskontrolle FOLGENDE ZUGRIFFSKONTROLLEN GIBT ES: public Variablen und Methoden öffentlich sichtbar (für alle Klassen) Niedrigste Schutzebene private Zugriff nur innerhalb der Klasse möglich (gilt für Variablen als auch Methoden) höchste Schutzebene protected Betrifft nur Subklassen Zugriffsschutz proctected macht Mitglieder für Unterklassen sichtbar Begründung Subklassen kennen oft die Interna der Elternklasse. Subklassen müssen die Daten einer Elternklasse häufig ändern oder erweitern. 8

9 Beispiel public class Mitarbeiter { protected String name; // für Unterklassen sichtbar protected Date geburtstag; // Konstruktor public Mitarbeiter (String n, Data g) { name = n; geburtstag = g; // getter-methode public String getname() { return name; // setter-methode public void setname(string n) { name = n; 9

10 Beispiel public class Angestellter extends Mitarbeiter { protected double gehalt; // für Unterklassen sichtbar // Konstruktor public Mitarbeiter (String n, Data g, double money) { // getter-methode public double getgehalt() { return gehalt; // setter-methode public void setgehalt(double money) { gehalt = money; 10

11 Konstruktoren METHODEN EINER KLASSE KÖNNEN KONSTRUKTOREN UND METHODEN IHRER UNMITTELBAREN OBERKLASSE AUFRUFEN Super-Konstruktoraufrufe super() à ruft den parameterlosen Konstruktor der Oberklasse auf super(arg) à ruft einen Konstruktor mit einem Argument aus der Oberklasse auf Super-Methodenaufrufe super.m() à ruft die Methode m() der Oberklasse auf 11

12 Selbstbezug this

13 Selbstbezug this IN JEDER OBJEKTMETHODE UND JEDEM KONSTRUKTOR STEHT EINE REFERENZ MIT DEM NAMEN THIS BEREIT, DIE AUF DAS EIGENE EXEMPLAR ZEIGT public class Firma { Angestellter service; public Firma(Angestellter s) { this.service = s; MIT DIESER THIS-REFERENZ LASSEN SICH FOLGENDE PROBLEME LÖSEN Lokale Variablen verdecken Objektvariablen Rückgabe des aktuellen Objektes Referenz auf das eigene Objekt 13

14 Lokale Variablen vs. Objektvariablen BISHER Vermeidung von Namensgleichheit von Variablen public class Firma { Angestellter service; public Firma(Angestellter s) { this.service = s; JETZT Unterscheidung nicht mehr notwendig Mit this immer Zugriff auf die Objektvariable (auf das aktuelle Objekt) public class Firma { Angestellter service; public Firma(Angestellter service) { this.service = service; 14

15 Der Typ von this DER STATISCHE TYP VON THIS IST JEWEILS DIE ENTHALTENE KLASSE In der Klasse K hat this den statischen Typ K 15

16 Beispiel public class Mitarbeiter { protected String name; // für Unterklassen sichtbar protected Date geburtstag; // Konstruktor public Mitarbeiter (String name, Data geburtstag) { this.name = name; this.geburtstag = geburtstag; // getter-methode public String getname() { return name; // setter-methode public void setname(string n) { name = n; 16

17 Abstrakte Methoden und Klassen

18 Konkrete Datentypen BISHER Klassennamen können in Typdeklarationen verwendet werden Angestellter service; // Variable service ist vom Typ // Angestellte PROBLEM: DAS IST ZU UNFLEXIBEL Klasse legt komplette Definition von Zustand und Verhalten fest (Datenstrukturen und Implementierung) Andere Implementierungen des gleichen Konzeptes werden somit ausgeschlossen IDEE: ABSTRAKTE DATENTYPEN Ein abstrakter Datentyp legt nur eine Datenstruktur ( Trägermenge ) und die Signaturen der darauf aufbauenden Operationen fest Verschiedene konkrete Datentypen können einen abstrakten Typ unterschiedlich implementieren 18

19 Abstrakte Methoden und Klassen ABSTRAKTE METHODE Hat keine Implementierung! Ihre Deklaration enthält nur Modifier, Ergebnistyp, Name und Parameter à aber keinen Block!! Reine Festlegung der Signaturen ABSTRAKTE KLASSE Hat mindestens eine abstrakte Methode Abstrakte Klassen dürfen nicht instanziiert werden! Da sie unvollständig sind Sie dienen nur als Oberklassen und als statischer Objekttyp JAVA-SYNTAX Abstrakte Methoden und Klassen müssen durch das Schlüsselwort abstract gekennzeichnet werden 19

20 Beispiel ABSTRAKTE KLASSE GAMEOBJECT Oberklasse für Spielgegenstände Abstrahierung von konkreten Spielgegenständen wie Spieler, Schlüssel, Räume, etc. Oberklasse enthält allgemeingültige Informationen, Unterklassen spezialisieren weiter public abstract class GameObject { public String name; SPEZIALISIERUNGEN VON GAMEOBJECT 20

21 Abstrakte Methoden ABSTRAKTE METHODE GIBT NUR LEDIGLICH DIE SIGNATUR VOR, UND EINE UNTERKLASSE IMPLEMENTIERT IRGENDWANN DIE METHODE Beispiel: Spielgegenstände werden während des Spiel benutzt, egal um welchen Spielgegenstand es sich gerade handelt. Schlüssel öffnet Tür Spieler nimmt Schlüssel Radio spielt Musik public abstract class GameObject { public String name; public abstract boolean useon(gameobject object); 21

22 Vererbung WENN WIR VON EINER KLASSE ABSTRAKTE METHODEN ERBEN, SO HABEN WIR ZWEI MÖGLICHKEITEN: Wir überschreiben alle abstrakten Methoden und implementieren sie. Dann muss die Unterklasse nicht mehr abstrakt sein (wobei sie es auch weiterhin sein kann). Von der Unterklasse kann es ganz normale Exemplare geben. Wir überschreiben die abstrakte Methode nicht, sodass sie normal vererbt wird. Das bedeutet: Eine abstrakte Methode bleibt in unserer Klasse, und die Klasse muss wiederum abstrakt sein. 22

23 Beispiel DIE UNTERKLASSE DOOR SOLL DIE ABSTRAKTE METHODE USEON() ÜBERSCHREIBEN, ABER IMMER FALSE ZURÜCKGEBEN, DA SICH EINE TÜR IN UNSEREM SZENARIO AUF NICHTS ANWENDEN LÄSST. NACH DEM IMPLEMENTIEREN DER ABSTRAKTEN METHODE SIND EXEMPLARE VON TÜREN MÖGLICH: 23

24 Beispiel UNTERKLASSE KEY (SCHLÜSSEL), WOBEI JEDER SCHLÜSSEL ALLE TÜREN ÖFFNEN KANN. 24

25 Interfaces

26 Abstrakter Datentypen KRITIK AN ABSTRAKTEN DATENTYPEN Sie legen eine Datenstruktur ( Trägermenge ) fest! Somit besteht nicht mehr die Freiheit, die gleiche Funktionalität auf einer ganz anderen Datenstruktur zu implementieren Beispiel: Suchen in Bäumen, Listen, IDEE: AUCH VON DER DATENSTRUKTUR ABSTRAHIEREN!!! SCHNITTSTELLEN (INTERFACES) Benannte Menge von Operationsspezifikationen (Signaturen) Jeweils Name, Parametertypen, Ergebnistyp 26

27 Interface (Schnittstelle) INTERFACE Enthält Typen und Namen von Operationen aber keine Implementierung!! Dient der Angabe der Operationen, die ein Objekt mindestens bieten muss, um in einem bestimmten Kontext benutzbar zu sein.. unabhängig von seiner konkreten Implementierung BEISPIEL Sollen in einem Spiel gewisse Dinge käuflich sein, haben sie einen Preis. Eine Schnittstelle Buyable soll allen Klassen die Methode price() vorschreiben. interface Buyable { double price(); alle Methoden sind automatisch abstrakt und öffentlich 27

28 Implementierungsbeziehung Interface I à definiert Schnittstelle Klasse A à Klasse definiert B Schnittstelle à Klasse Implementiert C Schnittstelle à Implementiert Schnittstelle gleiches Interfaces kann von verschiedenen unabhängigen Klassen implementiert werden public class B implements I { public class C implements I { 28

29 Beispiel interface Buyable { double price(); Implementierung der Schnittstelle public class Chocolate implements Buyable{ public double price() { return 0.99; 29

30 Beispiel 2: KOMBINATION ABSTRAKTER KLASSEN UND SCHNITTSTELLEN public abstract class GameObject { public String name; public abstract boolean useon(gameobject object); Unterklasse interface Buyable { double price(); Schnittstelle public class Magazine extends GameObject implements Buyable{ 30

31 Dynamisches Binden

32 Dynamisches Binden interface Buyable { double price(); Implementierung der Schnittstelle public class Chocolate implements Buyable{ public double price() { return 0.99; Buyable b; // Variablendeklaration Chocolate c = new Chocolate(); //Objektinstanz b = c; // ok, Buyable ist Obertyp von Chocolate b.price(); // Welche Methode wird aufgerufen?? 32

33 Nutzen von Schnittstellen WAS BRINGEN SCHNITTSTELLEN WIRKLICH? Was ist der Nutzen dahinter? 33

34 Nutzen von Schnittstellen WAS BRINGEN SCHNITTSTELLEN WIRKLICH? Was ist der Nutzen dahinter? AUFGABE Buyable a1 = new Chocolate(); Buyable a2 = new Coffee(); Buyable a3 = new Magazine(); Double sum = calculatesum(a1, a2, a3); Wie sollte die Methode calculatesum implementiert werden? 34

35 calculatesum AUSNUTZUNG DES DYNAMISCHEN BINDENS POLYMORPHER AUSDRUCK Ausdrücke, die Werte verschiedener Typen annehmen können 35

36 Polymorphismus POLYMORPHISMUS Ermöglicht, dass der gleiche Code Objekte verschiedener Typen bearbeitet (siehe Methode calculatesum ) DYNAMISCHES BINDEN Ermöglicht, dass der gleiche Code trotzdem verschiedene Effekte hat, je nach bearbeitetem Objekt GEMEINSAMER EFFEKT Wiederverwendung des gleichen Codes für eine unbegrenzte Anzahl von Variationen Wartbarkeit!!!! 36

37 Zusammenfassung

38 Take-Home-Message FOLGENDE BEGRIFFE/PRINZIPIEN SOLLTEN JETZT BEKANNT SEIN: Objekte Klasse Attribute Fähigkeiten SCHWERPUNKT DER HEUTIGEN VERANSTALTUNG Abstrakte Klassen Interfaces Polymorhismus Objektorientierte Programmierung Abstraktion Vererbung Kapselung Beziehungen Persistenz Polymorphie 38