Theor. Frage zu Interfaces

[knowledge]

Hallo,

ich habe eine theoretische Frage zu Interfaces. Klassen die ein Interface implementieren müssen die vom Interface vorgegebenen Methoden ja konkretisieren. Bsp.

interface SchachSpielfigur { kämpfe(); }

Angenommen eine andere Methode erwartet nun als Parameter eine SchachSpielfigur dann müsste diese ja die Methode kämpfe() anbieten. Könnte der Compiler nicht einfach prüfen ob ein übergebenes Objekt die Methode kämpfe() anbietet auch ohne das man immer explizit implements SchachSpielfigur angeben müste?

Was ich meine:

Angenommen wir haben eine Klasse Bauer implements SchachSpielfigur. Hier konkretisiere ich die kämpfe Methode. Wäre es rein theoretisch aber nicht möglich das ich einfach in der Klasse Bauer ohne implements SchachSpielfigur eine kämpfe Methode erstelle. Wenn ich Bauer nun irgendwo als "SchachSpielfigur" nutzen wöllte müsste der Compiler doch nur prüfen ob Bauer eine kämpfe Methode anbietet. Das könnte er doch auch ohne das ich Bauer explizit mit implements Schachfigur "markiere".

Wo wäre ein Nachteil zu sehen wenn einfach jedes Objekt zulässig wäre was eine kämpfe Methode anbietet? Der Compiler könnte doch sowas immer prüfen auch ohne das ich Klassen explizit durch ein Interface markiere. Ala wenn das übergebene Objekt eine kämpfe Methode anbietet wird es als SchachSpielfigur betrachtet, um beim obigen Bsp. zu bleiben...

 

[Atze]

es ist doch sinn des interfaces sicherzustellen, dass das entsprechende objekt die methode implementieren muss. woher soll der kompiler denn sonst wissen, ob es die richtige methode ist? es kann doch auch ein ork übergeben werden, der auch kämpfen kann, aber auf nem schachbrett nix zu suchen hat. soll er die methode am namen nach erkennen und das objekt akzeptieren, egal ob es vom typ schachfigur ist, oder nicht?

du könntest ja auch eine oberklasse "schachfigur" erzeugen und bauer davon erben lassen. dann ist aber nicht sichergestellt, dass bauer die methode auch wirklich überschreibt. dann kämpft im schlimmsten fall jede schachfigur nach dem gleichen muster. oder du machst schachfigur abstrakt

 

[knowledge]

Hi,

als Programmierer weiß ich doch aber das eine Schachfigur die Methode "kämpfen" besitzen muss. Der Compiler muss doch theoretisch nur schauen ob das Objekt die Methode kämpfen besitzt. Als Programmierer werde ich doch wissen das kein Org übergeben werden kann, auch wenn er kämpfen kann. Der Compiler würde einen Org (der kämpfen) kann zwar aktzeptieren, ich als Programmierer werde doch aber keinen Org übergeben, sondern nur Schachfiguren. Die müsssen kämpfen können. Ich könnte mir doch also die Zeile implements SchachFigur sparen. Wenn ich eine Schachfigur übergebe und diese nicht kämpfen kann meckert der Compiler ja trotzdem noch rum...

 

[knowledge]

Nachtrag: Also wieso sollte ich als Programmierer einen Org übergeben wollen? Ich sehe an der Stelle ja hier brauch ich ne Schachfigur. Das diese kämpfen implementiert stellt der Compiler ja trotzdem noch sicher...

 

[Atze]

Als Programmierer werde ich doch wissen das kein Org übergeben werden kann, auch wenn er kämpfen kann. Der Compiler würde einen Org (der kämpfen) kann zwar aktzeptieren, ich als Programmierer werde doch aber keinen Org übergeben, sondern nur Schachfiguren.

dann ist doch alles ok. wie willst du das dem kompiler denn auch anders sagen, als mit dem interface / der oberklasse als parameter? das heißt doch nichts anderes als "ich akzeptiere nur ein objekt, dass folgende methoden hat!".
ob das jetzt "objekt mit methodeXYZ" oder "Schachfigur figur" heißt, da ist das zweite sogar simpler? wie würdest du das deinem compiler denn sonst mitteilen wollen? und wenn programmierer immer drauf achten würden was sie übergeben, dann brauchten wir keine parametertypisierung und wären bei javascript! *scherz*

 

[Final_Striker]

Weil man in der Regel nicht alleine programmiert und nicht immer alles wissen kann. Woher soll jemand anderes, der dein Programm erweitern will, wissen, dass eine Figur eine kämpfe Methode haben muss?

 

