Interfaces "Schreibaufwand"

Status
Nicht offen für weitere Antworten.

knowledge

Bekanntes Mitglied
Hallo,

wenn ich ein Interface A definieren, welches z.B. eine Methode figh() vorgibt, dann müssen ja alle Klassen, die dieses Interface implementieren rechne implementieren. Eine Referenzvariable

A testvariable kann also alle Objekte aufnehmen, die das Interface mittels implements implementieren. Nun meine Frage:

Angenommen ich habe eine Klasse Bauer, welche die Methode fight() implementiert, also auch das Interface A. Ich müsste ja

class Bauer implements A {
... fight()
}

schreiben. Wieso ist es nicht möglich einfach

class Bauer {

...fight()

}

zu schreiben. Der Compiler müsste doch erkennen, dass wenn ich testvariable ein Bauer Objekt übergebe die fight() Methode dort vorhanden ist. Also es könnte doch immer geprüft werden, ob die von A geforderten Methoden in einem Objekt vorhanden sind. Wieso muss ich explizit kennzeichnen, dass ich ein bestimmtes Interface meine...

Egal was ich A testvariable zuweise, einfach nur prüfen, ob die zugewiesenen Objekte die Methode fight() implementieren. Was nützt da die explizite implements A Angabe? Der Compiler könnte doch auch so prüfen, ob die Methoden alle vorhanden sind, ohne das ich immer implements schreibe. Was ist also der Vorteil, wenn nicht einfach nur geprüft wird ob die konkreten Objekte alle benötigen (Interface) Methoden implementieren sondern ich noch explizit angeben, dass es sich um eine Implementation des konreten Interfaces handelt.

Wenn ich also eine Klasse Turm schreiben würde, könnte die ja auch einfach die Methode fight() implementieren.

class Turm() {

fight()

}

A testvariable = new Turm();

Wenn das gehen würde, bräuchte ja nur geprüft werden ob turm fight implementiert, da ich Turm testvariable zuweise. Ohne das ich noch extra implements schreiben müsste.
 

tfa

Top Contributor
Java ist statisch typisiert. Da müssen die Typinformationen alle schon zur Compilierzeit fest stehen, insbesondere auch welche Interfaces die Klassen implementieren. Es gibt dynamisch typisierte Sprachen bei denen man das nicht muss. Da hat man weniger Schreibaufwand (hat aber auch Nachteile). Bei Java hat man sich eben anders entschieden.
 

Noctarius

Top Contributor
Umgedreht kannst du bei schlauer Benutzung der Interfaces auf Fähigkeiten einer Klasse schließen.

Ich habe z.B. eine Art Property Interface als Basis genommen welches die Method implementsProperty definiert. Die Properties selbst sind dann Interfaces die Property extended und um Methoden erweitern.

Z.B.:

[highlight=java]public interface PropertyAttackable extends Property {
boolean isAutoAttackable(ManagedObject attacker);

boolean isAttackable(ManagedObject attacker);
}[/highlight]

Damit kannst du allein anhand der implementierten Interfaces auf Fähigkeiten eines "Objektes" schließen (ich mein als Programmierer) ohne dir auch den weiteren Sourcecode auch nur angesehen zu haben.
 

knowledge

Bekanntes Mitglied
>Da müssen die Typinformationen alle schon zur Compilierzeit fest stehen

Naja, stehen sie ja trotzdem. Die Objekte müssen vom Typ A sein, damit sie fight() haben. Ich erkenne die Objekte vom Typ A an, wenn sie die Methode implementieren.

Also Bauer hat fight Methode, also ist er vom Typ A, Turm hat fight Methode usw. Ich meine warum kann nicht auf den Typ von den implementierten Methoden geschlossen werden? Also ich sehe alles als vom Typ A an bzw. kann es als Typ A nutzen, wenn es eine fight Methode hat. Wieso also noch zusätzlicher Schreibaufwand indem ich implements A schreibe? Ich müsste nur sicherstellen, dass alles was A zugewiesen werden soll die Fight Methode hat. Also

Bauer {
fight()
}

Turm {
fight()
}

statt

Bauer implements A {
fight()
}

Turm implements A {
fight()
}

Ich muss doch nur sicherstellen, das wenn ich Bauer und Turm einer (Referenz)Variablen vom Typ A zuweise diese die Methode fight implementieren. Das kann ich doch auch so prüfen.

A fightvar = new Bauer(); -> Compiler prüft ob Bauer fight Methode hat, da A dies verlangt. Dies kann er doch einfach so prüfen ob eine Methode fight mit der entsprechenden Signatur existiert. Dazu bedarf es doch keines implements. D.h. der Compiler könnte doch auch ohne implements A erkennen, ob die gewünschte(n) Methode(n) fight() für Bauer vorhanden sind oder nicht. Was nützt da ein zusätzliches markieren mit implements A wenn man auch so überprüfen kann, ob die Methode bei einer Zuweisung vorhanden sind?
 
S

Spacerat

Gast
Ähhh nein: Compiler prüft, ob Bauer das Interface A implementiert. Wenn nicht gibt's ne' ClassCastException. Mit anderen Worten: Dem Compiler sind die implementierten Methoden des Objekts zunächst erstmal schnurz. Erst wird nämlich geprüft, ob der Objekttyp passt.
 
Zuletzt bearbeitet von einem Moderator:

Verjigorm

Top Contributor
Was ist, wenn eine deiner Klassen auch eine Methode fight() implementiert, die NIX mit dem Interface zutun haben soll(te)?

Edit:
Oder blödes Beispiel:
Du hast 2 Interfaces in deinem Projekt, die beide fight() vorgeben.
 
Zuletzt bearbeitet:
M

maki

Gast
In Smalltalk soll so etwas möglich sein, nämlich das man sich das implements sparen kann und es reicht wenn die Methoden die selben Signaturen haben.
 

tfa

Top Contributor
Du stellst die selbe Frage nochmal. An der Antwort hat sich nichts geändert. Es ist einfach so. Wenn du das nicht willst, musst du eine dynamisch typisierte Sprache (besser noch Duck-Typing-Sprache) verwenden. Dann gibt es keine Interfaces.

A fightvar = new Bauer(); -> Compiler prüft ob Bauer fight Methode hat, da A dies verlangt.
Und was macht der Compiler bei A fightvar = getObjectInputStream().readObject()?
 
B

Beni

Gast
Naja, stehen sie ja trotzdem. Die Objekte müssen vom Typ A sein, damit sie fight() haben. Ich erkenne die Objekte vom Typ A an, wenn sie die Methode implementieren.

