Extend, Implement, Abstract

[Michilee]

Hi,

ich hoffe, dass ist meine letzte Frage für heute oder die Tage.
Hatte mir in Jave dies notiert:

extend: Alle Methode von abgeleiteten Klasse nutzbar, überschreibbar, Variablen nutzbar
interface: Alle Methoden von Interface müssen implementiert werden. Keine fertigen Methoden nutzbar (Verstehe ich nicht??). Variablen nutzbar
abtract: Sobald eine Methode abstract ganze Klasse abstract. Variablen nutzbar. Abstracte Methoden müssen implementiert werden, die restlichen nicht und können direkt genutzt werden.

1. Sind Fehler in den Notizen oben? An einer Stelle habe ich Fragezeichen

2. Wie nutze ich nochmal von anderen Klassen private oder public (oder final) Variablen? Ohne sie andere Klasse zu implementieren, oder von Ihr abgeleitet zu sein, wird man womöglich die Variablenicht nutzen können ne?

3. Wo ich so meine Probleme habe, wenn es zum Beispiel heißt, dass wenn ich eine Klasse geschrieben habe und sie seriazible sein muss, dass ich einfach meine Klasse von seriazible ableite. Was bringt das? Vor allem, wenn ich nicht weiß, was die Klasse macht, von der ich abgeleitet worden bin.

Grüße
Michi

[Richard]

Hallo Michilee,

extend: Alle Methode von abgeleiteten Klasse nutzbar, überschreibbar, Variablen nutzbar

Nicht alle, sondern nur die mit einer Sichtbarkeit >= protected.

interface: Alle Methoden von Interface müssen implementiert werden. Keine fertigen Methoden nutzbar (Verstehe ich nicht??). Variablen nutzbar

In einem Interface werden Methoden definiert, aber nicht implementiert. Die Implementierung dieser Methoden übernimmt die Klasse, die das Interface mit dem Schlüsselwort implements implementiert.

abtract: Sobald eine Methode abstract ganze Klasse abstract. Variablen nutzbar. Abstracte Methoden müssen implementiert werden, die restlichen nicht und können direkt genutzt werden.

Soweit richtig.

2. Wie nutze ich nochmal von anderen Klassen private oder public (oder final) Variablen? Ohne sie andere Klasse zu implementieren, oder von Ihr abgeleitet zu sein, wird man womöglich die Variablenicht nutzen können ne?

Private Variablen sind außerhalb der Klasse nicht sichtbar. Ist eine Variable oder Methode als protected deklariert, kannst du darauf nur innerhalb der Vererbungshierarchie zugreifen. Öffentliche bzw. paketsichtbare Variablen und Methoden rufst du auf einem Objekt, bzw. statische Variablen/Methoden auf der Klasse auf.

3. Wo ich so meine Probleme habe, wenn es zum Beispiel heißt, dass wenn ich eine Klasse geschrieben habe und sie seriazible sein muss, dass ich einfach meine Klasse von seriazible ableite. Was bringt das? Vor allem, wenn ich nicht weiß, was die Klasse macht, von der ich abgeleitet worden bin.

Wenn die Klasse ein Interface implementiert, stellt sie damit nach außen hin sicher, dass sie bestimmte Fähigkeiten und auch gleichzeitig einen bestimmten Typ hat, da sie ja das Interface und damit dessen sämtliche Methoden implementiert.

Serializable ist ein schlechtes Beispiel, da es genau keine Methoden vorschreibt. Sieh dir beispielsweise das Interface java.lang.Comparable an. Es schreibt eine Methode compareTo() vor, mit deren Hilfe eine Ordnungsrelation auf der Klasse definiert wird. Die Objekte dieser Klasse sind dann also vergleichbar (engl. comparable). Ein Benutzer dieser Klasse sieht nun von außen, dass sie das Interface Comparable implementiert, und kann sich somit darauf verlassen, dass er auf dieser Klasse die compareTo()-Methode aufrufen kann. Außerdem kann jeder Methode, die ein Comparable als Parameter erwartet, nun auch ein Objekt deiner Klasse übergeben werden (Stichwort Polymorphie).

Grüße
Richard

[Rouven]

Hello,

Serializable ist ein schlechtes Beispiel, da es genau keine Methoden vorschreibt.

man kann das Interface dennoch erklären - Michilee, stelle es dir vor wie ein Versprechen: durch die Angabe "ich implementiere Serializable" verspreche ich dir, wenn du mich in der vorgesehenen Art speicherst und danach wieder lädst funktioniere ich weiter. Das kannst du natürlich nur, wenn du dir alle relevanten Informationen selbst merkst, also deinen gesamten Zustand in dir selbst trägst, nicht aber von anderen abhängig bist.

MfG
Rouven

[Michilee]

Hi Richard,
vielen dank für die echt sehr ausfürliche und verständliche antwort.

interface: Alle Methoden von Interface müssen implementiert werden. Keine fertigen Methoden nutzbar (Verstehe ich nicht??). Variablen nutzbar

In einem Interface werden Methoden definiert, aber nicht implementiert. Die Implementierung dieser Methoden übernimmt die Klasse, die das Interface mit dem Schlüsselwort implements implementiert.

oki doki, d.h., dass in einem interface es überhaupt keine fertigen methoden geben darf, bzw. kann, die man dann später nutzt?

Private Variablen sind außerhalb der Klasse nicht sichtbar. Ist eine Variable oder Methode als protected deklariert, kannst du darauf nur innerhalb der Vererbungshierarchie zugreifen. Öffentliche bzw. paketsichtbare Variablen und Methoden rufst du auf einem Objekt, bzw. statische Variablen/Methoden auf der Klasse auf.

Öffentlich oder Paketsichbare (?) rufe ich dann direkt einfach auf?

Klassenname.variable?

Es gibt ja manchmal static final variablen, wo man dann den Wert ablesen kann. Hatte ich in manchen Codes auch gesehen, ohne, dass man glaube ich ein Objekt von der Klasse bildete. (Hatte aber den Code nicht geprüft, ob der lief/funktionierte)