[knowledge]

"ich akzeptiere nur ein objekt, dass folgende methoden hat!".

Ja, das meinte ich ja auch. Der Compiler aktzeptiert in meinem Ansatz jedes Objekt welches eine kämpfen Methode hat. Ich sehe an der Signatur "aha Schachfigur". Als Programmierer würde ich an dieser Stelle doch keinen Org übergeben, um beim Bsp. zu bleiben. Ich meine was nützt das "markieren" mittels implements SchachFigur? Warum wird nicht einfach jedes Objekt (jede Schachfigur) akzeptiert die eine kämpfen Methode hat? Warum sollte ich denn als Programmierer andere Objekte als Schachfiguren übergeben? Ich will mir quasi nur das implements SchachFigur sparen...

Ala

interface SchachFigur { kämpfen(); }
class Bauer { kämpfen() { // bauer kämpft }
class Turm { kämpfen() { // turm kämpft }
class Springer { // hier FEHLT kämpfen}


Wenn jetzt eine Methode eine SchachFigur erwartet dann würde der Compiler Bauer und Turm akzeptieren (implementieren beide die Methode "kämpfen"), den Springer aber nicht (kämpfen fehlt).

Ich hätte noch immer eine Erkennung ob die Methode bei dem Objekt vorhanden ist...

 

[knowledge]

Nachtrag: Ich schau als Programmierer nach was muss die SchachFigur können, aha kämpfen. Implementiere die Methode nur "markiere" nicht den Bauer mittels implements SchachFigur. Compiler prüft kann übergebenes Objekt kämpfen, falls ja Schachfigur...
Und wie gesagt warum sollte ich an solch eine Stelle einen Org übergeben? Das eine SchachFigur kämpfen soll konnte ich ja beim Interface nachschlagen. Ich hab jetzt lediglich drauf verzichtet z.B. den Bauern als SchachFigur zu markieren...

 

[Atze]

hab das schon verstanden, aber wie willst du das dem compiler sagen? woher soll er wissen, dass du nur objekte mit der bestimmten methode haben willst? momentan sieht die signatur der methode dann so aus

methode(Schachfigur figur)

und die entsprechenden klassen sind mit dem interface (mit dem du die benötigten methoden festlegst) markiert

und wie hättest du's gerne? also wie würdest du die methode signieren, damit dein compiler die richtigen objekte zulässt und die falschen abweist? abgesehen davon, wenn du als programmierer eh nur die richtigen objekte übergibts, bräuchtest du so eine überprüfung ja garnicht mehr. dann signiere die methode mit

methode(Object object)

caste einfach auf gut glück, und ruf die methode auf

 

[Illuvatar]

Ich glaube, in groovy kann man zum Beispiel ein Objekt irgendwie in ein Interface casten, wenn die richtigen Methoden implementiert sind. Ich bin mir aber nicht mehr ganz sicher und finds auch grad nicht mehr.

 

[MrWizenly]

Hallo,

was Atze sehr schön andeutet ist wirklich wichtig zu verstehen, man kann den Compiler so arbeiten lassen wie Du möchtest, Du definierst eine Methode, welche ein Objekt akzeptiert, dass die Methode kämpfe beinhaltet und jedes Objekt mit so einer Methode wird akzeptiert.

Das Problem ist, dass Du auf eine Prüfung durch den Compiler verzichtest. Zwar kann der ohne weiteres schauen ob eine Methode mit vorgebener Signatur existiert, aber was ist wenn Du einen unglücklichen Konflikt vorliegen hast? Jeder hat sich schon mal vertippt und jedem passieren Fehler. In großen Teams, großen Programmen oder auch bei der Verwendung von Bibliotheken kann es schon mal vorkommen, dass zwei Objekte eine Methode mit gleichem Namen und völlig unterschiedlicher Semantik haben.

Ein einfaches Beispiel, wie haben keine Schachfigur sondern das Interface Db. Dieses muss von Objekten implementiert werden, die auf eine DB zugreifen wollen und eine der Methoden heißt init() und stellt sicher, dass eine Verbindung zur Datenbank aufgebaut wird. Dass andere Interfaces auch ein init() deklarieren ist plausibel, oder?
Was also passiert jetzt, wenn ich mit einem Objekt starte, dass zwar eine Datei initialisiert, aber nie die DB-Verbindung herstellt (hat aber eine Init-Methode und ich habe es wegen einem Tippfehler an die falsche Methode übergeben). Das merkt der Compiler nicht und der Zugriff der danach auf die DB folgt scheitert (da keine Verbindung existiert).

Natürlich fallen solche Fehler leicht auf wenn es kracht und die lassen sich dann super schnell im Debugger finden. Was aber wenn Du an vielen Stellen das korrekt Objekt übergibst und nur eine seltene Stelle den Tippfehler enthält? Da kracht es dann im Produktivbetrieb beim Kunden, ein Debugger läuft da nicht und Dein Ruf ist auch hin. Ist alles etwas schwarz gemalt, ein gutes Design mag das schon verhindern, aber die zusätzliche Sicherheit durch diese starke Typbindung erhöht die Qualität halt auch. Wenn man den Nutzen von ein paar Zeichen mehr die man Tippt (und die Codevervollständigung nimmt einem doch auch einen Teil ab) den Kosten (wenige Sekunden) gegenüberstellt, dann sollte einem auch klar sein warum die strenge Typbindung von Java eher ein Feature ist.
Alternativ empfiehlt sich dann eben eine Skriptsprache, da kann man mit viel weniger Zeichen zum Ergebnis kommen, hat es aber auch viel schwerer weil unsichere Typisierung zu einfach vermeidbaren Fehlern führt

 

[knowledge]

Hallo,

danke für die bisherigen Antworten

"...und ich habe es wegen einem Tippfehler an die falsche Methode übergeben..."

Unter Tippfehler verstehst du das ich ein Objekt übergebe was die Methode implementiert, aber etwas völlig anderes tut als erwartet da es halt nicht das "richtige" Objekt ist? D.h. es soll vermieden werden das ich irgendwann "ausversehen" ein Objekt übergebe was die Methode implementiert, semantisch aber was anderes tut?

 

[Atze]

ja, das ist halt praktisch, versteh nicht warum du so auf kriegsfuß damit bist

Ich glaube, in groovy kann man zum Beispiel ein Objekt irgendwie in ein Interface casten, wenn die richtigen Methoden implementiert sind. Ich bin mir aber nicht mehr ganz sicher und finds auch grad nicht mehr.

hm, vielleicht meinst du auch was anderes als ich, aber das geht doch nicht nur in groovy

List o = (List)new LinkedList();

 

[Painii]

Hallo,

danke für die bisherigen Antworten

"...und ich habe es wegen einem Tippfehler an die falsche Methode übergeben..."

Unter Tippfehler verstehst du das ich ein Objekt übergebe was die Methode implementiert, aber etwas völlig anderes tut als erwartet da es halt nicht das "richtige" Objekt ist? D.h. es soll vermieden werden das ich irgendwann "ausversehen" ein Objekt übergebe was die Methode implementiert, semantisch aber was anderes tut?

Tippfehler: kämpffe() -> deine Schachfigur ist keine Schachfigur mehr.

Andersrum, andere Methoden können auch kämpfe heissen, auch wenn sie nie für dein Schachspiel gedacht waren - wie hält der Compiler das auseinander?


Interfaces geben dir die Möglichkeit dem Compiler zu sagen:
Das Objekt ist eine Schachfigur.
Der Compiler muss dann nicht rumraten welches Objekt zufällig mal eine Schachfigur sein könnte und welche nicht.

Oder noch ein problematisches Beispiel:

interface foo{
 kämpfe();
}

interface bar{
 kämpfe();
}

class A{
 kämpfe(){
 }
}

Wäre A jetzt bar oder foo in deiner Version?

edit:
@ Atze: Geht, weil LinkedList, List implementiert.

class MyOwnList{
 //alle Methoden von List implementieren...
 private static List myList = new MyOwnList(); //MyOwnList hat alle Methoden von List, aber trotzdem geht das nicht in java, so wie oben erklärt würde das dann klappen
}

 

[Atze]

edit:
@ Atze: Geht, weil LinkedList, List implementiert.

class MyOwnList{
 //alle Methoden von List implementieren...
 private static List myList = new MyOwnList(); //MyOwnList hat alle Methoden von List, aber trotzdem geht das nicht in java, so wie oben erklärt würde das dann klappen
}

ok, danke, ich sag ja ich wußte nicht wie ers meint. also meinte illuvatar, dass objekte nicht in einer hierarchie zu einem interface stehen, aber dahin gecastet werden können weil die methoden die gleichen sind? sowas geht in groovy? klingt spannend, aber gefährtlich, eben grad wegen den angesprochenen "seiteneffekten". kennt jemand spontan n anwendungsfall, wo das nötig ist
und / oder n vorteil bringt?

 

[tuxedo]

Nur so am Rande:

Du kannst die Nutzung von Interfaces auch weglassen und eine Implizite Regel, dass eine Methode namens "kaempfe()" vorhanden sein muss, definieren.

Dann musst du allerdings alle Objekte die du in die Hand nimmst per Reflection analysieren ob da eine Methode namens "public void kaempfe()" vorhanden ist, und wenn ja, diese dann aufrufen.

Damit hast du dann die "einfache Logik im Compiler" in "umständliche Logik im Programmcode" verwandelt.

In der Praxis macht man das wohl nur für Sonder-/Spezialfälle. Die Benutzung von Interfaces ist hier doch deutlich einfacher und auch gängiger.

- Alex

 

[Atze]

jo, möglich ist es ja, aber dann muss er diese logik auch in jeder klasse verwenden, und hat ich dafür nur das "implements ..." gespart. ist ja mehr arbeit als vorher

 

[tuxedo]

Eben, deshalb auch mein Einwand:

In der Praxis macht man das wohl nur für Sonder-/Spezialfälle. Die Benutzung von Interfaces ist hier doch deutlich einfacher und auch gängiger.

- Alex

 

[Atze]

so nebenbei, kennt jemand ein sinnvolles beispiel für das groovy-"feature"?

 

[maki]

so nebenbei, kennt jemand ein sinnvolles beispiel für das groovy-"feature"?

Keine aus Groovy, aber SMalltalk zB. arbeitet nur so, da gibt es keine Interfaces wie in Java, wcihtig ist, dass die Methoden da sind.

interface A {
    public void do();
}

interface B {
    public void do();
}

Egal ob ich ein A oder ein B habe, ich kann einfach do() aufrufen.

 

[Atze]

ich meinte n beispiel für nen sinnvollen einsatz! innerhalb einer hierarchie ist das ja noch sinnvoll, aber zwischen zwei völlig unterschiedlichen hierarchien zu switchen, nur weil die methodensignaturen von zwei objekten zufällig gleich sind, find ich nicht so gebräuchlich.
hat das in nem produktivsystem schonmal n einsatz gefunden?

 

[maki]

ich meinte n beispiel für nen sinnvollen einsatz! innerhalb einer hierarchie ist das ja noch sinnvoll, aber zwischen zwei völlig unterschiedlichen hierarchien zu switchen, nur weil die methodensignaturen von zwei objekten zufällig gleich sind, find ich nicht so gebräuchlich.
hat das in nem produktivsystem schonmal n einsatz gefunden?

Wie gesagt, SmallTalk kennt sowas wie Interfaces nicht, da gibt es nur Messages zwischen Objekten
Und ja, es gab mal SmallTalk im Prod. Einsatz, viele Libraries/Konzepte die wir heute in Java und anderen Sprachen wie selbstveständlich nutzen, haben ihren Ursprung in Smalltalk, zB. MVC, xUnit, das erste toolgestützte Refactoring usw.

Ist halt nur schwierig mit den Java Regeln im Hinterkopf aussagen über andere Sprachen zu machen

 

[Atze]

 

[knowledge]

Danke für die zahlreichen Antworten und die angeregt Diskussion. Ich denke es ist nun schon viel klarer. Das mit dem Tippfehler habe ich auf jeden Fall verstanden ;-) Und ist es denn so realistisch das ein Programmierer einen Ork (mit Kämpfe) anstatt einer Schachfigur mit "kämpfe" ausversehen übergibt?

 

[Atze]

nein, das klingt nicht so realistisch, ist nur das erste was mir als beispiel dazu eingefallen ist. ich wollte damit nur sagen, dass du mit deiner variante auch freiwillig (fahrlässig) auf ein stück sicherheit verzichten würdest, da dann nicht nur objekte aus der hierarchie der schachfiguren, sondern alle erdenklichen objekte mit einer kämpfe()-methode (kampfflugzeuge, ninjas, soldaten, todessterne ) übergeben werden könnten. und du brauchst doch auf einem schachbrett nur schachfiguren, warum sollte dann die einschränkung erweitern? nur wegen den paar zeichen "implements Schachfigur"?

wie tuxedo sagte, ginge das über reflection, aber das wäre zusätzliche arbeit, weniger sicherheit und keinen effektiven vorteil.

mehr wollte ich mit dem bauer/ork beispiel nicht sagen.

 

[knowledge]

Ja, prinzipiell habe ich das verstanden. Wär halt schön wenn da noch ein "realistisches" Szenario gekommen wäre. Also wie jemand "ausversehen" ein Objekt übergibt mit einer Methode x. Ala "kämpfe" Bauer/Ork

 

[Gelöschtes Mitglied 5909]

denke mal an methoden wie init(), close() etc...

 

[dunhillone]

Wenn du schwache typisierung bevorzugst, kanst du auch Sachen wie php anfangen.. Du wirst schnell sehen, dass du da in Teufels Küche landest wenn du nicht höllisch aufpasst, wie du die Variable behandelst.

Stells dir vor wie blind fahren auf ner Bergstrasse ohne Leitplanken

 

[0x7F800000]

Du kannst die Nutzung von Interfaces auch weglassen und eine Implizite Regel, dass eine Methode namens "kaempfe()" vorhanden sein muss, definieren.

Dann musst du allerdings alle Objekte die du in die Hand nimmst per Reflection analysieren ob da eine Methode namens "public void kaempfe()" vorhanden ist, und wenn ja, diese dann aufrufen.

Damit hast du dann die "einfache Logik im Compiler" in "umständliche Logik im Programmcode" verwandelt.

Hier zur Abschreckung ein Beispiel:

package basicperformance;

import static java.lang.System.*;
import java.lang.reflect.*;

interface Duck{
	void walk();
	void quack();
}

class DuckCaster{
	public static Duck cast(final Object o) throws SecurityException, NoSuchMethodException{
		
		final Class<?> oClass = o.getClass();
		for(Method interfaceMethod:Duck.class.getMethods()){
			Method oMethod = oClass.getMethod(interfaceMethod.getName(),interfaceMethod.getParameterTypes());
			oMethod.setAccessible(true);
		}
		
		return new Duck(){
			@Override public void walk(){
				try {
					oClass.getMethod("walk").invoke(o);
				} catch (IllegalArgumentException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				} catch (SecurityException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				} catch (IllegalAccessException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				} catch (InvocationTargetException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				} catch (NoSuchMethodException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				}
			}
			@Override public void quack(){
				try {
					oClass.getMethod("quack").invoke(o);
				} catch (IllegalArgumentException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				} catch (SecurityException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				} catch (IllegalAccessException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				} catch (InvocationTargetException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				} catch (NoSuchMethodException e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				}
			}
		};
	}
}

class MandarinDuck implements Duck{
	