Solange der Compiler allen Code auf einmal kompilieren kann: ja, dann sind theoretisch all die Informationen vorhanden und Interfaces wären nicht notwendig.

Sobald du aber Libraries oder mehrere Projekte verwendest, sind zur Kompilierzeit nicht unbedingt alle Information zu finden. Und dann geht es nicht mehr ohne Interfaces (es sei denn, du möchtest die Fehler erst zur Laufzeit sehen... ).

Eine Ausnahmeregelung um Interfaces zu vermeiden wenn nicht notwendig wäre bestenfalls verwirrend.
 

Landei

Top Contributor
In Smalltalk soll so etwas möglich sein, nämlich das man sich das implements sparen kann und es reicht wenn die Methoden die selben Signaturen haben.

In Scala auch, da heißt sowas "struktureller Typ":
Code:
def test(f: { def getName(): String }) { 
   println(f.getName) 
}
Die Methode test(x) akzeptiert hier jedes Objekt x, das eine Methode getName():String implementiert.
 

slawaweis

Bekanntes Mitglied
Egal was ich A testvariable zuweise, einfach nur prüfen, ob die zugewiesenen Objekte die Methode fight() implementieren. Was nützt da die explizite implements A Angabe? Der Compiler könnte doch auch so prüfen, ob die Methoden alle vorhanden sind, ohne das ich immer implements schreibe. Was ist also der Vorteil, wenn nicht einfach nur geprüft wird ob die konkreten Objekte alle benötigen (Interface) Methoden implementieren sondern ich noch explizit angeben, dass es sich um eine Implementation des konreten Interfaces handelt.
die Antwort ist ziemlich einfach, Typsicherheit:

[highlight="java"]
public interface B
{
/** diese Funktion erstellt eine Datei fight.txt */
public void fight();
}

public interface C
{
/** diese Funktion verbindet mit einer Datenbank "fight" */
public void fight();
}

public interface D
{
/** diese Funktion öffnet ein Fenster mit dem Namen "fight" auf dem Desktop */
public void fight();
}

public class Bauer
{
public void fight()
{
/* ... */
}
}
[/highlight]

und jetzt die 1.000.000 Euro Frage:

welchem Interface entspricht fight() in Bauer? Ist A, oder B, oder C, oder doch D?

Slawa
 
M

maki

Gast
>> welchem Interface entspricht fight() in Bauer? Ist A, oder B, oder C, oder doch D?

Ganz einfach: allen ;)
 
M

maki

Gast
Hä? In welcher Sprache? Jedenfalls nicht in Java. Bauer hat hier nur zufällig 'ne Methode "fight()".
Bin mir nicht sicher ob es Smalltalk oder Eiffel war, jedenfalls ist das hier eine "was wäre wenn diskussion" ;)
 

tfa

Top Contributor
Bin mir nicht sicher ob es Smalltalk oder Eiffel war, jedenfalls ist das hier eine "was wäre wenn diskussion" ;)

Smalltalk, Python, Ruby, Groovy etc. Genau genommen gibt's in diesen Sprachen gar keine Methodenaufrufe, sondern nur Botschaften (Messages), die man an Objekte schickt. Wenn man die Botschaft "fight" an ein Objekt sendet, ist es völlig egal, ob das ein Bauer, Turm, Kampfpanzer oder sonstwas ist.
 

Noctarius

Top Contributor
Hä? In welcher Sprache? Jedenfalls nicht in Java. Bauer hat hier nur zufällig 'ne Methode "fight()".
Code:
Bauer b = new Bauer();
((A) b).fight();
funtz trotzdem nicht -> ClassCastException.

Wenn das Interface anhand der Methode erkannt werden würde, denn das war die Frage zu dem A, B, C oder D dann müssten es alle sein, genau wie maki gesagt hat. Ganz einfach.
 
S

Spacerat

Gast
Ja... gut... wer lesen kann... usw...
Dennoch wiederstrebt es mir, Fragen über Sinn und Zweck von Interfaces so zu beantworten. In Java bleibt das nun mal falsch. Erschwerend kommt hinzu, dass sich das auch noch kompilieren lässt. Das bedeutet das der Fehler erst zur Laufzeit auftaucht. Diese Tatsache löste bei mir schlicht 'nen Alarm aus, als ich diesen "Blödsinn" (war dort natürlich keiner: dort steht ja "entspricht") dort gelesen habe. Also,
Klarstellung:
Der Kompiler erkennt Interfaces nicht anhand von implementierten Methoden!
Klassen können alle Methoden eines Interfaces implementieren ohne dieses Interface selbst zu implementieren.
Aufrufe auf "Interface-Methoden" einer solchen Klasse unter Verwendung des Interfaces ("((A) b).fight()") enden zur Laufzeit in einer "ClassCastException", während der Aufruf als "Klassen-Methode" ("b.fight()") natürlich weiter funktioniert. Das ist das, was slawaweis mit Typsicherheit meinte.
 

slawaweis

Bekanntes Mitglied
und jetzt die 1.000.000 Euro Frage:

welchem Interface entspricht fight() in Bauer? Ist A, oder B, oder C, oder doch D?
ich habe mich hier etwas ungünstig ausgedrückt. Es ging darum, welche Funktionalität nach den Model von knowledge ausgeführt wird, wenn fight() in Bauer aufgerufen ist? Die Funktionalität von B, C und D habe ich ja in den Kommentaren festgelegt. Nach dem Model von knowledge würde folgendes gehen:

[highlight="java"]
public class Bauer
{
public void fight()
{
/* ... */
}
}

// ...

A a = new Bauer();
B b = new Bauer();
C c = new Bauer();
D d = new Bauer();

a.fight(); // ...
b.fight(); // nach der Definition aus B muss jetzt Datei fight.txt erstellt werden
c.fight(); // nach der Definition aus C muss eine Verbindung zu einer Datenbank "fight" aufgebaut werden
d.fight(); // nach der Definition aus D muss ein Fenster mit dem Namen "fight" geöffnet werden
[/highlight]

kurz gesagt es ist nicht klar, welche Funktionalität Bauer eigentlich realisiert. Kann auch sein, dass fight() in Bauer gar keinem Interface entsprechen sollte, sondern nur eine Funktion in der Klasse sein soll.

Slawa
 

0x7F800000

Top Contributor
Die gefahr bei ducktyping ist einfach die, dass man alleine anhand der methoden-signaturen irgendetwas falsches vom verhalten annehmen könnte. Ganz einfaches beispiel angelehnt an comparable:
Code:
interface Totalgeordnet<T>{ //aka Comparable
  int compareTo(T t); //hier wird gefordert: compareTo()=0 => equals()=true 
}