Serializable ist ein schlechtes Beispiel, da es genau keine Methoden vorschreibt.

Dann hat die implementierung irgendwie wenig Sinn?

Sieh dir beispielsweise das Interface java.lang.Comparable an. Es schreibt eine Methode compareTo() vor, mit deren Hilfe eine Ordnungsrelation auf der Klasse definiert wird.

D.h., wenn mir ein Interface eine Methode etwas vorschreibt, dann müsste ich auch Wissen (nachschauen), was in der zu implementierte Methode gemacht werden muss/soll.

Die Objekte dieser Klasse sind dann also vergleichbar (engl. comparable). Ein Benutzer dieser Klasse sieht nun von außen, dass sie das Interface Comparable implementiert, und kann sich somit darauf verlassen, dass er auf dieser Klasse die compareTo()-Methode aufrufen kann.

Oki doki, vielen Dank.

Außerdem kann jeder Methode, die ein Comparable als Parameter erwartet, nun auch ein Objekt deiner Klasse übergeben werden (Stichwort Polymorphie).

Ja, ich muss mir dann noch anschauen, wie das mit dem Objektbilden war, wenn abgeleitet wurde oder interfaces genutzt wurde.

Interface= Steuergerät
Extend= Auto
MeineKlasse = VW
Abtract= Austattung

Ich hatte dann auch gesehen, dass man da ganz verschieden Objekte Bilden konnte.

Auto a= new Auto()
Auto a = new VW()

Von abtract konnte man glaub kein Objekt bilden, aber von Interface schon.

Das was Du dan oben mit Polymorphie meinst, war, wenn ich meine Klasse als Comerable übergebe, welches aber als Mutter ein Objekt hat, was... ah, ich schau mir das nochmal genau an, bevor ich hier nen schrott schreibe ;)

grüße

[Richard]

Hallo Michilee,

In einem Interface werden Methoden definiert, aber nicht implementiert. Die Implementierung dieser Methoden übernimmt die Klasse, die das Interface mit dem Schlüsselwort implements implementiert.

oki doki, d.h., dass in einem interface es überhaupt keine fertigen methoden geben darf, bzw. kann, die man dann später nutzt?

Richtig, ein Interface definiert nur die minimale öffentliche Schnittstelle die eine implementierende Klasse hat.

Öffentlich oder Paketsichbare (?) rufe ich dann direkt einfach auf?

Klassenname.variable?

Ja, wenn sie statisch sind. Andernfalls erzeugst du zunächst ein Objekt der Klasse und rufst auf diesem die Variablen/Methoden auf.

Es gibt ja manchmal static final variablen, wo man dann den Wert ablesen kann. Hatte ich in manchen Codes auch gesehen, ohne, dass man glaube ich ein Objekt von der Klasse bildete. (Hatte aber den Code nicht geprüft, ob der lief/funktionierte)

Richtig, statische Variablen werden ohne konkretes Objekt aufgerufen. Sie haben daher unabhängig von Objekten der Klasse immer denselben Wert, weshalb man sie bisweilen mit globalen Variablen gleichsetzt. Sind sie darüberhinaus final, können sie nach einmaliger Wertzuweisung nicht mehr verändert werden. Es handelt sich dann um globale Konstanten.

Serializable ist ein schlechtes Beispiel, da es genau keine Methoden vorschreibt.

Dann hat die implementierung irgendwie wenig Sinn?

Doch, siehe Rouvens Antwort. Jede Klasse, die Serializable implementiert, ist dann selbst auch von diesem Typ und kann überall, wo ein Serializable als Datentyp gefordert wird, übergeben werden.

D.h., wenn mir ein Interface eine Methode etwas vorschreibt, dann müsste ich auch Wissen (nachschauen), was in der zu implementierte Methode gemacht werden muss/soll.

Ja, im Idealfall ist das bereits durch Rückgabewert in Kombination mit dem Methodennamen intuitiv ersichtlich.

Ich hatte dann auch gesehen, dass man da ganz verschieden Objekte Bilden konnte.

Auto a= new Auto()
Auto a = new VW()

Auto und VW sind Klassen, a ist ein Objekt.

Von abtract konnte man glaub kein Objekt bilden, aber von Interface schon.

Man kann von beidem keine Objekte erzeugen.

Grüße
Richard

[Michilee]

Hi Richard und Rouven,
vielen Dank euch beiden. Ja jetzt macht vieles Sinn.

Richtig, statische Variablen werden ohne konkretes Objekt aufgerufen. Sie haben daher unabhängig von Objekten der Klasse immer denselben Wert, weshalb man sie bisweilen mit globalen Variablen gleichsetzt. Sind sie darüberhinaus final, können sie nach einmaliger Wertzuweisung nicht mehr verändert werden. Es handelt sich dann um globale Konstanten.

den wert der static variablen kann ich auch nicht ändern? final ja sowieso nicht.

Doch, siehe Rouvens Antwort. Jede Klasse, die Serializable implementiert, ist dann selbst auch von diesem Typ und kann überall, wo ein Serializable als Datentyp gefordert wird, übergeben werden.

Oki, die eigentlich Frage bzw. mein Grübeln kommt unten noch.
Wenn ich in meiner Klasse extends Seriazible habe, kann ich ja davon ein Objekt mit meiner Klasse erzeugen.

Seriazible b = new MeineKlasse();

Dann wäre der Datentyp Seriazible? Habe ich das richtig verstanden?

Auto a= new Auto()
Auto a = new VW()

Auto und VW sind Klassen, a ist ein Objekt.

Okey, da kann ich meine Problematik besser schildern, wenn ich auf die Begriffe achte.

Also das Objekt a wäre von Datentyp Auto, da meine Klasse VW von Auto abgeleitet ist.

Ich könnte aber genauso
VW a = new VW() machen, obwohl Klasse VW von Klasse Auto (Elternelement?) abgeleitet ist.

