Einführung in die Objektorientierung Enums, innere-Klassen ... · •Jede Methode kann nur auf die...

Name: Patrick Förster

Programmieren in Java Einführung in die Objektorientierung Enums, innere-Klassen, Exceptions


• Repräsentiert eine „ist ein“ Beziehung zwischen Klassen

• Ein Rechteck ist eine (geometrische) Form • Ein Kreis ist eine (geometrische) Form

Vererbung

2 Programmieren in Java

Rectangle

width: float

height: float

Form

origin: Point

Circle

radius: float

Point

x: float

y: float

Vererbung


• Sprachgebrauch: • Elternklasse: Klasse von der geerbt wird • Kindklasse: Alle von einer Elternklasse erbenden Klassen

• Eine Kindklasse erbt:

• Alle Attribute der Elternklasse • Alle Methoden der Elternklasse • Alle Konstruktoren der Elternklasse

• Zugriff auf Elemente (Attribut, Methode, Konstruktor) zur Laufzeit:

• Ist das Element in der Klasse der aktuellen Instanz definiert? • Falls nein: Ist das Element ein der Elternklasse definiert? • Falls nein: Hat die Elternklasse eine Elternklasse? • Falls ja: Die Hierarchie durchlaufen, bis das Element gefunden wurde

• Ansonsten: Compiler-Fehler

Vererbung in Java



• In Java fängt jede Klassenhierarchie mit der Klasse Object an

• D.h. jede Klasse, die nicht explizit von einer anderen Klasse erbt, erbt von Object, ohne dass dies angegeben werden muss

• Am Beispiel der geometrischen Figuren

Klassenhierarchie in Java


Rectangle

width: float

height: float

Form

origin: Point

Circle

radius: float

Point

x: float

y: float

Object


• Das Schlüsselwort zu Deklaration von Vererbung ist extends

• Java kennt nur einfache Vererbung, • Die Hierarchietiefe ist allerdings beliebig

Vererbung in Java


public class {

}

BEZEICHNER

…

extends KLASSEN-BEZEICHNER

public class Rectangle extends Form {

private float width;

private float height;

}

public class Form {

private Point origin;

}

public class Circle extends Form {

private float radius;

}


• Bei der Erzeugung einer Instanz wird in jeder Hierarchieebene ein Konstruktor ausgeführt • Angenommen die Elternklasse Form hat folgenden Konstruktor

• Damit ist der Default-Konstruktor überschrieben • In erbenden Klassen muss ein Konstruktor explizit aufgerufen werden • Der Aufruf des Eltern-Konstruktors erfolgt über das Schlüsselwort super

• Der Aufruf von super muss dabei immer der erste Satz im Konstruktor sein

Vererbung und Konstruktoren





public Rectangle(Point origin, float width, float height) {

super(origin);

this.width = width;

this.height = height;

}

}

public class Form {


public Form(Point origin) {this.origin = origin;}

}


• Insbesondere

Vererbung und Variablen


public static void main(String[] args) {

Form form;

form = new Rectangle(…);

System.out.println(form); // Rectangle:…

form = new Circle(…);

System.out.println(form); // Circle:…

}

Rectangle rectangle;

rectangle = new Circle(…);

rectangle = new Form(…);

Form

Rectangle

Circle

Rectangle

Circle

Form

Object object;

object = new Circle(…);

object = "Hello World";

object = new Computer(…);

Object

Circle String

Computer


• Die abgeleitete Klasse erbt alle Methoden der Elternklasse

• Damit erben auch alle Instanzen die Funktionalität der Elternklasse

• Die Methode print wurde in Form definiert, kann aber über Instanzen von Rectangle und Circle aufgerufen werden

Vererbung und Methoden


public static void main(String[] args) {

Form form;

form = new Rectangle(new Point(50.0f, 75.0f), 2.0f, 8.0f);

form.print(); // (50.0f, 75.0f)

form = new Circle(Rectangle(new Point(1.0f, 0.0f), 16.0f);

form.print(); // (1.0f, 0.0f)

}

public class Form {


public Form(Point origin) {this.origin = origin;}

public void print() {

System.out.print(this.origin);

}

}


• Jede Methode kann nur auf die Instanzattribute und -methoden der eigenen oder der Elternklasse zugreifen • Die print-Methode von Form kennt daher nur das Attribut origin

• Es ist möglich Methoden der Elternklasse zu überschreiben:

Vererbung und Methoden (II)





…


System.out.print("width:" + this.width + ", height:" + this.height);

}

}