interface Halbgeordnet<T>{
   int compareTo(T t); //hier wird es nicht gefordert, compareTo() darf 0 ergeben, obwohl objekte ungleich sind
}
was könnte da ohne interfaces passieren?
Angenommen, es wird keine "implements XYZ" gefordert, sondern lediglich, dass die methode "compareTo" vorhanden ist. Dann schaust du in der API nach, stellst fest: "Oha, Klasse X stellt methode compareTo zur verfügung, toll!" , ohne auf den vermerk zu achten "vorsicht, halbgeordnet"...

Dann nimmst du ein TreeSet, und packst da die Klasse rein...

Nunja...
Das Programm wird im prinzip irgendwie laufen. Bei objekten der Klasse X, die bei compareTo nicht 0 rausspucken, wird es sogar fehlerfrei laufen. Das wird womöglich sogar den einen oder den anderen Test überstehen. Und dann stellst du nach einer Woche zufällig fest, dass die Elemente manchmal ohne jeglichen ersichtlichen Grund *irgendwo* versickern, und zwar nur, weil TreeSet von einer Totalordnung ausgeht, und verschiedene elemente die compareTo=0 ergeben einfach wegwirft... Viel spaß beim suchen: der Drache quackte wie eine Ente, und ist deswegen im TreeSet gelandet...

=> Interfaces garantieren ein bestimmtes Verhalten, und nicht nur Namen der Methoden.

Imho ist das alles selbst in Java ein bisschen zu wenig. Was mache ich denn, wenn zwei Interfaces gleichbenannte methoden vorschreiben, die aber was verschiedenes liefern sollen? ???:L
 
Zuletzt bearbeitet:

didjitalist

Bekanntes Mitglied
Imho ist das alles selbst in Java ein bisschen zu wenig. Was mache ich denn, wenn zwei Interfaces gleichbenannte methoden vorschreiben, die aber was verschiedenes liefern sollen? ???:L

dann ist man in den arsch gekniffen :D allerdings hat java den vorteil, dass man selbst bei solchem unsinn genau weiss, welche methode aufgerufen wird; nämlich die einzig vorhandene. interfaces wurden in java nur eingeführt, weil mehrfachvererbung nicht erlaubt ist, es aber trotzdem nötig sein kann, dass ein objekt diverse schnittstellen implementieren soll, die sich nicht durch eine gerade hierarchie abbilden lassen. dadurch sind aber trotzdem nicht alle probleme der mehrfachvererbung gelöst, wie man sieht.
 

Noctarius

Top Contributor
Imho ist das alles selbst in Java ein bisschen zu wenig. Was mache ich denn, wenn zwei Interfaces gleichbenannte methoden vorschreiben, die aber was verschiedenes liefern sollen? ???:L

Würde ich sagen hast du eine seltsame Methodenbenennung weil die Methode ansich vom Namen her ja schon die Funktionalität kurz anreißen sollte.

Einzig und allein solche Methoden wie getContent würden mir hier einfallen aber da seh ich tatsächlich keine Möglichkeit solange Java Methoden nicht anhand ihrer Rückgabeparameter unterschieden kann ;) Da liefert dir auch Mehrfachvererbung wie in C++ keinen Lösungsansatz.
 

knowledge

Bekanntes Mitglied
Danke für die zahlreichen Antworten.

>welchem Interface entspricht fight() in Bauer? Ist A, oder B, oder C, oder doch D?
>
>Slawa

OK, das sehe ich ein. Aber zumindest bei Methoden aus der Java API könnte man doch drauf verzichten, oder nicht. Beispielsweise actionPerformed(). In diesem Fall müsste man doch verbieten können, das ein Benutzer seine Methoden nicht nach Methoden nennen darf, die in der Java API schon definiert sind. Wenn ich also actionPerformed irgendwo implementiere, dann könnte immer davon ausgegangen werden, dass es sich um einnen Listener handelt. Damit wäre eindeutigkeit hergestellt.

>Solange der Compiler allen Code auf einmal kompilieren kann: ja, dann sind theoretisch all die Informationen >vorhanden und Interfaces wären nicht notwendig.

>Sobald du aber Libraries oder mehrere Projekte verwendest, sind zur Kompilierzeit nicht unbedingt alle Information >zu finden. Und dann geht es nicht mehr ohne Interfaces (es sei denn, du möchtest die Fehler erst zur Laufzeit >sehen... ).

Das habe ich noch nicht ganz verstanden. Wieso kann man schon kompilierte Klassen nicht darauf prüfen, ob sie eine bestimmte Funktionalität bieten? Also wenn ich die Kompilierte Klasse Bauer hätte könnte ich da nicht einfach prüfen ob Bauer figth() anbietet?

Danke
 
S

Spacerat

Gast
dann ist man in den arsch gekniffen
...aber unheimlich in den A... gekniffen...
Code:
if(this instanceof InterfaceA) return valueForInterfaceA;
else return valueForInterfaceB;
mag zwar gehen aber äh... wissen wir nicht alle, das unsere Klasse (welche ja beide Interfaces implementiert) stets "valueForInterfaceA" zurückgeben würde. Hat man bisher also irgend eine Chance, innerhalb der Methode zu unterscheiden, für welches Interface der Aufruf gedacht war? Soweit ich weis nicht.