Von abtract konnte man glaub kein Objekt bilden, aber von Interface schon.

Man kann von beidem keine Objekte erzeugen.

Siehe oben. Wenn ich das oben mit Seriazible richtig verstanden habe, kann ich von Seriazible nur extends machen, damit ich ein Objekt (also den Datentyp) erzeuge, denn implements Seriazible würde nicht gehen, wenn ich von abtract und Interface kein Objekt bilden darf.
Hoffentlich bin ich da auf dem richtigen weg und nerve euch weniger.

nochmals vielen dank
grüße

[Richard]

Hallo Michilee,

den wert der static variablen kann ich auch nicht ändern? final ja sowieso nicht.

Doch, kannst du. Natürlich nur, wenn die Variable in deinem Kontext gerade sichtbar ist.

Wenn ich in meiner Klasse extends Seriazible habe, kann ich ja davon ein Objekt mit meiner Klasse erzeugen.

Wenn du mit extends von Seralizable erbst, hast du wieder eine Schnittstelle. Willst du das Interface stattdessen implementieren, nutzt du dafür das Schlüsselwort implements.

Seriazible b = new MeineKlasse();

Dann wäre der Datentyp Seriazible? Habe ich das richtig verstanden?

b hat dann mindestens die Typen Serializable, MeineKlasse und Object. Und alle weiteren, die sich in der Vererbungshierarchie noch zwischen Object und MeineKlasse befinden.

Auto a= new Auto()
Auto a = new VW()

Auto und VW sind Klassen, a ist ein Objekt.

Okey, da kann ich meine Problematik besser schildern, wenn ich auf die Begriffe achte.

Also das Objekt a wäre von Datentyp Auto, da meine Klasse VW von Auto abgeleitet ist.

Es ist auch wichtig, dass der Code oben in ein und derselben Quelldatei nicht kompilierbar ist. In der ersten Zeile wird der Typ bereits auf Auto festgelegt. Du kannst das von a referenzierte Objekt zwar noch ändern, musst dann aber das "Auto" davor weglassen.

Ansonsten gilt, unter der Bedingung das VW von Auto erbt: In Zeile eins ist a vom Typ Auto, in Zeile zwei ist a vom Typ Auto und vom Typ VW. (Und beide Male trivialerweise auch vom Typ Object)

VW a = new VW() machen, obwohl Klasse VW von Klasse Auto (Elternelement?) abgeleitet ist.

Du kannst Objekte von beliebigem Typ erzeugen, unabhängig wovon sie abgeleitet sind.

Siehe oben. Wenn ich das oben mit Seriazible richtig verstanden habe, kann ich von Seriazible nur extends machen, damit ich ein Objekt (also den Datentyp) erzeuge, denn implements Seriazible würde nicht gehen, wenn ich von abtract und Interface kein Objekt bilden darf.

Moment, implements erzeugt dir kein Objekt, sondern zeigt an, dass eine _Klasse_ sämtliche Methoden einer Schnittstelle ebenfalls hat (sonst würde sie nicht durch den Compiler kommen). Von dieser _Klasse_ kannst du dann Objekte erzeugen, die automatisch auch den Typ Serializable haben.

Grüße
Richard

P.S.: Programmieren lernt man nur durch Programmieren.

[Michilee]

Hi,

den wert der static variablen kann ich auch nicht ändern? final ja sowieso nicht.

Doch, kannst du. Natürlich nur, wenn die Variable in deinem Kontext gerade sichtbar ist.

Wie du in deinem P.S geschrieben hast, probiere ich die Tage dann ein paar Testscripte zu schreiben und alles zu verstehen und dann erst wieder mit Fragen zu kommen. Jetzt versuche ich es mit Abschlussfragen, so dass sich dieser Thread nicht in die Länger zieht :-)

Also ohne ein Objekt zu bilden kann ich die static Variable ändern. Bis dahin klar. Und das versuche ich die Tage auch. Ich teste dann, (da die Klassen ja für eine Webanwendung ist), was passiert, wenn eine Klasse auf eine static-Variable zugreift und ändert und später eine andere Klasse die static-Variable aufruft, welcher Wert drin ist. (Weil die Kompilierte-Klasse kann man ja nicht ändern)

Seriazible b = new MeineKlasse();

Dann wäre der Datentyp Seriazible? Habe ich das richtig verstanden?

b hat dann mindestens die Typen Serializable, MeineKlasse und Object. Und alle weiteren, die sich in der Vererbungshierarchie noch zwischen Object und MeineKlasse befinden.

Ah ok, das Datentyp bezieht sich nicht immer auf das was vor dem beim Objektbilden steht (im oberen Fall Seriazible) sondern, das Objekt hat mehrere (Daten?)Typen.

Das Teste ich dann auch, zwischen extens und implements. Wenn ich Seriazible implements nehme, dann dürfte

Seriazible b = meineKlasse() nicht gehen.

Oder ich verwechsle gerade das Objekt bilden, so dass new Seriazible nicht geht.

Auto a= new Auto()
Auto a = new VW()

Auto und VW sind Klassen, a ist ein Objekt.

Okey, da kann ich meine Problematik besser schildern, wenn ich auf die Begriffe achte.

Also das Objekt a wäre von Datentyp Auto, da meine Klasse VW von Auto abgeleitet ist.

Es ist auch wichtig, dass der Code oben in ein und derselben Quelldatei nicht kompilierbar ist. In der ersten Zeile wird der Typ bereits auf Auto festgelegt. Du kannst das von a referenzierte Objekt zwar noch ändern, musst dann aber das "Auto" davor weglassen.

ah, ok, hab zweimal das Objekt a benannt. Sollte entweder oder sein, dass praktisch beides möglich ist.

Auto d= new Auto()
Auto e = new VW()