Form form;


form.print(); // „print“ von Rectangle: width: 2.0f, height: 8.0f

form = new Circle(Rectangle(new Point(1.0f, 0.0f), 16.0f);

form.print(); // „print“ von Form: (1.0f, 0.0f)


• Der Rectangle-Aufruf von print liefert keine Angabe zu origin mehr • Mit super kann nicht nur ein Konstruktor aufgerufen werden

• Auch der Zugriff auf Methoden und Attribute der Elternklasse ist damit möglich

• Der Zugriff auf origin innerhalb von Rectangle scheitert allerdings

Vererbung und Methoden (III)



…


super.print();

System.out.print("width:" + this.width + ", height:" + this.height);

}

}

Form form;


form.print(); // Rectangle::print (50.0f, 75.0f) width: 2.0f, height: 8.0f

form = new Circle(new Point(1.0f, 0.0f), 16.0f);

form.print(); // Form::print (1.0f, 0.0f)

System.out.print("origin:" + super.origin + ", width:" + this.width + ", height:" + this.height);


• Es gibt vier Sichtbarkeitsmodifiktoren für Attribute und Methoden • public: Zugriff von „überall“ • protected: Zugriff innerhalb des Packages und bei Vererbung • [keine Angabe]: Zugriff innerhalb des Packages („package private“) • private: Zugriff nur innerhalb der eigenen Klasse/Instanz

• Das erklärt das Scheitern des Zugriffes im vorherigen Beispiel

• Das Attribut origin ist nur innerhalb von Form verwendbar

• Es gibt zwei Sichtbarkeitsmodifikatoren für Klassen:

• public: Zugriff von „überall“ • [keine Angabe]: Zugriff innerhalb des Packages („package private“)

• Insbesondere: Nur die mit dem Dateinamen übereinstimmende Klasse kann public sein

Sichtbarkeit


public class Form {


…

}


Vererbung und this


System.out.println(

new Form(…)

);

System.out.println(

new Rectangle(…)

);

System.out.println(

new Circle(…)

);

Form

Rectangle width: … height: …

Circle

Form

Circle

toString: String

Rectangle

toString: String

public class Form {

..

public String toString() {

return this.getClass().getSimpleName();

}

}

public class Rectangle {

…


return super.toString()

+ " width:" + this.width

+ " height:" + this.height;

}

}


• Jede geometrische Figur hat einen Flächeninhalt • Im Sinne der Objektorientierung wäre dies eine Methode der Klasse Form

• Ein Flächeninhalt ist abhängig vom Typ der Form (Kreis, Rechteck, etc.) • Die Klasse Form kennt ihre allerdings Kindklassen nicht • Die Methode getArea kann für Form demnach nicht sinnig definiert werden

• In solchen Fällen (Zugehörigkeit eindeutig, Implementierung nicht) definiert man eine Methode als abstrakt

• Sobald eine Methode abstract ist, muss auch die Klasse abstract sein

Abstrakte Klassen/Methoden


public class Form {

public double getArea() …

}

optional

SICHTBARKEIT RÜCKGABETYP ( ); DATENTYP BEZEICHNER PARAM-

BEZEICHNER

, … abstract

public abstract double getArea();

public abstract class Form … SICHTBARKEIT abstract KLASSEN-BEZEICHNER … class


• Es kann keine Instanz einer abstrakten Klasse erstellt werden • Eine abstrakte Methode hat keinen Methodenrumpf (Implementierung) • Lediglich die Signatur wird angegeben • Nur Instanz-Methoden können abstrakt sein • Eine erbende Klasse muss entweder

• eine Implementierung der Methode angeben

• oder selbst wieder als abstract definiert werden

Abstrakte Klassen/Methoden


public class Circle extends Form {

public final static double PI = 3.1415926;

…

public double getArea() {

return this.radius * this.radius * Circle.PI;

}

}

Form