(edit: Hab' den Beitrag verfasst, während Noctarius schon geantwortet hat... und wenn C++ usw. schon keine Lösung dafür haben, weis ich es für Java nun noch etwas genauer.)
 
Zuletzt bearbeitet von einem Moderator:

Noctarius

Top Contributor
OK, das sehe ich ein. Aber zumindest bei Methoden aus der Java API könnte man doch drauf verzichten, oder nicht. Beispielsweise actionPerformed(). In diesem Fall müsste man doch verbieten können, das ein Benutzer seine Methoden nicht nach Methoden nennen darf, die in der Java API schon definiert sind. Wenn ich also actionPerformed irgendwo implementiere, dann könnte immer davon ausgegangen werden, dass es sich um einnen Listener handelt. Damit wäre eindeutigkeit hergestellt.

1. Namen sind Schall und Rauch und einer der Vorteile der Sprache Java selbst ist die Wenigkeit der internen Keywords. 99% dessen was man normal benutzt sind Bibliotheken wie alle anderen Externen auch, nur dass sie irgendwann in den Standardumfang der SUN JRE gewandert sind.

2. Sun z.B. bundled Apache Xerxes für XML Kram, IBM tut es nicht. Trotzdem sind dank den Interfaces nach außen hin (also für dein Programm) beide gleich, weil sie über ein Interface angesprochen werden, dass die Implementierung des XML-Krams nach außen hin versteckt. Du erwartest nur ein festes Verhalten, wie dieses erreicht wird *schulter zuck*

3. Und wenn ich mir jetzt mein eigenes Eventframework baue, dass an AWT angelehnt ist und möchte daher (ums den Programmierern einfach zu machen) meine Funktion auch setActionHandler und actionPerformed nennen? =(
 
S

Spacerat

Gast
Das habe ich noch nicht ganz verstanden. Wieso kann man schon kompilierte Klassen nicht darauf prüfen, ob sie eine bestimmte Funktionalität bieten? Also wenn ich die Kompilierte Klasse Bauer hätte könnte ich da nicht einfach prüfen ob Bauer figth() anbietet?
Das hab' ich mit meinen Beiträgen (bis auf den letzten... vergiss den letzten!!!) schon versucht darzulegen. Faktisch wird schon zur Kompilezeit geprüft, ob Bauer eine gewisse Funktion bietet (siehe meinen Beitrag mit der Klarstellung). Deswegen erhält man diese "ClassCastException" ja auch erst zur Laufzeit (achso... für die Erfahreneren... mir ist schon klar, das Exceptions ohnehin erst zur Laufzeit geworfen werden...). Wie gesagt: Klassen mögen zwar die Methoden eines Interfaces bieten, ohne dieses zu implementieren. Aber welcher umstand sollte dann garantieren, das die Methode dieser Klasse dann auch das tut, was vom Interface verlangt wird?
(edit: Mir fällt grad' auf... Kann es sein, das wir überhaupt vom Thema abgekommen sind? Mal folgendes: Du bastelst dir eine Klasse, die eine Methode "public void actionPerformed(ActionEvent e)" bietet. Das Interface "ActionListener" implementierst du aber nicht. Dann versuchst du diese Klasse einem "Button" (oder "JButton") mit "addActionListener()" zu übergeben. Du wirst sehen... das geht nicht.)
 
Zuletzt bearbeitet von einem Moderator:

0x7F800000

Top Contributor
Da liefert dir auch Mehrfachvererbung wie in C++ keinen Lösungsansatz.
Echt nicht? Könnte man da nicht einfach den vollen methodennamen angeben:
Code:
interface A{
   void f();
}

interface B{
   void f();
}

class X implements A,B{
   public void A::f(){
        //do the stuff A guarantees
   }
   public void B::f(){
        //do the stuff B guarantees
   }
}
wenn das nicht möglich ist: wieso nicht, was würde denn dagegen sprechen??

Weil, wenn das nicht möglich ist, dann hätte ich in der Sprache ein problem, das theoretisch durch hinzufügen von 100 zufälligen Ziffern zu jedem methodennamen behoben werden könnte, und dennoch keine Möglichkeit das _schön_ auszuformulieren...
Code:
//interface A ist "gut durchdacht" und für den fall gerüstet, 
//dass eine andere Interface evtl. auch eine methode mit dem namen "f" 
//implementieren will.
interface A{
   void f_1763581263412349216351475641751645934769326941658689162498();
}

//yeah, B ist auch besonders "benutzerfreundlich": 
//Mehrdeutigkeit hat keine chance^^
interface B{
   void f_5736295432694632974598327497532978549732854983275472639542();
}

class X implements A,B{
   public void f_1763581263412349216351475641751645934769326941658689162498(){
        //do the stuff A guarantees
   }
   public void f_5736295432694632974598327497532978549732854983275472639542(){
         //do the stuff B guarantees
    }
    //keine kollisionen, toll, nicht?
}
das wäre doch einfach nur extremst scheiße :autsch:
 
Zuletzt bearbeitet:

knowledge

Bekanntes Mitglied
Hallo,

ihr habt geschrieben, dass Interfaces das sogenannte Ducktyping verhindern sollen. Was versteht man darunter und was ist daran so schlimm? Es geht wohl darum, dass ich annehme wenn ich eine Methode fight() implementiere, dann ist das z.B. immer eine Spielfigur. Also wieso sind Interfaces besser, wo sind die Vorteile? Ich werde ja wohl nicht absichtlich die Fight Methode woanders reinpacken als in eine Spielfigur, um beim Beispiel zu bleiben.
 

Noctarius

Top Contributor
Abgesehen davon, was mache ich wenn ein Interface mehrere Methoden bietet? Muss eine Klasse diese dann alle bereitstellen um in deiner Prüfung anerkannt zu werden?

Und die ClassCastException wie Spacerat sagt kommt weil auch ein Interface intern eine Klasse ist, von welcher vererbt wird. Nur eben verbietet die JLS, dass ein Interface Implementierungen enthält. Quasi ist es vergleichbar mit einer abstrakten Klasse, welche eben keine einzige Methode implementiert.
 

Noctarius

Top Contributor
Hallo,

ihr habt geschrieben, dass Interfaces das sogenannte Ducktyping verhindern sollen. Was versteht man darunter und was ist daran so schlimm? Es geht wohl darum, dass ich annehme wenn ich eine Methode fight() implementiere, dann ist das z.B. immer eine Spielfigur. Also wieso sind Interfaces besser, wo sind die Vorteile? Ich werde ja wohl nicht absichtlich die Fight Methode woanders reinpacken als in eine Spielfigur, um beim Beispiel zu bleiben.

Duck-Typing ? Wikipedia
 
S

Spacerat

Gast
Ich werde ja wohl nicht absichtlich die Fight Methode woanders reinpacken als in eine Spielfigur, um beim Beispiel zu bleiben.
... wieso nicht? Mal rein hypothetisch... Was würde denn ein KI-Spieler machen, wenn ein echter Spieler "besch..."? Nicht etwa "fight();"? Aber genau dieses "fight();" sähe dann doch wohl etwas anders aus. z.B. KI nimmt Spielfigur und bewirft damit den echten Spieler.
 
Zuletzt bearbeitet von einem Moderator:

0x7F800000

Top Contributor
Hallo,

ihr habt geschrieben, dass Interfaces das sogenannte Ducktyping verhindern sollen. Was versteht man darunter und was ist daran so schlimm? Es geht wohl darum, dass ich annehme wenn ich eine Methode fight() implementiere, dann ist das z.B. immer eine Spielfigur. Also wieso sind Interfaces besser, wo sind die Vorteile? Ich werde ja wohl nicht absichtlich die Fight Methode woanders reinpacken als in eine Spielfigur, um beim Beispiel zu bleiben.
Ducktyping ist das was du beschreibst: mutmaßung über funktionalität anhand methodennamen. Es soll nicht durch Interfaces "verhindert" werden, es ist einfach ein paradigma, von dem Java (imho: zum Glück) kein Gebrauch macht.
Bei allen möglichen Skriptsprachen ist das freilich anders, von den arbeiten sehr viele mit ducktyping, was für kleinere Skripts auch angebracht ist, und einem wirklich schlicht und einfach ein bisschen schreibarbeit erspart.
Den Luxus kann sich aber eine die gigatonnenschwere Sprache wie Java mit ihren 50000 Klassen in der API einfach nicht leisten, weil alles im Chaos enden würde. Wie gesagt, ich find's sogar immer noch zu mehrdeutig.;(

Was beim ducktyping schnell schief laufen kann habe ich versucht am Beispiel mit TreeSet zu demonstrieren, diesen fandest du wohl weniger einleuchtend oder wie?...:bahnhof:
 
Zuletzt bearbeitet:

tfa

Top Contributor
ihr habt geschrieben, dass Interfaces das sogenannte Ducktyping verhindern sollen. Was versteht man darunter und was ist daran so schlimm? Es geht wohl darum, dass ich annehme wenn ich eine Methode fight() implementiere, dann ist das z.B. immer eine Spielfigur. Also wieso sind Interfaces besser, wo sind die Vorteile? Ich werde ja wohl nicht absichtlich die Fight Methode woanders reinpacken als in eine Spielfigur, um beim Beispiel zu bleiben.

Also erstmal ist Duck-Typing nicht schlechter oder besser als Interfaces. Nur anders. Vor- und Nachteile hat beides. Der Vorteil der statischen Typisierung ist eben, dass viele Probleme schon vom Compiler erkannt werden können und nicht erst zur Laufzeit. Bei dynamischer Typisierung ist das nicht möglich. Hier muss man eben besonders viel Wert legen auf ausgiebige Unit-Tests, was natürlich auch nicht schlecht ist.
 

knowledge

Bekanntes Mitglied
>Was beim ducktyping schnell schief laufen kann habe ich versucht am Beispiel mit TreeSet zu demonstrieren, diesen >fandest du wohl weniger einleuchtend oder wie?

Naja, nicht so richtig. Ich mein ich lese doch in der API was die Klassen machen und wähle dann aus, oder nicht? Du gingst davon aus, dass da nicht richtig aufgepasst/gelesen wird, oder?

>Der Vorteil der statischen Typisierung ist eben, dass viele Probleme schon vom Compiler erkannt werden können und >nicht erst zur Laufzeit.

Was sind das für Probleme? Wäre Prima wenn du da ein (einfaches) Beispiel wählen könntest um diese zu veranschaulichen. Denn wenn ich das verstanden habe, dann dürfte ja auch das mit den Interfaces klar sein ;-)
 

Noctarius

Top Contributor
Naja, nicht so richtig. Ich mein ich lese doch in der API was die Klassen machen und wähle dann aus, oder nicht? Du gingst davon aus, dass da nicht richtig aufgepasst/gelesen wird, oder?

Und wenn ich meine Methode jetzt trotzdem actionPerformed nenne? ;)
 

tfa

Top Contributor
>Der Vorteil der statischen Typisierung ist eben, dass viele Probleme schon vom Compiler erkannt werden können und >nicht erst zur Laufzeit.

Was sind das für Probleme?
Einfach die Typsicherheit.

[HIGHLIGHT="Java"]//Statisch:
TierInterface variableDieNurTiereEnthaltenKann = new Hund(); // geht! Hund implements TierInterface
TierInterface variableDieNurTiereEnthaltenKann = new Apfelbaum(); // Compilerfehler

//Dynamisch:
variableDieNurTiereEnthaltenSoll1 = new Hund(); // geht
variableDieNurTiereEnthaltenSoll2 = new Apfelbaum(); // geht auch. kein Fehler

variableDieNurTiereEnthaltenSoll1.gassiGehen(); // Tier geht gassi
variableDieNurTiereEnthaltenSoll2.gassiGehen(); // Boing! Laufzeitfehler
[/HIGHLIGHT]
 

0x7F800000

Top Contributor
Ich mein ich lese doch in der API was die Klassen machen und wähle dann aus, oder nicht? Du gingst davon aus, dass da nicht richtig aufgepasst/gelesen wird, oder?
Das ist doch genau der Punkt.
Wenn du beim Ducktyping was übersiehst, kann es sein, dass das Programm zu laufen scheint, obwohl es schlicht und einfach Schrott ist, und dann musst du womöglich zwei Stunden vor der Auslieferung des Programms an den Kunden mit roten Augen da sitzen und panisch nach einem schwer auffindbaren Fehler suchen... Und zwar nur weil du vom Verhalten irgendeiner Klasse was falsches angenommen hast, während diese sich an eigene paketspezifische Konventionen hält.

Bei Interfaces wird der Fehler dagegen direkt beim eintippen vom Compiler rot angestrichen.

Rate mal, was für die Nerven schonender ist.
 

tfa

Top Contributor
Rate mal, was für die Nerven schonender ist.
Möglicherweise erzieht Ducktyping ja dazu, mehr und bessere Unit-Tests zu schreiben. Vielleicht macht man so dann weniger Fehler bzw. findet sie eher (nicht nur die Typfehler), als bei einer statischen Sprache, die einem (vermeindliche) Sicherheit durch den Compiler vorgaukelt.
Ich würde das nicht so verteufeln. Obwohl ich auch haufenweise Typfehler verursacht habe, als ich vor einiger Zeit mal mit Ruby rumbastelte -- natürlich ganz ohne Unit-Tests :)
 