Ansonsten gilt, unter der Bedingung das VW von Auto erbt: In Zeile eins ist a vom Typ Auto, in Zeile zwei ist a vom Typ Auto und vom Typ VW. (Und beide Male trivialerweise auch vom Typ Object)

oki doki, das letztere ist beides.

VW f = new VW() wäre jedoch vom Typ her auch beides, also Auto und VW, da er ja geerbt wird oder ignoiert er das? Womöglich geht das nicht. Und natürlich noch vom Typ "Objekt".

Moment, implements erzeugt dir kein Objekt, sondern zeigt an, dass eine _Klasse_ sämtliche Methoden einer Schnittstelle ebenfalls hat (sonst würde sie nicht durch den Compiler kommen). Von dieser _Klasse_ kannst du dann Objekte erzeugen, die automatisch auch den Typ Serializable haben.

Oki, mit Objektbilden, habe ich dann etwas falsch verstanden. Hab als Objekt immer das bezeichnet, was vor dem = steht.

Seriazible a = new meineKlasse();

Das Objekt was ich bilde ist ja meineKlasse und Serizible (die Klasse) der Typ und meineKlasse.
Und da ich von Implements kein Objekt bilden kann, geht aber evtl. dies, wenn ich zum Beispiel Seriazible implements gemacht habe.

Seriazible a = new meineKlasse()

also
ImplementiereKlasse b = meineKlasse()

P.S.: Programmieren lernt man nur durch Programmieren.

ja ich merke, da muss ich mich schnell ranmachen. danke nochmals.

[Richard]

Hallo Michilee,

Also ohne ein Objekt zu bilden kann ich die static Variable ändern. Bis dahin klar. Und das versuche ich die Tage auch. Ich teste dann, (da die Klassen ja für eine Webanwendung ist), was passiert, wenn eine Klasse auf eine static-Variable zugreift und ändert und später eine andere Klasse die static-Variable aufruft, welcher Wert drin ist. (Weil die Kompilierte-Klasse kann man ja nicht ändern)

Nachdem das Programm einmal beendet wurde, existieren die Objekte natürlich nicht mehr. Beim nächsten Programmstart sind die geänderten Werte also nicht mehr da. Alle Angaben bzgl. des Änderns von Variablenwerten bezogen sich auf genau _eine_ Laufzeit des Programms.

Seriazible b = new MeineKlasse();

Dann wäre der Datentyp Seriazible? Habe ich das richtig verstanden?

Unter anderem, ja.

Ah ok, das Datentyp bezieht sich nicht immer auf das was vor dem beim Objektbilden steht (im oberen Fall Seriazible) sondern, das Objekt hat mehrere (Daten?)Typen.

Richtig, das Objekt ist polymorph.

Das Teste ich dann auch, zwischen extens und implements. Wenn ich Seriazible implements nehme, dann dürfte

Seriazible b = meineKlasse() nicht gehen.

Das wird nur gehen, wenn die Methode meineKlasse() eine konkrete Implementierung von Serializable zurückgibt. Wahrscheinlich meintest du aber den Konstruktor. Um den aufzurufen, musst du das Schlüsselwort new verwenden. Wenn die Klasse meineKlasse Serializable implementiert, ist obiges Konstrukt richtig (abgesehen vom fehlenden new natürlich).

Oder ich verwechsle gerade das Objekt bilden, so dass new Seriazible nicht geht.

new Serializable() wird in der Tat nicht funktionieren.

VW f = new VW() wäre jedoch vom Typ her auch beides, also Auto und VW, da er ja geerbt wird oder ignoiert er das? Womöglich geht das nicht. Und natürlich noch vom Typ "Objekt".

Ein Objekt ist immer Typ von:
1. der Klasse, von der es erzeugt wurde,
2. allen Klassen, die in der Vererbungshierarchie über der Klasse stehen, von der das Objekt erzeugt wurde, und
3. allen Schnittstellen, die von irgendeiner Klasse, die in der Vererbungshierarchie über der Klasse steht, von der das Objekt erzeugt wurde, inklusive der Klasse selbst, implementiert wurden.

Oki, mit Objektbilden, habe ich dann etwas falsch verstanden. Hab als Objekt immer das bezeichnet, was vor dem = steht.

Das, was vor dem = steht ist der Variablenname der Variable, die eine Referenz auf das Objekt enthält.

Seriazible a = new meineKlasse();

Das Objekt was ich bilde ist ja meineKlasse und Serizible (die Klasse) der Typ und meineKlasse.

Nein, meineKlasse ist nicht das Objekt, sondern eine Klasse.

Und da ich von Implements kein Objekt bilden kann, geht aber evtl. dies, wenn ich zum Beispiel Seriazible implements gemacht habe.

Seriazible a = new meineKlasse()

also
ImplementiereKlasse b = meineKlasse()

Überlege dir genau, welche Klasse hier welche Schnittstelle implementieren muss und wie die entsprechenden Passagen im Quellcode aussehen müssen.

Grüße
Richard

[Michilee]

Hi Richard,

Nachdem das Programm einmal beendet wurde, existieren die Objekte natürlich nicht mehr. Beim nächsten Programmstart sind die geänderten Werte also nicht mehr da. Alle Angaben bzgl. des Änderns von Variablenwerten bezogen sich auf genau _eine_ Laufzeit des Programms.

ja danke, das ist mir klar. das erübrigt sich dann auch meine frage, sobald man eine statische Variable von einem anderen Objekt ändert und wiederum ein anderes Objekt auf die statische Variable zugreift, so gilt der Wert, denn das Objekt für die Variable gesetzt hat, natürlich bis die Laufzeit beendet wird.

Bei einem Webprojekt (JSP/Servlets) gäbe es ja nur eine Laufzeit, da das Programm ja "eigentlich" permanent läuft.

Seriazible b = meineKlasse() nicht gehen.

Das wird nur gehen, wenn die Methode meineKlasse() eine konkrete Implementierung von Serializable zurückgibt. Wahrscheinlich meintest du aber den Konstruktor. Um den aufzurufen, musst du das Schlüsselwort new verwenden. Wenn die Klasse meineKlasse Serializable implementiert, ist obiges Konstrukt richtig (abgesehen vom fehlenden new natürlich).