Circle

public abstract class UnknownForm extends Form {

…

}

Form

UnknownForm


• Die getArea()-Methode ist den Zugriffsrechten entsprechend aufrufbar

• Demnach auch von der definierenden Klasse selbst

• Warum compiliert dies? • Da Form abstract ist kann es keine Instanz der Klasse Form geben • toString kann nur von Instanzen aufgerufen werden

• D.h. es existiert eine Klasse in der Hierarchie des aufrufenden Objektes, die getArea implementiert

• Welche Klasse dies ist, steht erst zur Laufzeit fest • Dieses Verhalten nennt sich „spätes Binden“ (auch: „dynamisches Binden“) • Abstrakte Methode werden daher als „polymorph“ bezeichnet

Polymorphie


public abstract class Form {

public abstract double getArea();


return this.getClass().getSimpleName() + " Fläche=>" + this.getArea();

}

}


• Ein Interface ist eine abstrakte Klasse, in der alle Methoden • public sind (per default, eine Sichtbarkeit muss nicht angegeben werden) • abstrakt sind (per default, abstract muss nicht angegeben werden)

• Eine Klasse „implementiert“ ein Interface • Die Beziehung wird nicht per extends sondern mit implements angegeben

Interfaces


public interface Identifiable {

String getMAC();

}

SICHTBARKEIT interface BEZEICHNER {

}

RÜCKGABETYP ( ); DATENTYP BEZEICHNER PARAM-

BEZEICHNER

, …

public class {

}

BEZEICHNER

…

implements INTERFACE-BEZEICHNER


• Innerhalb eines Interfaces können keine Instanz-Attribute definiert werden • Klassenattribute sind möglich • Eine implementierende Klasse muss entweder alle im Interface angegebenen Methoden definieren oder als abstract deklariert werden

• Eine Klasse kann beliebig viele Interfaces implementieren (Aufzählung per ,) • Dadurch gewinnt man eine Art Pseudo-Mehrfachvererbung • Es können Variablen vom Typ eines Interfaces definiert werden:

Interfaces (II)


public class Computer implements Identifiable {

private String id;

public Computer(String id) { this.id = id;}

public String getId() {return this.id;}

…

}

Identifiable identifiable = new Computer("0080.41ae.fd7e");

System.out.print(identifiable.getId());


• Vererbung, Interfaces und abstrakte Klassen sollen nun auf das Computer-Beispiel übertragen werden

• Nicht immer ist Vererbung so offensichtlich wie im Formen-Beispiel • Da Vererbung immer eine „ist ein“ Beziehung abbilden soll, müssen zuerst Gemeinsamkeiten identifiziert werden • Sowohl Grafik- als auch Soundkarte sind Platinen

mit einem Prozessor

Anwendung


Processor

GraphicsCard Soundcard

CircuitBoard


• Der Computer hat ebenfalls eine Platine (Mainboard) mit Prozessor • Sowohl Computer als auch die Grafikkarte verfügen über RAM

Anwendung



CircuitBoard

Processor

Computer

RAMModule


• Sound- ,Grafikkarte und RAM-Module werden auf das Mainboard „gesteckt“ • Der Entwurf wirft mindestens zwei Fragen auf:

• Soll die RAM-Gemeinsamkeit von Computer und GraphicsCard zu einer

neuen Elternklassen führen? • Wie wird die Mehrfachvererbung für Sound- und Grafikkarte aufgelöst?

Anwendung



CircuitBoard

Processor Computer

RAMModule

Pluggable


• Soll die RAM-Gemeinsamkeit von Computer und GraphicsCard zu einer

neuen Elternklassen führen? • Das wäre durchaus denk- und machbar • Allerdings kann man sich die Klasse sparen, wenn man die RAM-Abhängigkeit auf die Tatsache reduzieren, dass RAMModule Pluggable ist und damit bereits zum CircuitBoard gehört • GraphicsCard erbt von CircuitBoard und Computer besitzt eines • CircuitBoard muss demnach eine beliebige Anzahl von Pluggable-

Instanzen verwalten

• Die Verwaltung der Pluggable-Instanz wird immer gleich aussehen und kann daher in der CircuitBoard-Klasse implementiert werden