KSG9|sebastian

Top Contributor
Oh man, vielleicht solltest du mit den Java Specification Leads diskutieren und denen erklären dass Interfaces quatsch sind.
Im Endeffekt würde es nicht reichen nur Ducktyping "zu aktivieren". Damit würde ein sehr großer Teil der Typisierung wegfallen, bzw. wahrscheinlich sogar die Typisierung komplett. Dann benennen wir noch ein paar Keywords um, ändern ein bisschen die Struktur und tatatata: Wir haben Java Groovy/JRuby gemacht - herzlichen Glückwunsch.

Diese Diskussion ist absolut sinnlos. Fakt ist: Es GIBT Interfaces in Java, es gibt KEIN Ducktyping in Java, es GIBT typisierung zur Compilezeit in Java. Das sind alles Fakten, die haben allesamt auch ihren Sinn. Ist ja nicht so dass mal irgendein Entwickler drauf kam dass so zu machen weil ihm grade danach war. Die "Kritikpunkte" sind ein Großteil der Kriterien die eine Scriptsprachen von Java/C++ u.s.w. unterscheiden.

Als nächstes können wir dann drüber diskutieren dass das Schlüsselword "class" eigentlich auch nutzlos ist weil ich ja genauso den Dateinamen nennen könnte. Ist ja schließlich redundante Information, wer braucht das schon. Oder wer braucht überhaupt noch Klassen. Wäre es nicht cooler eine generische Klasse zu haben die alles sein kann.