Oh, ja habe das new vergessen. Wo macht es bzw. worin sind die Unterschiede genau, wenn meineKlasse Seriazible implementiert und ich das Objekt mal so:

a) Seriazible a = new meineKlasse()

und einmal

b) meineKlasse b = new meineKlasse() verwende?

Unterschiede dürfte es eher wenig geben?
a) und b) sind von Datentypen beide Objekt, beide meineKlasse und auch beide Seriazible, weil es wie du geschrieben hast, in der Vererbungshierarchie oben steht, auch wenn ich ein Objekt beginnend mit meineKlasse gebildet habe.

(Gelernt habe ich ja bisher, wenn man Seriazible nicht implentiere, sondern davon ableite, dass der Unterschied nur daran besteht, dass man bei der Variante implement kein Objekt von Seriazible verwenden kann)

Ein Objekt ist immer Typ von:

1. der Klasse, von der es erzeugt wurde,
2. allen Klassen, die in der Vererbungshierarchie über der Klasse stehen, von der das Objekt erzeugt wurde, und
3. allen Schnittstellen, die von irgendeiner Klasse, die in der Vererbungshierarchie über der Klasse steht, von der das Objekt erzeugt wurde, inklusive der Klasse selbst, implementiert wurden.

danke, das ist schön erklärt.
Zur Verdeutlichung des Punkt 3.

Nehmen wir an Seriazible implementiert die Klasse Abc.
meineKlasse implementiert Seriazible.

Egal, ob ich das Objekt mit Seriazible a = new meineKlasse() oder meineKlasse b = meineKlasse() bilde, ist das Objekt vom Typ Seriazible, Abc, meineKlasse, Objekt und alles was drüber, bzw. Abc wiederum implementiert usw.

Das, was vor dem = steht ist der Variablenname der Variable, die eine Referenz auf das Objekt enthält.

Nein, meineKlasse ist nicht das Objekt, sondern eine Klasse.

Seriazible xyz = new meineKlasse()

Seriazible ist Klasse
xyz ist Variable bzw. eine Referenz auf das Objekt (bzw. auch der Speicherplatz)
meineKlasse ist auch eine Klasse, bzw. auch der Konstruktor :-)
Das was aus dem ganzen gebildet wird, ist das Objekt mit dem Typ, was wir oben hatten.

Seriazible a = new meineKlasse()

also
ImplementiereKlasse b = meineKlasse()

Überlege dir genau, welche Klasse hier welche Schnittstelle implementieren muss und wie die entsprechenden Passagen im Quellcode aussehen müssen.

Klasse A (A extends X und A implementiert B)
Klasse C (implementiert A)

1. A m = new A (Typ A, B und X)

2. B m = new A (Typ A, B und X)

3. C m = new C (Typ C, B, A und X)

4. A m = new C (Typ C, B, A und X)

5. X m = new X (Typ X)

Morgen abend schreibe ich ein paar ganz simple Scripts und teste extends, implements usw. mal alles durch. Ich will ja auch testen, wenn ich ein Objekt wie in Punkt 3) erstelle und Methoden von X nutze oder von A, bzw. wenn wie sich die drüberstehenden Objektvariablen verhalten. (Bsp. wenn ich die Objektvariablen die in der Vererbungshierarchie drüber stehen, beim Erzeugen von 3) nicht gefüllt habe)

nochmals vielen dank an alle und vor allem an richard.

grüße

[Richard]

Hallo Michilee,

Oh, ja habe das new vergessen. Wo macht es bzw. worin sind die Unterschiede genau, wenn meineKlasse Seriazible implementiert und ich das Objekt mal so:

a) Seriazible a = new meineKlasse()

und einmal

b) meineKlasse b = new meineKlasse() verwende?

Siehe Programmieren gegen Schnittstellen. Wenn du nur die Funktionalität des Interfaces benötigst, gib auch nur das Interface als Typ an. Das bringt enorme Vorteile vor allem in der Erweiterbarkeit.

(Gelernt habe ich ja bisher, wenn man Seriazible nicht implentiere, sondern davon ableite, dass der Unterschied nur daran besteht, dass man bei der Variante implement kein Objekt von Seriazible verwenden kann)

Nein nein, du bringst da einiges durcheinander. Du wirst niemals mit new Serializable() ein Objekt von Serializable erzeugen können. Serializable ist ein Interface. Erben (im Sinne von extends) können davon nur andere Interfaces. Implementieren (im Sinne von implements) können es nur Klassen.

Nehmen wir an Seriazible implementiert die Klasse Abc.

Ein Interface kann keine Klasse implementieren.

Seriazible xyz = new meineKlasse()

Seriazible ist Klasse

Nein, Interface.

Seriazible a = new meineKlasse()

also
ImplementiereKlasse b = meineKlasse()

Überlege dir genau, welche Klasse hier welche Schnittstelle implementieren muss und wie die entsprechenden Passagen im Quellcode aussehen müssen.

Klasse A (A extends X und A implementiert B)
Klasse C (implementiert A)

Eine Klasse kann keine Klasse implementieren. Annahme für nachfolgende Betrachtung: C erbt von A.

1. A m = new A (Typ A, B und X)

2. B m = new A (Typ A, B und X)

3. C m = new C (Typ C, B, A und X)

4. A m = new C (Typ C, B, A und X)

5. X m = new X (Typ X)

Stimmt.

(Bsp. wenn ich die Objektvariablen die in der Vererbungshierarchie drüber stehen, beim Erzeugen von 3) nicht gefüllt habe)

Wenn ihnen in der Klasse kein fester Wert zugewiesen wird und auch der Konstruktor das nicht erledigt, haben alle Variablen primitiven Typs einen Standardwert und alle Referenzen sind null.

Grüße
Richard