• Das beantwortet auch schon Frage zwei: • Pluggable muss ein Interface werden

Anwendung


CircuitBoard Pluggable 1 n


• Auch Processor kann als Pluggable betrachtet werden • Daneben existierte im Ursprungsentwurf noch die Klasse Connector, die ebenfalls als Pluggable umsetzbar ist

• Die Steckplätze einer Platine sind begrenzt • Zudem Unterscheiden sich die einzelnen Steckplätze

• Es gibt nur einen Prozessor • Allerdings bspw. zwei RAM-Steckplätze

• Pluggable-Instanzen unterscheiden sich daher anhand ihres „Steckplatzes“

Anwendung


<<interface>>

Pluggable

GraphicsCard Soundcard RAMModule

Connector Processor ? getSlot();


• Der Steckplatz wird ein Instanzattribut der Pluggable-Klassen sein

• D.h. „Steckplatz“ muss typisiert werden • Klassisch bieten sich zwei Möglichkeiten an: String oder int

• Die möglichen Werte sollten als konstante Klassenattribute definieren werden • Da Klassenattribute in Interfaces zulässig sind, bietet sich Pluggable an

• Die Zuteilung eines Wertes erfolgt über den Attributnamen

• Dies hat zum Vorteil:

• Da der Attribut-Name anstelle des Wertes benutzt wird und dieser vom Compiler auf Existenz überprüft wird, keine Flüchtigkeitsfehler

• Im int-Fall: Attributname „sprechender“ als eine Zahl

Typisierung des Steckplatzes


public interface Pluggable {

public static final String PROCESSOR = "PROCESSOR";

public static final String RAM = "RAM";

…

}


public static final int PROCESSOR = 0;

public static final int RAM = 1;

…

}

String slot = Pluggable.PROCESSOR; int slot = Pluggable.PROCESSOR;


• Der Ansatz einen bestimmten Satz an Werten über konstante Klassenattribute zu benennen hat allerdings klare Nachteile:

• Da der Typ der Attribute int oder String ist, kann jeder beliebige String oder int-Wert eingesetzt werden

• Der Compiler hat keine Möglichkeit zu überprüfen, ob ein angegebener Wert valide ist

• Die Werte sind nicht abgeschlossen gegenüber Operatoren

• Man könnte meinen, dass dies entweder heißt, beide Slots sind zulässig oder dass ein kombinierter Slot gemeint ist

• Mit Java (1.)5 wurden Enums in den Java-Sprachumfang eingeführt, die

Aufzählungen wie oben konsistent abbilden

Typisierung des Steckplatzes


String slot = "SUPPE"; int slot = -1111;

String slot = Pluggable.PROCESSOR + Pluggable.RAM;


Enums

• Enums sind eine Aufzählung von int-Werten, wobei jedes Element einem

bestimmten Namen zugeordnet ist • In Java werden Enums über das Schlüsselwort enum definiert und sind

spezielle Klassen und damit jeder Enum-Wert ein Objekt

• Lediglich die Namen werden angegeben und werden per Konvention komplett in Großbuchstaben notiert (analog zu konstanten Klassenattributen) • Die Werte werden konsekutiv angefangen bei 0 einem int-Wert zugeordnet • Ein Zugriff erfolgt über die Dereferenzierung des Klassennamens:


Slot.PROCESSOR

SICHTBARKEIT KLASSEN-BEZEICHNER { enum

}

ENUM-BEZEICHNER ,

…

public enum Slot {

PROCESSOR,

RAM,

…

}


Enums (2)

• Über die Methoden ordinal() und name() kann die zugordnete

Ordnungszahl sowie der Name eines Enums abgefragt werden

• Enums können in switch-Anweisungen genutzt werden:

• Achtung: Im Gegensatz zum „normalen“ Zugriff wird in der case-

Anweisung nur der Enum-Name angeben, keine explizite Dereferenzierung


Slot slot = Slot.PROCESSOR;

…

System.out.print("Das Enum " + slot.name() + " hat die Ordnungszahl " + slot.ordinal());

// Da Enum PROCESSOR hat die Ordnungszahl 0

switch (slot) {

case PROCESSOR: …

case RAM: …

case …

default: …

}