Code:
Generic gen = new Generic();

// ich glaub ich will mal was rechnen
Generic result = gen.add(1, 18);

// urgh, falsch..eigentlich wollte ich was einlsen
Generic input = new Generic().readFromConsole();

// urgh, wieder nix, was wollt ich nochmal tun..mhhh
Generic unknown = gen.doWhatIWant();

Schließlich ist es doch quatsch tausende von Klassen zu schreiben. Eine generische Klasse könnte doch einfach auf alle Klassen im Classloader deligieren. Schließlich sind die Methodennamen (nach der Diskussion von oben) ja eindeutig, somit kann doch die generische Klasse alles kennen..wär doch viel toller. Und dann noch ein bisschen Chained Invocation

Code:
new Generic().readText().fromConsole().andIfItFails().askYourself().what().toDo();
 
Zuletzt bearbeitet:
M

maki

Gast
>> Rate mal, was für die Nerven schonender ist.

Wenn interessiert es, wenn der Code kompliliert aber nicht das macht was er soll? ;)
Ohne autom. Tests steht es nie gut um deine Nerven.
 

0x7F800000

Top Contributor
tfa hat gesagt.:
Möglicherweise erzieht Ducktyping ja dazu, mehr und bessere Unit-Tests zu schreiben. Vielleicht macht man so dann weniger Fehler bzw. findet sie eher (nicht nur die Typfehler), als bei einer statischen Sprache, die einem (vermeindliche) Sicherheit durch den Compiler vorgaukelt.
Ich würde das nicht so verteufeln. Obwohl ich auch haufenweise Typfehler verursacht habe, als ich vor einiger Zeit mal mit Ruby rumbastelte -- natürlich ganz ohne Unit-Tests

Wieso verteufeln? Ich hab doch wohl oft genug gesagt, dass ich das für "kleinere" Sachen in Skriptsprachen für recht sinnvoll halte. Das ist zur Abwechslung sogar irgendwie erfrischend, wenn man hin und wieder mit Ducktyping arbeitet. Aber wenn man ausführliche Unittests schreibt, dann sollte man sich wirklich nicht über "zuviel Schreibaufwand" beschweren, schließlich tragen die Unittests zur Funktionalität des Endproduktes quasi nichts bei, sind so zu sagen "zum wegwerfen"... Also, wenn man sich schon bei dem einen Wörtchen "implements" so lange über zuviel Schreibaufwand beschwert, dann sieht es für die Unittests wohl ganz düster aus...:autsch:
 
M

maki

Gast
Wieso verteufeln? Ich hab doch wohl oft genug gesagt, dass ich das für "kleinere" Sachen in Skriptsprachen für recht sinnvoll halte. Das ist zur Abwechslung sogar irgendwie erfrischend, wenn man hin und wieder mit Ducktyping arbeitet. Aber wenn man ausführliche Unittests schreibt, dann sollte man sich wirklich nicht über "zuviel Schreibaufwand" beschweren, schließlich tragen die Unittests zur Funktionalität des Endproduktes quasi nichts bei, sind so zu sagen "zum wegwerfen"... Also, wenn man sich schon bei dem einen Wörtchen "implements" so lange über zuviel Schreibaufwand beschwert, dann sieht es für die Unittests wohl ganz düster aus...:autsch:
Nicht wirklich, Unittests können sogar helfen weniger Produktivcode zu schreiben, und zum "wegwerfen" sind sie schon mal gar nicht.
"nichts beitragen" ist auch nicht richtig, in TDD ist Testen eine Designaktivität.
Und schliesslich kann man kein komplexes System ohne autom. Tests schreiben, wenn man irgendein Interesse an Qualität bzw. Terminen hat.
Lustigerweise erübrigt sich debuggen zu 90% mit Unittests.

Alles in allem sparen Unittests Nerven & Zeit, wenn man sie richtig macht.
 

0x7F800000

Top Contributor
Nicht wirklich, Unittests können sogar helfen weniger Produktivcode zu schreiben
Diese eine Aussage verstehe ich nicht wirklich, um ehrlich zu sein.

Mit allen anderen Aussagen bin ich ntürlich einverstanden, was ich sagen wollte ist: man kann dem endgültigen code nicht ansehen, wieviele tests damit durchgeführt werden. Wären alle Programmierer Genies, und würden sie niemals Fehler machen, so wären Unittests wirklich nur "unnötiger code", der eben nichts zur Funktionalität des Programms beiträgt. Das meinte ich.

Dass nicht alle Programmierer genies sind, bzw dass einfach jeder dauernd Fehler macht ist mir schon klar... ;)
Alles in allem sparen Unittests Nerven & Zeit, wenn man sie richtig macht.
Tun die Interfaces im vergleich zum Ducktyping imho auch...

es wird vielleicht der Tag kommen, wann solche Threads in die Plauderecke geschoben werden :D Da gehören die imho hin^^
 
Zuletzt bearbeitet:
S

Spacerat

Gast
Zu viel Schreibaufwand wirds doch erst wenn man sich in einem 3-Seiten-Thread darüber unterhält. Ich sag abschliessend (für mich abschliessend) dazu... Schön das es Interfaces und die damit verbundene Typsicherheit gibt! Definitiv besser als
Code:
$ergebnis = "1 Apfel" + "3 Birnen"; // $ergebnis = 4 (!)
Wer soll denn damit was anfangen können?

@Edit: ...ich hab' da was von abschliessend gefaselt, deshalb hab' ich's mal markiert. Ob ich da nun schwache (bis gar keine) und starke dynamische Typisierung verwechsle ist mir dabei völlig Hupe. Fakt ist doch, dass die Typsicherheit die Java nicht zuletzt durch Interfaces bietet, diesen "BLÖDSINN" von vornherein ausschliesst. Interfaces sind deswegen eben alles andere als "Schreibaufwand".
 
Zuletzt bearbeitet von einem Moderator:

tfa

Top Contributor
Zu viel Schreibaufwand wirds doch erst wenn man sich in einem 3-Seiten-Thread darüber unterhält. Ich sag abschliessend (für mich abschliessend) dazu... Schön das es Interfaces und die damit verbundene Typsicherheit gibt! Definitiv besser als
Code:
$ergebnis = "1 Apfel" + "3 Birnen"; // $ergebnis = 4 (!)
Wer soll denn damit was anfangen können?
Ich glaub, jetzt verwechselst du dynamische Typisierung mit schwacher Typisierung. Äpfel und Birnen ineinander zu schmeißen ist natürlich Blödsinn.
 