[Michilee]

Hi Richard,

» b) meineKlasse b = new meineKlasse() verwende?

Siehe Programmieren gegen Schnittstellen. Wenn du nur die Funktionalität des Interfaces benötigst, gib auch nur das Interface als Typ an. Das bringt enorme Vorteile vor allem in der Erweiterbarkeit.

vielen dank, habe ich mir angeschaut. Die dritte Grafik von oben leuchtet mir aber nicht ganz ein:

http://www.baldenhofer.eu/images/blog/grundlagen/interfaces.png

• Ich habe die ClassA  mit imlements InterfaceB
• ClassB und ClassBWebwersvices sind eigentständige Klassen mit fertigen Methoden.
• Was macht nun das Interface InterfaceB nun genau. Ist es nun einfach ein Interface in der die Methoden von ClassB und ClassBWebservice drin stehen, die dann für ClassA vorgeschrieben werden oder läuft dies anders ab. Das erstere wüde wohl wenig sinn machen, wenn ich in ClassA alle Methoden implementieren muss, die mir das Interface vorschreibt.

Nein nein, du bringst da einiges durcheinander. Du wirst niemals mit new Serializable() ein Objekt von Serializable erzeugen können. Serializable ist ein Interface. Erben (im Sinne von extends) können davon nur andere Interfaces. Implementieren (im Sinne von implements) können es nur Klassen.

Ja, war von mir ein ganz blödes Beispiel. Hätte anstatt Seriazible eine willkürliche eigene Klasse nehmen sollen.

Wo macht es bzw. worin sind die Unterschiede genau, wenn meineKlasse Seriazible implementiert und ich das Objekt mal so:
»»

a) Seriazible a = new meineKlasse()

»»

und einmal

»»

b) meineKlasse b = new meineKlasse() verwende?

Klasse A
Interface I
Klasse X extend A und implementiert I

Ich könnte ja wie gesagt das Objekt so bilden:

1. I a = new X();
   oder
2. X a = new X();
3. A a = new X();

Von Typ her wären beide gleich. Funktionalität wäre womöglich bei beiden auch gleich. Du schriebst, sobald ich als Typ I angebe beim Objekt bilden (hoffentlich habe ich dich nicht falsch verstanden), dann bringt das Vorteile bei der Erweiterbarkeit.

Sollte ich beim Objektbilden in der Variante 2) das Inteface erweitern, hätte bzw. müsste ich das ja eh in Klasse X implementieren. Ich checke hier genau den Vor- und Nachteil der oberen 3 Objektbildungen nicht.

Gut, dass meine Threads kürzer werden :-)

Grüße

[Rouven]

Hello,

• Was macht nun das Interface InterfaceB nun genau. Ist es nun einfach ein Interface in der die Methoden von ClassB und ClassBWebservice drin stehen, die dann für ClassA vorgeschrieben werden oder läuft dies anders ab. Das erstere wüde wohl wenig sinn machen, wenn ich in ClassA alle Methoden implementieren muss, die mir das Interface vorschreibt.

Ja, es ist einfach nur ein Interface (in Deutsch: Schnittstelle). Dein Klassendiagramm zeigt den Zweck ganz deutlich: Du hast ein A, das etwas verwenden möchte. Es möchte eine Methode getDataFromB aufrufen, die ihm irgendwas liefert. Dem A ist aber vollkommen egal, ob das jetzt ClassB oder ClassBWebservices ist, es arbeitet einfach stur gegen das Interface.
Wenn du am Anfang der Java-Welt stehst, dann stellt sich dir vielleicht die Frage "wie geht das, A muss doch irgendwas erzeugen", du denkst vielleicht dran, dass im Code von A irgendwo steht
   InterfaceB meinB = new ClassB();
oder eben
   InterfaceB meinB = new ClassBWebservices();

Dem ist aber bei "entkoppelter" Programmierung nicht so. Nein, viel eher steht irgendwo ein Aufruf "Hallo, kann mir mal irgendjemand ein InterfaceB besorgen" - dieser irgendjemand hat Kriterien, nach denen er auswählt, ob er sich für B oder BWebservice entscheidet, die dem A aber vollkommen verborgen bleiben.

Tragen wir es auf eine etwas andere Ebene und nehmen ein Beispiel:
A sei Teil eines Web Content Management Systems, es hält einen Inhalt in der Hand, den es gerne zum Nutzer schicken möchte.
Es gibt ein Interface ContentRenderer, das eine Methode render(Content) zur Verfügung stellt.
Abhängig davon, ob dein Benutzer ein iPhone oder ein ausgewachsenes PC-System vor sich hat, möchtest du jetzt den Inhalt unterschiedlich aufbereiten. WAS für ein System du vor dir hast, weißt du aber völlig wo anders, sagen wir in einer Klasse UserProfile, da hast du die Daten mal ausgewertet und hältst die jetzt vor. Jetzt passiert folgendes:
(1) A hat den Inhalt den es verschicken möchte, weiß aber nicht was das für ein Benutzer ist
(2) A lässt sich von UserProfile einen adäquaten ContentRenderer geben, z.B. ContentRenderer myRenderer = UserProfile.getRendererForUser();
(3) A kann, ohne zu wissen, ob es jetzt einen IPhoneContentRender oder einen PCContentRenderer vor sich hat, blind die Methode render(myContent) aufrufen, da diese vom Interface gestellt wird.

A wird also ausschließlich gegen das Interface entwickelt. Das hat noch einen weiteren Vorteil - sagen wir, Googles Android kriegt in Zukunft den Inhalt nochmal anders aufbereitet - am Ablauf von A ändert das mal gar nichts, der möchte weiterhin nur den Inhalt rausspucken - wäre jetzt ziemlich blöd, wenn du den Code anpassen müsstet, nur weil es plötzlich auch noch einen AndroidRenderer gibt - passiert dir beim Schreiben gegen das Interface nicht, da kümmert sich ausschließlich UserProfile drum.