Inner-Class

• Damit kann der Steckplatz nun über eine Enum-Klasse abgebildet werden • Enum-Klassen können in einer eigenen Java-Datei abgelegt werden

• Das Slot-Enum existiert allerdings nur im direkten Zusammenhang mit

dem Pluggable-Interface • Um eine solche Abhängigkeit abzubilden bietet Java die Möglichkeit Klassen/Interfaces innerhalb von Klassen/Interfaces zu definieren


MODIFIKATOREN KLASSEN-BEZEICHNER { class|enum

}

…

MODIFIKATOREN

}

…

KLASSEN-BEZEICHNER { class|enum


public static enum Slot {

PROCESSOR,

RAM,

}

…

}


Inner-Class

• Der Zugriff auf innere Klassen erfolgt analog zu Klassenattributen über den umschließenden Klassennamen

• Nur bei inneren Klassen kann der Modifikator static genutzt werden:

• Innerhalb eines Interfaces sind alle inneren Klassen automatisch static

• Geeignete Sichtbarkeit vorausgesetzt können von außen nur Instanzen von statischen inneren Klassen erzeugt werden:


Pluggable.Slot slot = Pluggable.Slot.PROCESSOR;

public class GraphicsCard {

public static class Resolution {

int width;

int height;

…

}

…

}


public class Resolution {

int width;

int height;

…

}

…

}

GraphicsCard.Resolution resolution = new GraphicsCard.Resolution(…);

GraphicsCard.Resolution resolution = new GraphicsCard.Resolution(…); // Resolution nicht statisch

// Resolution statisch


Inner-Class

• Instanzen nicht statischer innerer Klassen können nur innerhalb von Instanzen der umschließenden Klasse erzeugt werden:

• Jede Instanz einer nicht statischen inneren Klasse hat automatisch Zugriff auf die Instanz, die sie erzeugt hat

• Damit kann die Instanz auch auf alle Attribute und Methoden der erzeugenden Instanz zugreifen


GraphicsCard card = new GraphicsCard(…);

GraphicsCard.Resolution resolution = card.createResolution(1024, 920);


public class Resolution {…}

…

public Resolution createResolution(int width, int height) {

return new Resolution(width, height);

}

}

public class Resolution {

public GraphicsCard getCard() {

return GraphicsCard.this;

}

}


• Mit dem Slot-Enum können Pluggable-Instanzen nun einem Steckplatz auf

der Platine zugeordnet werden • Die Anzahl Steckplätze eines bestimmten Typs sind begrenzt • Die Anzahl kann bspw. im Konstruktor des CircuitBoards festgelegt werden • Nun benötigt CircuitBoard eine Methode um Pluggable-Instanzen „auf die

Platine zu stecken“

• Die Methode muss sich die Zuordnung des Steckplatzes merken • Zudem muss sie überprüfen, ob überhaupt noch ein Steckplatz frei ist • Schlägt diese Überprüfung fehlt, wurde bisher die Ausführung der Methode durch ein return beendet

• Semantisch bedeutet dies, dass die Methode erfolgreich ausgeführt wurde • Die Methode sollte eigentlich signalisieren, dass das Stecken fehlschlug

Anwendung


1 n

<<interface>>

Pluggable

Slot getSlot();

CircuitBoard

plugin(Pluggable pluggable): void


• Mit den bisherigen Mitteln kann das Fehlschlagen einer Ausführung durch Codierung in der Rückgabe umgesetzt werden

• Das ist auch durchaus ein nutzbarer Ansatz, allerdings • Was wenn die Methode eine Rückgabe liefern soll, die für die Fehlercodierung ungeeignet ist? • Ein „Nutzer“ der Methode kann die Rückgabe ignorieren, so dass unter Umständen eine nötige Fehlerbehandlung überhaupt nicht durchgeführt wird

Fehlerbehandlung durch Rückgabewerte


public class CircuitBoard {

…

public boolean plugin(Pluggable pluggable) {

if (!slotAvailableFor(pluggable.getSlot())) {

return false;

}

return true;

}

}

public class CircuitBoard {

…

public Pluggable plugin(Pluggable pluggable) {


return null;

}

return pluggable;

}

}