M

maki

Gast
Diese eine Aussage verstehe ich nicht wirklich, um ehrlich zu sein.
Klingt seltsam, aber wenn man es mal probiert hat versteht man besser ;)

"dead code", "overdesigned", redundanzen etc. pp. sind Dinge, die sich verhindern bzw. korrigieren lassen.
TDD ist natürlich extermer (stammt aus XP), geht in Richtung "lean development".

Tun die Interfaces im vergleich zum Ducktyping imho auch...
Wie gesagt, was nutzt es wenn man den Code zwar kompilieren kann, er aber nicht so funzt wie er sollte?

was ich sagen wollte ist: man kann dem endgültigen code nicht ansehen, wieviele tests damit durchgeführt werden.
Nun ja, wenn man Unittest hat, kann man auch refactoren und das Design "geradeziehen" welches im Zuge der "normalen" Entwicklung ("wildwuchs") verhunzt wurde.
Das gut zu testender Code auch ein gutes Design ausweist ist mittlerweile anerkannt.
Man kann auf jedenfall erkennen wenn Code nicht getestet wurde ;)
 

Noctarius

Top Contributor
Oh man, vielleicht solltest du mit den Java Specification Leads diskutieren und denen erklären dass Interfaces quatsch sind.
Im Endeffekt würde es nicht reichen nur Ducktyping "zu aktivieren". Damit würde ein sehr großer Teil der Typisierung wegfallen, bzw. wahrscheinlich sogar die Typisierung komplett. Dann benennen wir noch ein paar Keywords um, ändern ein bisschen die Struktur und tatatata: Wir haben Java Groovy/JRuby gemacht - herzlichen Glückwunsch.

Diese Diskussion ist absolut sinnlos. Fakt ist: Es GIBT Interfaces in Java, es gibt KEIN Ducktyping in Java, es GIBT typisierung zur Compilezeit in Java. Das sind alles Fakten, die haben allesamt auch ihren Sinn. Ist ja nicht so dass mal irgendein Entwickler drauf kam dass so zu machen weil ihm grade danach war. Die "Kritikpunkte" sind ein Großteil der Kriterien die eine Scriptsprachen von Java/C++ u.s.w. unterscheiden.

Als nächstes können wir dann drüber diskutieren dass das Schlüsselword "class" eigentlich auch nutzlos ist weil ich ja genauso den Dateinamen nennen könnte. Ist ja schließlich redundante Information, wer braucht das schon. Oder wer braucht überhaupt noch Klassen. Wäre es nicht cooler eine generische Klasse zu haben die alles sein kann.

Code:
Generic gen = new Generic();

// ich glaub ich will mal was rechnen
Generic result = gen.add(1, 18);

// urgh, falsch..eigentlich wollte ich was einlsen
Generic input = new Generic().readFromConsole();

// urgh, wieder nix, was wollt ich nochmal tun..mhhh
Generic unknown = gen.doWhatIWant();

Schließlich ist es doch quatsch tausende von Klassen zu schreiben. Eine generische Klasse könnte doch einfach auf alle Klassen im Classloader deligieren. Schließlich sind die Methodennamen (nach der Diskussion von oben) ja eindeutig, somit kann doch die generische Klasse alles kennen..wär doch viel toller. Und dann noch ein bisschen Chained Invocation

Code:
new Generic().readText().fromConsole().andIfItFails().askYourself().what().toDo();

<ironie>Klingt genial</ironie>
 
S

Spacerat