Genau solche Entkopplungsszenarien sind ein Grund für Interfaces.

MfG
Rouven

[Richard]

Hallo Michilee,

• Ich habe die ClassA  mit imlements InterfaceB

Nein, der UML-Pfeil mit spitzer Spitze (statt Dreieck; zusätzlich ist der Pfeil waagerecht, was aber reine Konvention ist) zeigt eine Aggregation an (beschriftet mit «use»), was in der Praxis nichts anderes bedeutet, als dass ClassA ein Attribut vom Typ InterfaceB hat. Dies ist natürlich in Wahrheit eine konkrete Implementierung davon (also ClassB oder ClassBWebservices). Diese Klassenkonstellation deutet eindeutig auf ein Strategy-Pattern hin (oder State-Pattern, was im Prinzip das gleiche ist).

Den Gedanken dahinter hat Rouven sehr schön erklärt.

Frohes Fest
Richard

[Michilee]

Hi,

• Ich habe die ClassA  mit imlements InterfaceB

Nein, der UML-Pfeil mit spitzer Spitze (statt Dreieck; zusätzlich ist der Pfeil waagerecht, was aber reine Konvention ist) zeigt eine Aggregation an (beschriftet mit «use»), was in der Praxis nichts anderes bedeutet, als dass ClassA ein Attribut vom Typ InterfaceB hat. Dies ist natürlich in Wahrheit eine konkrete Implementierung davon (also ClassB oder ClassBWebservices).

aaah, also nicht implements, sondern Attribut. (Objektvariable bzw. Klassenvariable) Auch ganz schön.

Ich schaue mir dann morgen oder die Tage den Beitrag von Rouven genau an, bzw. versuch morgen seine Logik auch praktisch zu realisieren und antworte dann, ob alles geklappt hat oder ich evtl. noch kleine Lücken habe.

Vielen Dank Euch beiden und übriges schönes und frohes Fest

Grüße

[Michilee]

Hi,
ich störe gerade nochmal, bevor ich ins Bett gehe, da ich wieder etwas verwechselt habe.

Also den ersten Bereich von Rouven habe ich schon sehr gut verstanden, morgen mach ich das Beispiel durch.

Vorhin hatte ich Attribut geschrieben, also ClassA hat kein implements von IntefaceB, sondern ein Attribut (ich denke Objektvariable, Klassenvariable) in ClassA.

Was mich noch kurz vor dem Bettgehen durcheinander gebracht hat, dass man ja von einem Inteface eigentlich kein Attribut (Objektvarieble,Klassenvariable) erstellen kann in ClassA, da es ja ein Interface ist und keine Klasse,da kann man ja keine Objekte bilden.

Vielleicht träum ich auch von Java heut :-)

Grüße

[Richard]

Hallo Michilee,

Was mich noch kurz vor dem Bettgehen durcheinander gebracht hat, dass man ja von einem Inteface eigentlich kein Attribut (Objektvarieble,Klassenvariable) erstellen kann in ClassA, da es ja ein Interface ist und keine Klasse,da kann man ja keine Objekte bilden.

Natürlich verbirgt sich hinter dem Attribut vom _Typ_ InterfaceB eine konkrete Implementierung davon.

Grüße
Richard

[Michilee]

Nabend,
hoffe, dass jeder nen schönen Fest hatte.

Was mich noch kurz vor dem Bettgehen durcheinander gebracht hat, dass man ja von einem Inteface eigentlich kein Attribut (Objektvarieble,Klassenvariable) erstellen kann in ClassA, da es ja ein Interface ist und keine Klasse,da kann man ja keine Objekte bilden.

Natürlich verbirgt sich hinter dem Attribut vom _Typ_ InterfaceB eine konkrete Implementierung davon.

Habe den Satz leider nicht ganz verstanden, frage aber nach den Ferien unseren Lehrer nochmals direkt. "Eine konkrete Implementierung?"

Habe die Wiki http://de.wikipedia.org/wiki/Strategie_%28Entwurfsmuster%29 gelesen.

Zitat:
"
Die Klasse Strategie definiert nur eine Schnittstelle (Interface) für alle unterstützten Algorithmen. Die Implementierung der eigentlichen Algorithmen finden sich erst in den Ableitungen dieser (konkreteStrategie).

Der Kontext hält eine Member-Variable der Schnittstelle Strategie, wird aber mit einer Referenz auf das gewünschte konkrete Strategieobjekt belegt. Somit wird der Algorithmus über die Schnittstelle verwendet und dies ermöglicht auch ein Austauschen der Algorithmen zur Laufzeit.
"

Was meint er mit, die Klasse Strategie definiert nur eine Schnittstelle?
Strategie selber ist kein Interface, sondern eine Klasse. D.h., sie implementiert dann vom meinem Verständnis her die beiden Interfaces KonkreteStrategieA und B?

Ich gehe halt immer von der Programmiersprache Java aus. Bevor ich das aushole, bzw. meine spezielle Frage stelle, warte ich mal auf eine Antwort für ganz oben mit der konkreten Implementierung. Attribut vom _Typ_ InterfaceB eine konkrete Implementierung.

Grüße

[Richard]

Hallo Michilee,

Natürlich verbirgt sich hinter dem Attribut vom _Typ_ InterfaceB eine konkrete Implementierung davon.

Habe den Satz leider nicht ganz verstanden, frage aber nach den Ferien unseren Lehrer nochmals direkt. "Eine konkrete Implementierung?"

Ich meine damit ein Objekt von einer Klasse, die InterfaceB implementiert.

Was meint er mit, die Klasse Strategie definiert nur eine Schnittstelle?

Dass Strategie ein Interface ist, dass die Fähigkeiten der konkreten Strategien vorschreibt.

Strategie selber ist kein Interface

Doch.

sie implementiert dann vom meinem Verständnis her die beiden Interfaces KonkreteStrategieA und B?

Nein, umgekehrt.

Grüße
Richard

[Michilee]