	@Override
	public void quack(){
		out.println("quack quack");
	}
	@Override
	public void walk(){
		out.println("walk walk");
	}
}

class PlasticDuck /*implements nothing*/{
	public void quack(){
		out.println("...");
	}
	public void walk(){
		out.println("...");
	}
}

class Dragon /*implements nothing*/{
	public void quack(){
		out.println("WRAAAAARAGARGAAAAAAAAAAARRRRR");
	}
	public void walk(){
		out.println("GKGKH GKGKH GKGKH");
	}
}

class KingOfPop /*implements nothing*/{
	public void quack(){
		out.println("wuuuuuhoooo");
	}
	public void walk(){
		out.println("mooooonwalk");
	}
}

class DuckSchool{
	public static void aaaand_action(Duck... ducks){
		for(Duck d:ducks){
			out.print("how do you talk? ");
			d.quack();
			out.print("how do you walk? ");
			d.walk();
		}
	}
}

public class DuckTypingExample{
	public static void main(String[] args) throws Exception{
		Duck realDuck = new MandarinDuck();
		Dragon hydra = new Dragon();
		PlasticDuck toy = new PlasticDuck();
		KingOfPop michaelJackson = new KingOfPop();
		
		DuckSchool.aaaand_action(
				realDuck,
				DuckCaster.cast(hydra),
				DuckCaster.cast(toy),
				DuckCaster.cast(michaelJackson)
		);
	}
}

hehe^^
...was ein haufen schrott :autsch:

Duck Typing ist zur Compile-zeit einfach nicht sinnvoll umsetzbar, solche Stunts gehen nur zur Laufzeit bei interpretierten Sprachen, und da ist das Programmieren schwerer, da der Compiler nicht prüfen kann, ob wirklich alles zusammenpasst... D.h. man muss andauernd selbst höllisch aufpassen, und das stresst wesentlich mehr, als kurz "[c]implements Blup[/c]" hinzuschreiben.

 

[Tomate_Salat]

Auf die Zeile [c]implements ...[/c] kommt es ja jetzt auch nicht mehr an . das was tuxedo und 0x7F80.* angesprochen haben sollte man meiner Meinung nach mit Vorsicht genießen.

 

[maki]

Ach, dass ist doch nur die uralte Diskussion typisierte vs. untypisierte Sprachen