• Java bietet mit Exceptions eine alternative Möglichkeit zur Fehlerbehandlung • Die Ausführung einer Methode kann jederzeit durch das „Werfen“ einer Exception beendet werden • Methoden, die durch eine Exception abgebrochen werden könnten, müssen diese in ihrer Signatur nach dem Schlüsselwort throws angeben

• ConfigurationException ist selbstdefinierte Klasse, die von Exception

erbt, d.h. Exceptions sind Objekte • Alle Kindklassen von Exception können nach throws angegeben werden

• Innerhalb der Methode muss im Fehlerfall eine Instanz der Klasse erzeugt und mittels throw geworfen werden:

Fehlerbehandlung durch Exceptions


public void plugin(Pluggable pluggable) throws ConfigurationException{…}

MODIFIKATOREN RÜCKGABETYP ( BEZEICHNER … throws } EXCEPTION-TYP , … ;


throw new ConfigurationException("FEHLERMELDUNG");

}


• Eine Methode, die eventuelle Fehler durch Exceptions signalisiert kann nicht mehr einfach unbedacht aufgerufen werden • Sie muss durch einen sogenannten try-catch-Block umschlossen werden



{ try

}

…

AUFRUF EINER METHODE, DIE MIT THROWS DEFINIERT WURDE

…

catch ( ) EXCEPTION-TYP BEZEICHNER_1 {

}

FEHLERBEHANDLUNG

catch ( ) EXCEPTION-TYP BEZEICHNER_N { } …

CircuitBoard board = …;

Pluggable pluggable = …;

try {

…

board.plugin(pluggable);

…

}

catch (ConfigurationException e) {

System.out.println(

e.getMessage()

);

}


• In einem try-catch Block können mehrere Anweisung ausgeführt werden

• Führt eine Anweisung zum Fehler wird keine der nachfolgenden ausgeführt • Jede dieser Anweisung kann das Schmeißen diverser Exceptions signalisieren • Für jeden Exception-Typ kann ein catch-Block angegeben werden • Es müssen alle potentiellen Exceptions durch catch abgefangen werden • Ein catch-Block kann mehrere Exception-Typen abdecken:

• Entweder durch die Angabe eines übergeordneten Exception-Typs

• Oder durch Angabe mehrerer Typen:

• Jede Exception darf allerdings nur einmal durch einen catch-Block

behandelt werden



try {

…

}

catch (Exception e) {…}

try {

…

}

catch (ExceptionTyp_1 | ExceptionTyp_2 e) {…}


• Angenommen ein Aufruf innerhalb des try-Blockes führt zu einem illegalen

Programmzustand • Der catch-Block sollte dann dazu genutzt werden, diesen illegalen Zustand

wieder aufzulösen • Ist dies in der aufrufenden Methode nicht möglich, so kann die Exception an die nächste Methode weitergereicht werden:

• Dazu muss auch die aufrufende Methode die möglichen Exceptions per throws deklarieren • Falls die Methode alle Exceptions definiert, die im try-Teil potentiell auftreten könnten, so kann try-catch in der Methode weggelassen werden

• Alternative kann die Methode eine eigene Exception anderen Typs schmeißen, dann ist allerdings ein try-catch für den plugin-Aufruf nötig



public void test(CircuitBoard board) throws ConfigurationException{

…



…

}


• Neben dem catch-Block kann optional noch ein finally-Block angegeben

werden • Der Code innerhalb des finally-Blockes wird in jedem Fall ausgeführt:

• Entweder nach erfolgreicher Ausführung aller im try-Block befindlichen

Anweisungen • Oder nachdem ein Fehler durch einen catch-Block behandelt wurde



CircuitBoard board = …;


try {

…


…

}

catch (ConfigurationException e) {

System.out.println(e.getMessage() );

}

finally {

System.out.println("FINALLY" );

}

// Freier Slot

FINALLY

// Kein freier Slot

Slot not available for pluggable object

FINALLY

Einführung in die Objektorientierung Enums, innere-Klassen ... · •Jede Methode kann nur auf die...

Documents

Transcript of Einführung in die Objektorientierung Enums, innere-Klassen ... · •Jede Methode kann nur auf die...