Hi,

Oki, bezogen auf auf folgenden Link Wikipedia: Strategie
versuche ich das dann zusammenzufasen:

Ah, ich weiß nicht. Könntest mir falls du Zeit hast, dass nur ganz klein javaorientiert aufzeigen, da ich grad wieder falsch angefangen habe.

Kontext ist eine Klasse.

Strageie ist ein Interface in der nur Methoden vorgeschrieben werden.

KonkreteStrategieA implementiert Strategie
KonkreteStrategieB implementiert Strategie

Ab hier hätte KonkreteStrategieA und KonkreteStrategieB doppelt Aufwand, da sie immer die Methoden von Strategie implementieren muss.

Die Klasse Kontext implementiert nun nichts, sondern hat eine Attribut. Laut Wiki ist das Strategie, aber von Strategie könnte man kein Objekt bilden. Ist da noch eine Zwischenklasse? Oder hat die Klasse Kontext hat die Attribute KonkreteStrategieA und KonkreteStrategieB. Würde aber kein Sinn machen.

Grüße

[Richard]

Hallo Michilee,

KonkreteStrategieA implementiert Strategie
KonkreteStrategieB implementiert Strategie

Ab hier hätte KonkreteStrategieA und KonkreteStrategieB doppelt Aufwand, da sie immer die Methoden von Strategie implementieren muss.

Nein, niemand hat doppelten Aufwand, da KonkreteStrategieA und KonkreteStrategieB die Methode(n) selbstverständlich jeweils unterschiedlich implementieren - das ist schließlich der Sinn des Patterns.

Die Klasse Kontext implementiert nun nichts, sondern hat eine Attribut. Laut Wiki ist das Strategie, aber von Strategie könnte man kein Objekt bilden. Ist da noch eine Zwischenklasse? Oder hat die Klasse Kontext hat die Attribute KonkreteStrategieA und KonkreteStrategieB. Würde aber kein Sinn machen.

Exakt dieselbe Frage habe ich in meinem vorhergehenden Posting bereits beantwortet.

Grüße
Richard

[Michilee]

Hi,
hab ein Zwischenergebniss. Habe einen absolvierten Informatik Diplomanten gefragt, da ich unsere Lehrer erst in 1-2 Wochen sehe, der jedoch nun meint und mich erst recht durcheinander bringt:

Kontekt sei ein Interface
Strategie sei eine Klasse "(Die Wiki fängt auch so an: Die Klasse Strategie definiert ....)"

KonkreteKlasseA und B seien nur Imports.

Man könne bei einem Interface auch viel mehr machen, anstatt nur Methodennamen ohne Rumpf, um das Interface in einer anderen Klasse zu implementieren. Das hat mir dann den Kick gegeben :-I
Ich schau mir das ganze nochmal die Tage in Ruhe an und versuch alles auf mich einzuwirken, bin nur nicht dazu gekommen in Java ein paar Versuche zu schreiben, hoffentlich aber die Tage, dann poste ich den Code.

Die Klasse Kontext implementiert nun nichts, sondern hat eine Attribut. Laut Wiki ist das Strategie, aber von Strategie könnte man kein Objekt bilden. Ist da noch eine Zwischenklasse? Oder hat die Klasse Kontext hat die Attribute KonkreteStrategieA und KonkreteStrategieB. Würde aber kein Sinn machen.

Exakt dieselbe Frage habe ich in meinem vorhergehenden Posting bereits beantwortet.

:(

Grüße

[Richard]

Hallo Michilee,

Kontekt sei ein Interface

Entwurfsmuster sind auf objektorientierte Programmierung gemünzt, was mehr einschließt als nur die Sprache Java. Es ist auch vorstellbar, Entwurfsmuster in Sprachen zu realisieren, die das Konzept „Interface” gar nicht kennen. Dementsprechend schreibt ein Entwurfsmuster grundsätzlich nicht vor, welche Klasse abstrakt oder gar nur ein Interface ist. Prinzipiell könnten auch alle Interfaces normale Klassen sein.

Die Klasse Kontext enthält allerdings ein Strategieobjekt, auf dem sie arbeitet (d.h. auf dem sie die Methode Algorithmus() aufruft). Dieser Sachverhalt ist so in Java nicht abbildbar, wenn Kontext keine „normale” Klasse ist. Kontext ist also bis auf weiteres kein Interface.

Strategie sei eine Klasse "(Die Wiki fängt auch so an: Die Klasse Strategie definiert ....)"

Was daran liegt, dass Entwurfsmuster nicht Java-spezifisch sind (siehe oben). „Die Klasse definiert eine Schnittstelle” heißt auf Java-Deutsch soviel wie: „Die Klasse ist eine Schnittstelle”.

KonkreteKlasseA und B seien nur Imports.

Imports haben mit dieser Thematik sowieso nichts zu tun. KonkreteStrategieA und KonkreteStrategieB sind Implementierungen des Interfaces Strategie (oder, allgemeiner gesprochen, irgendeine Form von Ableitungen der Klasse Strategie).

Man könne bei einem Interface auch viel mehr machen, anstatt nur Methodennamen ohne Rumpf, um das Interface in einer anderen Klasse zu implementieren.

Ohne zu wissen, was mit „viel mehr machen” gemeint ist, kann ich dir versichern: nein, kann man nicht. Du kannst gerne versuchen, dem Compiler ein Interface zu überreichen, das mehr als unimplementierte Methodenrümpfe enthält; er wird es dir mit Ablehnung strafen. Interfaces sind in dieser Hinsicht ziemlich langweilig. Erst wenn man sie implementiert, wird's spannend.

:(

Wir haben innerhalb dieses Threads bereits ausführlich genug erörtert, wann welches Objekt welche(n) Typ(en) hat, um dir zu ermöglichen, was mit „konkrete Implementierung eines Interfaces” gemeint ist. (Erinnere dich an die Code-Beispiel zum Interface Serializable)

Grüße
Richard