Gast
Jetzt muss ich doch noch mal...
[totalsinnfrei]Wr unbedingt eine dermassen generische Klasse haben will soll doch einfach "null" verwenden. Die "Klasse" ist so extrem generisch, das sie stets nur ein einziges Ergebnis liefert... -> "NullPointerException"[/totalsinnfrei]
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
J Methodenaufrufe abstrakte Klassen, Interfaces Java Basics - Anfänger-Themen 17
M Wozu dient Interfaces? Java Basics - Anfänger-Themen 6
O Mehrfachvererbung auf Spezifikations- und Implementierungsebene in Java. Interfaces Java Basics - Anfänger-Themen 19
U Funktionale Interfaces mit mehreren abstrakten Methoden? Java Basics - Anfänger-Themen 8
M Interfaces Aufgabe Java Basics - Anfänger-Themen 2
I JSON / XML Struktur mit Vererbung / Interfaces Java Basics - Anfänger-Themen 0
I XML und Interfaces aus anderen Projekten Java Basics - Anfänger-Themen 3
8u3631984 Record - Interfaces Java Basics - Anfänger-Themen 4
M Wie kann ich in einem Konstruktor die Methode eines anderen Interfaces mit den jeweiligen Parametern aufrufen? Java Basics - Anfänger-Themen 8
H Sinn von Interfaces Java Basics - Anfänger-Themen 21
B JaxB und Interfaces? Java Basics - Anfänger-Themen 2
M Funktionale Interfaces Java Basics - Anfänger-Themen 3
Kirby.exe Frage zur Verwendung von Interfaces Java Basics - Anfänger-Themen 6
H Frage zu interfaces Java Basics - Anfänger-Themen 1
J Zweck von Interfaces immer noch nicht klar Java Basics - Anfänger-Themen 3
M Klasse erbt von Interfaces Java Basics - Anfänger-Themen 6
T Interfaces in erbenden Klassen Java Basics - Anfänger-Themen 2
T Abstrakte Klasse und Interfaces Java Basics - Anfänger-Themen 12
H Polymorphie Interfaces und statischer Typ Java Basics - Anfänger-Themen 33
T Verständnisfrage zu Interfaces Java Basics - Anfänger-Themen 7
F Exceptions in Interfaces Java Basics - Anfänger-Themen 4
F Interface Warum Interfaces? Java Basics - Anfänger-Themen 5
R interfaces Java Basics - Anfänger-Themen 1
B Interfaces Java Basics - Anfänger-Themen 6
A Vererbung/Interfaces/Generics Java Basics - Anfänger-Themen 12
D Interface Wieso Aufruf aller Methoden eines Interfaces? Java Basics - Anfänger-Themen 11
J Interfaces? Java Basics - Anfänger-Themen 32
M Erstellung Interfaces....totale Anfängerfrage Java Basics - Anfänger-Themen 16
S Erste Schritte Innere Klassen und Interfaces Java Basics - Anfänger-Themen 2
J Wofür dienen Interfaces ? Java Basics - Anfänger-Themen 1
Hijo2006 Frage zu Interfaces Java Basics - Anfänger-Themen 21
Hacer Interfaces implementieren Java Basics - Anfänger-Themen 7
H Implementierung eines Interfaces erweitern Java Basics - Anfänger-Themen 13
L Via Interfaces unterschiedliche Klassen ansprechen Java Basics - Anfänger-Themen 8
A Verwendung von Interfaces Java Basics - Anfänger-Themen 7
J Interfaces Java Basics - Anfänger-Themen 15
D Frage bzgl. Interfaces Java Basics - Anfänger-Themen 10
D Interface Verständnisprobleme von Interfaces Java Basics - Anfänger-Themen 5
D Interface Interfaces und abstrakte Klassen implementieren Java Basics - Anfänger-Themen 4
S Rollen verändern, Interfaces austauschen wie? Java Basics - Anfänger-Themen 10
K Interfaces/Klassen etc. Java Basics - Anfänger-Themen 6
F Implementierung von Interfaces -> Problem mit main Java Basics - Anfänger-Themen 12
S Verständnisproblem bei Interfaces Java Basics - Anfänger-Themen 6
I Interface Verständnisfrage Interfaces (Bsp.: Enumeration) Java Basics - Anfänger-Themen 2
M Frage zu Generics in Klassen, Abstrakten Klassen und Interfaces Java Basics - Anfänger-Themen 5
O Java Interfaces für andere Programmiersprachen zur Verfuegung stellen? Java Basics - Anfänger-Themen 2
K Interface Generics, Interfaces und Listen - ich bin verwirrt. Java Basics - Anfänger-Themen 7
G Instanzen eines Interfaces erzeugen Java Basics - Anfänger-Themen 7
M Compiler-Fehler Alle Methoden eines Interfaces Implementiert dennoch Fehler Java Basics - Anfänger-Themen 3
V Interface Interfaces und abstrakte Klassen Java Basics - Anfänger-Themen 3
F Best Practice UML/Planung eines Projektes (Klassen, Interfaces, ...) Java Basics - Anfänger-Themen 0
V Vererbung Vererbung, Interfaces und OOP... Java Basics - Anfänger-Themen 10
C Sinn eines Interfaces? Java Basics - Anfänger-Themen 4
A Interface Poymorphismus bei Interfaces Java Basics - Anfänger-Themen 2
Pentalon Eclipse JUNO keine Vorschläge von Methoden bzw. Interfaces der eigenen Klassen Java Basics - Anfänger-Themen 5
R Mehrere Interfaces(Comparable, ...) Java Basics - Anfänger-Themen 2
J Interfaces Abstrakte Klassen Java Basics - Anfänger-Themen 15
D Interfaces und allgemeingültige Methodenaufrufe Java Basics - Anfänger-Themen 6
H Erste Schritte 2 User Interfaces für eine Anwendung Java Basics - Anfänger-Themen 7
S OOP Wann Proxies und Interfaces? Java Basics - Anfänger-Themen 3
M Interface @Inject mit Interfaces? Java Basics - Anfänger-Themen 2
F Interface Unterschied von Attributen und Methoden bei abstrakten Klassen und Interfaces Java Basics - Anfänger-Themen 5
V mehrfachvererbung unter interfaces Java Basics - Anfänger-Themen 10
J Interface Wie funktioniert das mit den Interfaces. Ich verstehe es einfach nicht! :( Java Basics - Anfänger-Themen 15
T Interfaces und Implementierungen Java Basics - Anfänger-Themen 12
S Interface mehrere Interfaces Java Basics - Anfänger-Themen 2
M Vererbung Problem bei Interfaces Java Basics - Anfänger-Themen 8
H Dynamische Bindung mit Interfaces und LinkedList Java Basics - Anfänger-Themen 7
F Interfaces Java Basics - Anfänger-Themen 4
M Frage zu Interfaces Java Basics - Anfänger-Themen 3
N Generics und Interfaces Java Basics - Anfänger-Themen 5
D Abstrakte Klassen und Interfaces als Paramter in Funktionen Java Basics - Anfänger-Themen 3
P OOP Aufruf eines Interfaces Java Basics - Anfänger-Themen 4
N OOP Vererbung von Interfaces Java Basics - Anfänger-Themen 12
S Verständnisfrage zu Interfaces Java Basics - Anfänger-Themen 2
D Sinn von Interfaces - Wozu? Java Basics - Anfänger-Themen 9
P Frage zu Interfaces Bsp. Java Basics - Anfänger-Themen 9
A Deklarationen in abstrakten Klassen und Interfaces Java Basics - Anfänger-Themen 11
R Adapterklassen vs Interfaces Java Basics - Anfänger-Themen 6
P Interfaces -> eins oder mehrere für eine Anwendung? Java Basics - Anfänger-Themen 9
2 Interfaces, Polymorphie und Methoden. Java Basics - Anfänger-Themen 14
A Obstlager Interfaces Java Basics - Anfänger-Themen 7
K Theor. Frage zu Interfaces Java Basics - Anfänger-Themen 30
T Frage zu Interfaces und Abstrakten Klassen Java Basics - Anfänger-Themen 4
J Interfaces Java Basics - Anfänger-Themen 14
L Interfaces Java Basics - Anfänger-Themen 5
J spiel "Gefangenendilemma" Probleme mit Interfaces Java Basics - Anfänger-Themen 8
H Interfaces in java? Java Basics - Anfänger-Themen 2
A OOP Interfaces mit gleichem Methoden Java Basics - Anfänger-Themen 15
T Interfaces: Braucht man abstrakte Klassen eigentlich noch? Java Basics - Anfänger-Themen 3
S Implementierung gegen Interfaces / List, ArrayList, LinkedList Java Basics - Anfänger-Themen 11
D Interfaces / Schnittstellen Java Basics - Anfänger-Themen 8
I Probleme mit Interfaces Java Basics - Anfänger-Themen 4
I Interfaces Java Basics - Anfänger-Themen 34
bigbasti Warum genau braucht man Interfaces? Java Basics - Anfänger-Themen 10
A Programmieren gegen Interfaces Java Basics - Anfänger-Themen 4
I Frage zu Collection und List Interfaces Java Basics - Anfänger-Themen 2
7 Interfaces - Aufbau Java Basics - Anfänger-Themen 9
G Interfaces mit gleichen Methoden Java Basics - Anfänger-Themen 4
U Interfaces und ihre Daseinsberechtigung Java Basics - Anfänger-Themen 4

Ähnliche Java Themen

Neue Themen


Oben