Unterschied zwischen Implement und extend ?
- Themenstarter Code46
- Beginndatum
vfl_freak
Premium-User
Moin,
das sollte Deine Frage beantworten:
http://www.java-forum.org/java-basics-anfaenger-themen/69071-klassendesign-extend-implement.html
Gruß
Klaus
das sollte Deine Frage beantworten:
http://www.java-forum.org/java-basics-anfaenger-themen/69071-klassendesign-extend-implement.html
Gruß
Klaus
vfl_freak
Premium-User
Moin,
naja, ich glaube nicht so ganz (wenn ich Deine Bemerkung richtig verstehe ...)
Vlt. nochmal in anderen Worten:
extends
Die abgeleitete Klasse erbt alle Elemente der Basisklasse und darf auf alle Elemente zugreifen (soweit in der Basisklasse erlaubt).
Auch Nutzer der abgeleiteten Klasse können dies !
implements
Hiermit werden sog. Schnittstellen vererbt, die Du Dir als abstrakte Klasse vorstellen musst, d. h. sie enthalten nur abstrakte public-Methoden ()und ggf. Konstanten. In der erbenden Klasse müssen alle Elemente der Schnittstelle implementiert werden
Besser ? ? ?
Gruß
Klaus
naja, ich glaube nicht so ganz (wenn ich Deine Bemerkung richtig verstehe ...)
Vlt. nochmal in anderen Worten:
extends
Die abgeleitete Klasse erbt alle Elemente der Basisklasse und darf auf alle Elemente zugreifen (soweit in der Basisklasse erlaubt).
Auch Nutzer der abgeleiteten Klasse können dies !
implements
Hiermit werden sog. Schnittstellen vererbt, die Du Dir als abstrakte Klasse vorstellen musst, d. h. sie enthalten nur abstrakte public-Methoden ()und ggf. Konstanten. In der erbenden Klasse müssen alle Elemente der Schnittstelle implementiert werden
Java:
interface Test
{
Objekt myTest();
} // Test
// ......
public class TestKlasse
implements Test
{
.....
// hier muss "myTest()" implementiert werden !!
.....
} // TestklasseBesser ? ? ?
Gruß
Klaus
MasterOP22
Grünschnabel
Hallo,
vielleicht sollte man dir implements am besten an einem Beispiel verdeutlichen.
Nehmen wir ma an, du hast eine Anwendung die eine Datenbank verwenden soll. Aber du möchtest dich nicht auf Dauer auf eine festlegen, sondern möchtest den Zugriff auf die Datenbank aus deinem Quellcode so leicht wie möglich austauschen.
Durch solche Probleme entsteht das Wort Schnittstelle, die wenn man es mal sehr abstrakt betrachtet ein Tor bzw. eine Hülle vor deinen ausimplementierten Klasse darstellt.
Für dieses Problem sähe sowas wie folgt aus. Du hast zum einen eine Klasse, welche den Zugriff auf eine MySQL Datenbank durchführt, nennen wir sie MySqlDelegate und du hast eine Klasse die dasgleiche nur für eine Datenbank von Oracle tut z.B. OracleDelegate. So und du hast eine main-Klasse die jetzt gerne Daten speichern möchte. Wenn du jetzt direkt den mysqldelegate oder den OracleDelegate aufrufst, hast du Datenbank und Anwendung fest mtieinander verdrahtet -> d.h. eine späterer Austausch ist schon recht umständlich.
Also packen wir eine Hülle davor, namens DBDelegate. Dieses Interface wird über implements in die beiden Delegates(Mysql, Oracle) eingefügt. Damit ist klar, dass du über das Tor mit diesen Klassen reden kannst aus deiner Anwendung. So nun rufst du aus deiner Anwendung nur noch das DBDelegate auf. Dies hat zur Folge, dass die Anwendung von der Datenbankimplementierung getrennt ist. Deswegen macht es keinen Sinn in das DBDelegate mit private Methoden auszustatten, weil du erstellst die Schnittstelle ja um der Anwendung ne Möglichkeit zu geben mit den datenbanken zu kommunizieren.
Jetzt fvragst du dich wahrscheinlich, woher weiß denn nun der DBDelegate an welche der Datenbanken die Aufrufe weiterzugeben sind. Deswegen erstellst du eine weitere Klasse z.B. DBFactory. Diese enthält folgende Methode
public DBDelegate getDB(){
return new MySqlDelegate();
}
aus der Anwendung kannste jetzt sagen
DBDelegate db = DBFactory.getDB();
db.speicher();
Das DBDelegate muss dann natürlich zwingend folgende Methode haben
public interface DBDelegate{
public void speicher();
}
Und da du das DBDelegate per implements in der MysqlDelegate hast musst du dort die speicher() - Methode implementieren
public class MySqlDelegate{
public void speicher(){
//Code um Daten in einer MySql anzulegen.
}
Jetzt erkennste vllt. langsam den Vorteil. Wenn du jetzt lieber die Oracle datenbank benutzen willst musst du in DBFactory statt der MySqlDelegate das OracleDelegate zurückgeben und fertig. In der Anwendung bleibt alles beim alten, weil er dort ja nur mit der Schnittstelle redet.
}
Vielleicht hilft dir das ein bissel!?
vielleicht sollte man dir implements am besten an einem Beispiel verdeutlichen.
Nehmen wir ma an, du hast eine Anwendung die eine Datenbank verwenden soll. Aber du möchtest dich nicht auf Dauer auf eine festlegen, sondern möchtest den Zugriff auf die Datenbank aus deinem Quellcode so leicht wie möglich austauschen.
Durch solche Probleme entsteht das Wort Schnittstelle, die wenn man es mal sehr abstrakt betrachtet ein Tor bzw. eine Hülle vor deinen ausimplementierten Klasse darstellt.
Für dieses Problem sähe sowas wie folgt aus. Du hast zum einen eine Klasse, welche den Zugriff auf eine MySQL Datenbank durchführt, nennen wir sie MySqlDelegate und du hast eine Klasse die dasgleiche nur für eine Datenbank von Oracle tut z.B. OracleDelegate. So und du hast eine main-Klasse die jetzt gerne Daten speichern möchte. Wenn du jetzt direkt den mysqldelegate oder den OracleDelegate aufrufst, hast du Datenbank und Anwendung fest mtieinander verdrahtet -> d.h. eine späterer Austausch ist schon recht umständlich.
Also packen wir eine Hülle davor, namens DBDelegate. Dieses Interface wird über implements in die beiden Delegates(Mysql, Oracle) eingefügt. Damit ist klar, dass du über das Tor mit diesen Klassen reden kannst aus deiner Anwendung. So nun rufst du aus deiner Anwendung nur noch das DBDelegate auf. Dies hat zur Folge, dass die Anwendung von der Datenbankimplementierung getrennt ist. Deswegen macht es keinen Sinn in das DBDelegate mit private Methoden auszustatten, weil du erstellst die Schnittstelle ja um der Anwendung ne Möglichkeit zu geben mit den datenbanken zu kommunizieren.
Jetzt fvragst du dich wahrscheinlich, woher weiß denn nun der DBDelegate an welche der Datenbanken die Aufrufe weiterzugeben sind. Deswegen erstellst du eine weitere Klasse z.B. DBFactory. Diese enthält folgende Methode
public DBDelegate getDB(){
return new MySqlDelegate();
}
aus der Anwendung kannste jetzt sagen
DBDelegate db = DBFactory.getDB();
db.speicher();
Das DBDelegate muss dann natürlich zwingend folgende Methode haben
public interface DBDelegate{
public void speicher();
}
Und da du das DBDelegate per implements in der MysqlDelegate hast musst du dort die speicher() - Methode implementieren
public class MySqlDelegate{
public void speicher(){
//Code um Daten in einer MySql anzulegen.
}
Jetzt erkennste vllt. langsam den Vorteil. Wenn du jetzt lieber die Oracle datenbank benutzen willst musst du in DBFactory statt der MySqlDelegate das OracleDelegate zurückgeben und fertig. In der Anwendung bleibt alles beim alten, weil er dort ja nur mit der Schnittstelle redet.
}
Vielleicht hilft dir das ein bissel!?
Zuletzt bearbeitet:
