# multiple inheritance - irgendwann?



## kudi82 (31. Aug 2005)

Ich habe vor kurzem beonnen, mit Java zu programmieren. Da Java eine OO Sprache ist, wollte ich natürlich alles schön strukturiert aufbauen. Nur, was ich plötzlich feststellen musste, Java unterstützt ja gar keine multiple inheritance... Das war ganz schön enttäuschend. Weiss jemand, ob dies irgendwann mal unterstützt werden wird in nächster Zeit? Sonst braucht man besser gar keine inheritance, dann ist der code wenigstens konsistent. Und interfaces sind ganz bestimmt keine Alternative.


----------



## Ives (31. Aug 2005)

Mehrfachvererbung wird es in absehbarer Zeit bzw. nie in Java geben. 
Warum hast du ein Problem mit der einfachen Vererbung? Auch so kann man gut strukturierten und oo-konformen Code schreiben.

Wenn man will geht es. Wirklich! Nur nicht zu schnell aufgeben


----------



## Roar (31. Aug 2005)

Anonymous hat gesagt.:
			
		

> Weiss jemand, ob dies irgendwann mal unterstützt werden wird in nächster Zeit?


nein, wirds nicht.



> Sonst braucht man besser gar keine inheritance, dann ist der code wenigstens konsistent.


schmarrn


> Und interfaces sind ganz bestimmt keine Alternative.


sicher sind sie das.

lies mal hier, da sollte das hoffentlich erklärt sein: http://www.java-forum.org/de/javabuch/html/k100051.html#kapiteloop2


----------



## kudi82 (31. Aug 2005)

Vielleicht weiss ich einfach noch nicht, wie man mit interfaces umgeht, darum ein Beispiel, was ich programmieren möchte:


```
class Point {
  public void setXY(...) { ..... }
}

class Size {
  public void setHeightWidth(...) { ..... }
}

class Rectangle extends Point, Size { ..... }
```

Das muss ich übersetzen in:



```
class Rectangle {
  Point p;
  Size s;
}
```

Leider müsste ich ja dann für Rectangle wieder neue setXY und setHeightWidth Funktionen schreiben. Oder geht das einfacher?


----------



## Roar (31. Aug 2005)

das macht aber keinen sinn. warum leitet rectangle von point ab? ein rechteckt ist kein punkt, ebensowenig wie ein rechteck eine größe ist. 
sinnvoll wär hier eine klasse Figure zu machen, die x,y,width & height schon implementiert und vor den dann dein rectangle und dein circle und so dann ableiten...


----------



## Ives (31. Aug 2005)

Wenn Rectangle  die Attrribute Point und Size enthält gehören dazu die entsprechenden get-/set-Methoden in die Klasse. Diese Klasse soll ja nur die Daten halten und keine weitere Logik - in Java nennt man das dann Bean.


----------



## byte (31. Aug 2005)

kudi82 hat gesagt.:
			
		

> Vielleicht weiss ich einfach noch nicht, wie man mit interfaces umgeht, darum ein Beispiel, was ich programmieren möchte:
> 
> 
> ```
> ...




ich glaube, du hast da noch nen allgemeinen denkfehler drin. du kannst durchaus in rectangle objekte des typs point und size verwenden, ohne dass rectangle von diesen klassen erbt. ein rechteck hat ja zb. 4 punkte (die im rechten winkel miteinander verbunden sind). ergo bekommt rectangle 4 objekte vom point. usw...

vererbung ist wie roar schon sagte immer eine "ist..." beziehung. einfaches beispiel: oberklasse gebäude, unterklasse kirche. kirche erbt von gebäude, denn "eine kirche *ist ein* gebäude", aber halt mit zusätzlichen eigenschaften.

in deinem fall: "ein rechteck ist *kein* punkt und schon gar nicht eine größe" ...


@ives - sorry aber von beans spricht man eigtl. nur in der j2ee welt. normalerweise heisst sowas ganz ordinär "datentyp" aber darum gings hier eigtl doch nur im entferntesten.


----------



## kudi82 (31. Aug 2005)

Oje, da hab ich aber ein ganz schlechtes Beispiel gegeben. Ich glaube, ich habe mir unter Vererbung etwas anderes vorgestellt. 

Ich habe es so betrachtet:

Wenn ich einen Hund und eine Katze mische, dann ist das Resultat ja auch weder ein Hund noch eine Katze, aber es erbt von beiden gewisse Eigenschaften. 

Wenn man das als "ist-ein" Beziehung betrachtet, dann funktionierts wirklich nicht. 

Bin ich denn völlig falsch, oder wäre so etwas wie in meinem Beispiel doch noch praktisch, aber vielleicht nicht unter der Terminologie inheritance? Oder wären dann genau das die Beans?


----------



## byte (31. Aug 2005)

wie gesagt, völlig falsch bist du nicht. nochmal:

ein rechteck besteht unter anderem aus 4 punkten. es macht also unter umständen schon sinn, sich eine klasse punkt zu definieren und dann in klasse rechteck 4mal diese klasse punkt zu referenzieren. dann kannst du in rechteckt auf alle 4 punkte zugreifen und entsprechend dein rechteck realisieren (indem du z.b. die punkte verbindest und dann prüfst, ob die linien rechtwinklig sind).

nur mit vererbung hat das halt nix zu tun. 


also etwa so:


```
class Point {
   
   int x;
   int y;

   public Point(int x, int y) {
      this.x = x;
      this.y = y;
   }

   ...

}

class Rectangle {

   Point p1;
   Point p2;
   Point p3;
   Point p4;

   public Rectangle(Point p1, Point p2, Point p3, Point p4) {
      this.p1 = p1;
      this.p2 = p2;
      this.p3 = p3;
      this.p4 = p4;
   }

   ...

}
```


----------



## kudi82 (31. Aug 2005)

Das wird nun ganz spezifisch, aber ich wollte eben mein Rechteck so definieren, dass es durch den Mittelpunkt (Point) und durch die Grösse (Breite, Höhe von Size) definiert ist. Ich muss nun zugeben, dass das mit Vererbung in dieser Art wie es in Java gebraucht wied, nicht viel zu tun hat. 

Ich dachte einfach, es wäre schön, wenn ich die Methoden von Point und Size in Rectangle wiederverwenden könnte, ohne sie erneut zu implementieren.


----------



## Ives (31. Aug 2005)

Vielleicht hilft das weiter:
http://www.galileocomputing.de/artikel/gp/artikelID-215?GalileoSession=77137046A19h8V1VsnI

@byto
Ich meinte nicht EJB´s. Das Package java.beans ist auch in J2SE definiert (hier hauptsächlich für GUI etc.). Umgangssprachlich werden Klassen zu reinen Datenhaltung als Beans bezeichnet und genau das habe ich getan. http://de.wikipedia.org/wiki/Java_Beans


----------



## byte (31. Aug 2005)

kudi82 hat gesagt.:
			
		

> Ich dachte einfach, es wäre schön, wenn ich die Methoden von Point und Size in Rectangle wiederverwenden könnte, ohne sie erneut zu implementieren.



also ein drittes mal erklär ichs dir nicht ...


----------



## kudi82 (31. Aug 2005)

Irgendwie habe ich das Gefühl, den Begriff der Vererbung zu Beginn richtig verstanden zu haben, und während dem Programmieren kam ich aus Faulheit einfach auf solche komische Ideen, die aber irgendwie schon praktisch wären. 

Sagen wir, ich habe eine Klasse Point mit den folgenden Methoden

setX
setY
setLocation
getX
getY
getXAsInt
getXAsInt
getLocation
move

und das ganze für Size

setWidth
setHeight
setSize
shrink
expand

dann wäre es einfach gewesen, wenn ich diese Methoden direkt hätte übernehmen können, aber ich bin jetz wieder auf dem richtigen Dampfer...


----------



## AlArenal (31. Aug 2005)

Ich finde es interessant, wie man erst mit anglizistischen Fachbegriffen um sich wirft, um das Fehlen eines Features zu monieren, um dann peiszugeben, dass man sich mit der Materie noch gar nicht eingehend auseinandergesetzt hat...

Würde mich da gerne noch zu auslassen, aber ich muss zu meinem Autohändler fahren, um mich zu beschweren, dass meine 90 PS Limousine keine Geländeuntersetzung hat, obowohl ich aufm Arbeitsweg recht viel Steigung habe...


----------



## kudi82 (31. Aug 2005)

Wenn ich das erste Beispiel noch so umwandle:

Point -> Movable
Size -> ExpandableShrinkable

Dann wäre auch alles etwas klarer gewesen, und die multiple inheritance wäre eben doch praktisch...


----------



## Ives (31. Aug 2005)

Wenn Point und Size Attribute deiner Klasse sind kannst du die Methoden z. B. mit rectangle.getSize().shrink() usw. ansprechen. Ob das gutes Design ist kann man streiten.

Ansonsten viel programmieren, dann lernt man was dabei. So und jetzt äußere ich mich nicht mehr dazu.


----------



## kudi82 (31. Aug 2005)

Vielleicht habe ich ja schon zu viel programmiert. Darum habe ich ja auch keine Lust jede Methode wiede einzubetten. 

rectangle.getSize().shrink() wäre sicher logisch, und zudem könnte man dann ja auch rectangle.shrink() aufrufen...


----------



## kudi82 (31. Aug 2005)

Jedenfalls schöner als:


```
s = rect.getSize();
s.shrink(2.0);
rect.setSize(s);
```


----------



## Beni (31. Aug 2005)

Du könntest das Delegate-Pattern anwenden:

```
public class Rectangle{
  private Dimension size = ...;

  public void shrink( double x ){
    size.shrink( x );
  }
}
```

Multiple Inheritance verursacht in 99% aller Fälle Probleme, und das letzte % kann man stets anders lösen :wink: Ich mag mich nicht erinnern, dass ich mir jemals Multiple-Inheritance gewünscht hätte (und ich programmiere jetzt schon länger mit Java).


----------



## kudi82 (31. Aug 2005)

Beni hat gesagt.:
			
		

> Du könntest das Delegate-Pattern anwenden:
> 
> ```
> public class Rectangle{
> ...



Darauf habe ich eben keinen Bock, das stört mich ja schon die ganze Zeit.


----------



## Sky (31. Aug 2005)

Anonymous hat gesagt.:
			
		

> Beni hat gesagt.:
> 
> 
> 
> ...



Dann verwende einfach nicht Java !


----------



## kudi82 (31. Aug 2005)

Tschuldigung, ich wollte ja nicht darüber diskutieren, was besser ist, sondern nur fragen, ob es einen Weg gibt, dies zu umgehen, der schön ist und von dem ich noch nichts weiss (eben z.B. dass ich eventuell nicht die volle Funktionalität von Intefaces kennen könnte). Aber irgendwie wollten einfach alle nur multiple inheritance schlecht reden...


----------



## KSG9|sebastian (31. Aug 2005)

dann nenn mir mal 2 Vorteile von Mehrfachvererbung. Aber richtige Vorteile, keine Vorteile bei der man gegen sinnvolle Architektur einer Anwendung verstößt (siehe dein erstes Beispiel).


----------



## Sky (31. Aug 2005)

Nein, eben nicht. 

Die Feststellung, dass es in Java nicht geht ist ein ausreichender Grund zu Alternativen zu kommen wie hier vorgeschlagen wird... ich finde es eher ungewöhlich dies mit "Darauf habe ich eben keinen Bock, das stört mich ja schon die ganze Zeit." zu beantworten !


----------



## byte (31. Aug 2005)

```
class Rectangle {
   Point point;
   Size size;

   ...

   // Konstruktor
   public Rectangle() {
      this.point = new Point();
      this.size = new Size();
   }

   ...

   void doSomething() {
      point.aMethod();
      size.anotherMethod();
   }
}
```


wo ist denn das problem?  ???:L


----------



## AlArenal (31. Aug 2005)

kudi82 hat gesagt.:
			
		

> Tschuldigung, ich wollte ja nicht darüber diskutieren, was besser ist, sondern nur fragen, ob es einen Weg gibt, dies zu umgehen, der schön ist und von dem ich noch nichts weiss (eben z.B. dass ich eventuell nicht die volle Funktionalität von Intefaces kennen könnte). Aber irgendwie wollten einfach alle nur multiple inheritance schlecht reden...



Umgehen brauchst du es nicht, denn es gibt ja in Java keine Mehrfachvererbung. 

Versuch doch mal dich schlau zu machen wann ein C++-Coder in der Praxis tatscählich Mehrfachvererbung sinnvoll nutzen kann, was für Voraussetzungen erfüllt sein müssen, wo die Fallstricke liegen. 

Mehrfachvererbung gehört zu den am meisten überschätzten Features und ist m.E. eine Ausgeburt der Featuritis im Microsoft-Style. Man schnappt sich was, was sich toll anhört, baut es ein und bewirbt es. Es braucht zwar niemand, aber es hört sich toll an und 1047 Features mehr als Konkurrent XY zu haben, macht sich in der Statistik immer gut.

Da muss man sich ja fragen wie all die großen Java-Anwendungen nur ohne auskommen können, wenn das doch so ein Hammer-Feature ist...



> Nur wenige Programmiersprachen bieten die Möglichkeit der Mehrfachvererbung. Nicht alle objektorientierten Programmiersprachen erlauben die Mehrfachvererbung. Programmiersprachen mit Mehrfachvererbung sind z.B. C++, Eiffel und Python. Dagegen unterstützen Smalltalk und Ada Mehrfachvererbung nicht. Als Einwand gegen Mehrfachvererbung wird häufig genannt, dass es das Design unnötig kompliziere und undurchsichtig machen könne.
> 
> Java, Delphi, C# und VB (.NET) bieten mit so genannten Schnittstellen eine eingeschränkte Form der Mehrfachvererbung. Hierbei kann eine Klasse maximal von einer Basisklasse abgeleitet werden, jedoch kann sie beliebig viele Schnittstellen erben. Damit verpflichtet sich diese Klasse, die Methoden der Schnittstelle zu erfüllen. Mit einfacher Vererbung und eingeschränkter Mehrfachvererbung in Form von Schnittstellen sind die meisten Anforderungen an ein Software-Design realisierbar, ohne die Nachteile der uneingeschränkten Mehrfachvererbung in Kauf nehmen zu müssen.



Siehe: http://de.wikipedia.org/wiki/Mehrfachvererbung#Mehrfachvererbung



> In five years of C++ programming, I never once used multiple inheritance.
> 
> My attitude about multiple inheritance in C++ didn't come only from your book. Most of my friends who were programming in C++ shared that attitude. The way we thought about multiple inheritance was that given two full blown classes, each of which could be instantiated, you create a third full blown class that inherits from the other two. That class structure, which is what we thought of when we thought of multiple inheritance, has all the problems you describe in Effective C++. I wasn't determined to avoid multiple inheritance in C++ at all costs, but in five years I never encountered a situation in which I felt inheriting from multiple base classes made sense in my designs.



Siehe: http://www.artima.com/intv/abcs.html


----------



## kudi82 (31. Aug 2005)

AlArenal hat gesagt.:
			
		

> Umgehen brauchst du es nicht, denn es gibt ja in Java keine Mehrfachvererbung.



Nicht darum, sondern weil es logischer Natur ist...

Mit Eiffel habe ich innert kürzester Zeit einige Beispiele angetroffen, die es wirklich rechtfertigen. Nur ist Eiffel nicht so weit verbreitet. 

Ich habe auch 1000 von C++ Zeilen geschrieben, habe aber nicht über multiple inheritance nachgedacht, weil die sich ergebenden Probleme in C++ nicht gut gelöst sind. Zudem geht natürlich alles auch anders, ich kann auch alles ohne Polymorphism lösen, irgendwie....


----------



## kudi82 (31. Aug 2005)

Im übrigen kann ich mir vorstellen, dass man lernen kann so zu denken, dass multiple inheritance logisch ist. Genauso wie man lernen muss OO zu denken, oder funktional zu denken. Nur kann das noch niemand wirklich.


----------



## AlArenal (31. Aug 2005)

Jede Sprache hat ihre Vor- und Nachteile. Ich kann mir aber keinenen Fall vorstellen, der nicht rein akademischer Natur wäre, in dem eine Eiffel- oder Samlltylk-like Umsetzung von Mehrfachvererbung allein über die Wahl der einzusetzenden Sprache entscheiden würde.

Davor stehen noch so Sachen wie Verbreitung, Wartbarkeit, Performace, Time to Market, Zukunftssicherheit, ...

Von Eiffel ist mir gar nicht bekannt, dass es mal kommerziell eingesetzt worden wäre (außer als W*chs-Vorlage für Bjarne Stroustroup  - oder war das Simula? hm..), wogegen es gerüchteweise ja tatsächlich kommerzielle Smalltalk-Software geben soll...

Die eierlegende Wollmilchsau unter den Sprachen ist auch Java nicht, weder was Unterstützung und Implementierung von OO-Features, noch den Einsatzzweck, .. angeht. Das gilt aber für jede Sprache.

Da kann man nun weinen, monatelang drüber meditieren und philosophieren, oder aber mal lieber schauen was man eigentlich entwickeln will/muss und sich auf die Suche nach dem am besten geeigneten Tool (Sprache) machen. Das es ne Weile braucht sich in die verschiedenen Ansätze einzuarbeiten und bei der Entwicklung von Software diese EIgenarten zu berücksichtigen, sollte selbstverständlich sein. Die Zeit sollte man sich auch nehmen.


----------



## AlArenal (31. Aug 2005)

kudi82 hat gesagt.:
			
		

> Im übrigen kann ich mir vorstellen, dass man lernen kann so zu denken, dass multiple inheritance logisch ist. Genauso wie man lernen muss OO zu denken, oder funktional zu denken. Nur kann das noch niemand wirklich.



Es nicht nicht a priori unlogisch, aber es ist in der Praxis schwer zu implementieren und warum soll man sich damit aufhalten, wenn andere Lösungsansätze deutlich einfacher und mit weniger unerwünschten Nebeneffekten arbeiten? In Java hat man sich ja bewusst entschieden, dies nicht umzusetzen und genausowenig wie du jetzt noch einen dazu bringen wirst, es plötzlich in C++ anders zu implementieren, wird es dieses Feature so auch nie in Java geben.

Das Problem tritt nur auf, wenn man aus ner anderen Ecke kommt, anderes gewöhnt ist und im Kopf noch nicht umschalten kann. Ich kenne keinen Java-Entwickler der das Feature vermisst und irgendwie gibts mehr Java-Software und -Entwickler als Eiffel, Smalltalk, ... und selbst die C++ler nutzen es sehr spärlich. Wozu also der Ballast wenn man es nicht braucht?

When you're in Rome, do it like Romans do.


----------



## kudi82 (31. Aug 2005)

> Da kann man nun weinen, monatelang drüber meditieren und philosophieren, oder aber mal lieber schauen was man eigentlich entwickeln will/muss und sich auf die Suche nach dem am besten geeigneten Tool (Sprache) machen.



Darum wollte ich ja fragen wie man die an sich logische multiple inheritance elegant umgehen kann. Und zwar eben nicht mit dem Delegate-Pattern (hat anscheinend sogar einen eigenen Namen), das Zeit kostet.


----------



## Roar (31. Aug 2005)

Anonymous hat gesagt.:
			
		

> > Da kann man nun weinen, monatelang drüber meditieren und philosophieren, oder aber mal lieber schauen was man eigentlich entwickeln will/muss und sich auf die Suche nach dem am besten geeigneten Tool (Sprache) machen.
> 
> 
> 
> Darum wollte ich ja fragen wie man die an sich logische multiple inheritance elegant umgehen kann.



indem man sich eine anstänige vererbungsstruktur ausdenkt?



			
				Roar hat gesagt.:
			
		

> sinnvoll wär hier eine klasse Figure zu machen, die x,y,width & height schon implementiert und vor den dann dein rectangle und dein circle und so dann ableiten...


----------



## kudi82 (31. Aug 2005)

> When you're in Rome, do it like Romans do.



Ich würde meinen die Römer sind an sich selbst gescheitert...


----------



## Beni (31. Aug 2005)

Also Eiffel verwende ich gerne als abschreckendes Beispiel: noch unübersichtlicher (und unflexibler) als z.B. die EiffelBase, oder EiffelVision2 kann man Software glaube ich nicht mehr designen.
Das kommt zum einen von der nicht vorhandenen Dokumentation (Code erklärt sich ja selber, *ja klar*), zum anderen von einer *Vererbungshierarchie, die man nur durch tagelanges Studium durchschaut. Guck dir mal EV_BUTTON an, und erkläre mir, was das Ding den jetzt alles kann. Und ob das alles zusammen überhaupt funktioniert.
Swing kann dasselbe (teilweise auch mehr) wie EiffelVision2 benötigt aber 20-Klassen-Hierarchien...

Nenn mal deine guten Beispiele, damit wir sie zerpflücken können :bae:

[Edit: * mit grossem Einsatz von Multiple Inheritance]


----------



## AlArenal (31. Aug 2005)

kudi82 hat gesagt.:
			
		

> > Da kann man nun weinen, monatelang drüber meditieren und philosophieren, oder aber mal lieber schauen was man eigentlich entwickeln will/muss und sich auf die Suche nach dem am besten geeigneten Tool (Sprache) machen.
> 
> 
> 
> Darum wollte ich ja fragen wie man die an sich logische multiple inheritance elegant umgehen kann. Und zwar eben nicht mit dem Delegate-Pattern (hat anscheinend sogar einen eigenen Namen), das Zeit kostet.



Mit Interfaces und Delegates. Im Übrigen habe ich erst im Nachhinein erfahren, dass es ein Delegate-Pattern gibt. Das ist wie mit Deutsch und Duden, erst kommt die Sprache und dann leitet man aus ihr Wörterbücher und Grammatik ab. Ich habe Delegates schon benutzt, ehe ich wusste, dass sie nen eigenen Namen haben, einfach weil es Sinn machte.

Wenn du dich natürlich bewusst dagegen sträubst die in Java vorhandenen Mittel zu nutzen, wieß ich nicht wohin das führen soll. Diesel ist toll, aber wer seinen Benziner mit Diesel zwangsbetankt kann sich schonmal auf ne hübsche Werkstattrechnung einrichten...

"Ich will in Java programmieren, aber Features nutzen die Java nicht hat, ohne Features von Java zu nutzen, die mein Problem lösen würden" - Viel Spaß dabei!


----------



## kudi82 (31. Aug 2005)

> "Ich will in Java programmieren, aber Features nutzen die Java nicht hat, ohne Features von Java zu nutzen, die mein Problem lösen würden" - Viel Spaß dabei!



Nö. Ich will ein Problem logisch angehen, und dann in Java übersetzen. Aber ich möchte nicht in Java denken. Und das sollte ja genau die Stärke einer OO Sprache sein. Nun weiss ich dass es nicht geht in Java. Also back to the roots. Mein Problem ist einfach, dass ich mit viel zu grosser Euphorie an Java herangieng, meine Erwartungen waren zu gross.


----------



## kudi82 (31. Aug 2005)

@beni: 

Wie ich deiner E-Mail entnehme, auch ein Bertrand gequälter... Sie haben einiges schlecht gemacht, aber ich würde wagen zu sagen, dass man damit sehr gute Software schreiben könnte.


----------



## Beni (31. Aug 2005)

> Aber ich möchte nicht in Java denken.


Aber genau das must du tun.

Wenn ich mit Eiffel programmiere, sehen meine Programme auch total anders aus, als wenn ich Java benutze. Einfach weil die beiden Sprachen unterschiedliche Schwerpunkte haben (Beispiel: die agents auf Eiffel, finde ich eine praktische Sache. Dass hingegen die Signatur einer Methode auf ihren Namen beschränkt ist, finde ich total daneben).

Wenn du in einen Ferrari steigst, musst du auch anders fahren, als wenn den Smart deiner Oma nimmst...


----------



## Beni (31. Aug 2005)

kudi82 hat gesagt.:
			
		

> Wie ich deiner E-Mail entnehme, auch ein Bertrand gequälter... Sie haben einiges schlecht gemacht, aber ich würde wagen zu sagen, dass man damit sehr gute Software schreiben könnte.


Da hast du IMHO zweimal recht. Eiffel wäre nicht schlecht (sogar gut, wenn ich über meinen Schatten springen könnte), gäbe es anständige Libraries, und wenigstens einen anständigen Editor (ich weiss nicht, wie es jetzt aussieht. Vor einem Jahr musste ich noch mit diesem schrecklichen EiffelStudio arbeiten).


----------



## AlArenal (31. Aug 2005)

Nein, die Herangehensweise, die du eben geäußert hast, ist falsch. Wenn du gut in einer Sprache sein willst, musst du auch in ihre denken, egal ob richtige Sprache oder Programmiersprache. 

Sprachen unterscheiden sich eben in vielen Dingen.. im Japanischen wird nicht konjugiert, aber es gibt vier Höflichkeitsformen.. Einen japanischen Satz kannst du nie 1:1 ins Deutsche übersetzen, sondern lediglich sinngemäß wiedergeben.

Wenn du ein Problem in einer best. Programmiersprache lösen willst, musst du dich auf diese Sprache auch einlassen. Gäbe es diese Unterschiede nicht, wo läge dann die Existenzberechtigung der ganzen OO-Sprachen?

Ich kann meinen Wagen auch nicht fahren wie ne Formel-1-Karre, obwohl beides Autos sind...


----------



## AlArenal (31. Aug 2005)

Beni hat gesagt.:
			
		

> Wenn du in einen Ferrari steigst, musst du auch anders fahren, als wenn den Smart deiner Oma nimmst...



Zwei Doofe, ein Gedanke


----------



## Bleiglanz (31. Aug 2005)

> Mein Problem ist einfach, dass ich mit viel zu grosser Euphorie an Java heranging, meine Erwartungen waren zu gross.


völlig lächerlich, kannst du mal sagen WAS du denn erwartet hast?

obige verquaste Diskussion über Rechteck-Punkte-Size lässt eher daraufschliessen, dass schon beim stinknormalen OO-Modellieren ziemliche Defizite vorhanden sind


----------



## kudi82 (31. Aug 2005)

> Sprachen unterscheiden sich eben in vielen Dingen.. im Japanischen wird nicht konjugiert, aber es gibt vier Höflichkeitsformen.. Einen japanischen Satz kannst du nie 1:1 ins Deutsche übersetzen, sondern lediglich sinngemäß wiedergeben.



Eben genau, das meine ich ja. Mir ist schon klar dass ich in gewisser weise in Deutsch denke, aber in erster Linie denke ich irgendwie mathematisch, logisch, vernünftig, strukturiert, etc. oder wie auch immer. Und eigentlich sollte man eben nicht gezwungen werden, in einer Sprache zu denken, denn die ist immer anders, aber es gibt gewisse Dinge die wären allen gemein. Und so wollte ich das auch angehen, ich wollte das Problem so angehen, wie es möglichst einfach wird (vielleicht nicht auf den ersten Blick), und dann das ganze übersetzen. Und eigentlich wollte ich nur wissen, ob es für diese Übersetzung einen einfacheren Weg als den von mir gewählten gibt.


----------



## Beni (31. Aug 2005)

Es gibt auch mit Logik unlösbare Probleme (z.B. das berühmte Halteproblem). Ich würde mal drauf tippen, das es sich mit "DER Programmiersprache" ähnlich verhält, es gibt einfach keine die *alles* kann :wink:
(Und sollte es sie doch geben, wäre sie derart überladen, dass man sie nicht lernen kann).

Nein, wenn du mit Java arbeiten willst, musst du MI schlicht und einfach aus dem Gedächnis löschen (um später zu merken, dass es auch ohne sehr gut geht).


----------



## AlArenal (31. Aug 2005)

kudi82 hat gesagt.:
			
		

> Und eigentlich sollte man eben nicht gezwungen werden, in einer Sprache zu denken, denn die ist immer anders, aber es gibt gewisse Dinge die wären allen gemein.



Dann versuch mal dich deinem Mitmenschen oder PC ohne Sprache mitzuteilen. 



> Und so wollte ich das auch angehen, ich wollte das Problem so angehen, wie es möglichst einfach wird (vielleicht nicht auf den ersten Blick), und dann das ganze übersetzen. Und eigentlich wollte ich nur wissen, ob es für diese Übersetzung einen einfacheren Weg als den von mir gewählten gibt.



Theorie und Praxis. Du kannst dein Problem sprachunabhängig in UML oder gleich rein mathematisch beschreiben, aber du kannst es nicht ohne implementieren. Ebensowenig wie es im Deutschen 1:1 Übersetzungen der 3 Dutzend verschiedenen Begriffe für Schnee der Inuit geben kann (und jeder Begriff bezeichnet eine andere Form von Schnee) ist das auch in anderen Sprachen nicht möglich.

Jede Sprache beschränkt in gewisser Weise und um eine Sprache zu beherrschen, muss man ihre Regeln und Eigenheiten verstehen. Dein Problem liegt nicht ursächlich darin begründet, dass Java keine Mehrfachvererbung für Klassen unterstützt, sondern dass du noch nicht in der Lage bist dein problem mit Javas Bordmitteln zu lösen.

Da gibts nur eins: Bastel dir ne eigene Sprache


----------



## kudi82 (31. Aug 2005)

Mein Problem ist, dass ich es schon etwa 7 Jahre ohne MI ausgehalten habe, vor allem in C/C++ und nun auf etwas gehofft habe, das alles etwas schöner macht...


----------



## kudi82 (31. Aug 2005)

AlArenal hat gesagt.:
			
		

> Dein Problem liegt nicht ursächlich darin begründet, dass Java keine Mehrfachvererbung für Klassen unterstützt, sondern dass du noch nicht in der Lage bist dein problem mit Javas Bordmitteln zu lösen.



Das habe ich ja schon geschrieben:



			
				kudi82 hat gesagt.:
			
		

> Und so wollte ich das auch angehen, ich wollte das Problem so angehen, wie es möglichst einfach wird (vielleicht nicht auf den ersten Blick), und dann das ganze übersetzen. Und eigentlich wollte ich nur wissen, ob es für diese Übersetzung einen einfacheren Weg als den von mir gewählten gibt.


----------



## Beni (31. Aug 2005)

Einige Programmierer (und mein linker grosser Zehen gehört auch zu der Gruppe) sagen, dass Vererbung nur ein bisschen syntaktischer Zucker ist, und mit OOP eigentlich nicht so viel zu tun hat.
Dass man mit Vererbung sehr schnell unflexible Software schreibt, ist IMHO nicht so schwer einzusehen. Sobald mal was geschrieben ist, führte jede Veränderung zu weitrechenden Folgen, sogar in anderen Klassen.
z.B. das Delegate-Pattern (kombiniert mit Interfaces) kann hier flexibler sein. Wenn man mal was an den Interfaces ändert, bekommt man wenigstens Compilerfehler. Im Gegesatz zu lustigen Dingen, wie versehentlich überschriebenen Methoden...
Abgesehen davon, kann man mit Delegate die Implementation noch während der Laufzeit ändern; mit Vererbung ist das unmöglich. :bae:

Vielleicht als Einstiegsartikel, und um das Interesse zu wecken, auf JavaWorld gibt es auch ein oder zwei Artikel dazu (und natürlich google...).


----------



## stev.glasow (31. Aug 2005)

kudi82 hat gesagt.:
			
		

> Mein Problem ist, dass ich es schon etwa 7 Jahre ohne MI ausgehalten habe, vor allem in C/C++ und nun auf etwas gehofft habe, das alles etwas schöner macht...


Halt mit Interfaces, ne schönere Alternative gibt es der Zeit nicht bzw. kenn ich keine.


----------



## kudi82 (31. Aug 2005)

Artikel auf Java World hat gesagt.:
			
		

> Programming to interfaces is at the core of flexible structure. To see why, let's look at what happens when you don't use them. Consider the following code:
> 
> 
> ```
> ...


----------



## AlArenal (31. Aug 2005)

Ich sags mal ketzerisch so:

Es juckt weder meinen Chef (und damit meinen Gehaltsscheck) noch unsere Kunden, ob Java MI kann oder nicht. Mich störts auch nicht, weil ich keinen Anwendungsfall sehe, in dem MI der eleganteste und tollste Weg wäre, so ganz ohne unerwünschte Nebeneffekte.

Ich wüsste ja gerne was du da so entwickelst.. (außer Kreis, Rechteck, ..)


----------



## kudi82 (31. Aug 2005)

Ooops.. Ich wollte noch was zum Artikel schreiben:
Da verstehe ich nun aber nicht wieso Collection besser ein Interface ist als eine Klasse?



> Ich wüsste ja gerne was du da so entwickelst.. (außer Kreis, Rechteck, ..)



Wenn das Fundament nicht stimmt...


----------



## stev.glasow (31. Aug 2005)

Was sollte die Klasse Collection den implemtieren? Methoden wie add(), iterator() etc, müsste ich dann doch mit nem leeren Body versehnen oder abstarkt machen.


----------



## Beni (31. Aug 2005)

Stell dir eine Liste, basierend auf einem Array, und eine Menge, basierend auf einem Baum vor. Beide implementieren Collection.

Die haben zwar einige Methoden die denselben Namen haben, und ähnliche Effekte erzeugen, das wars dann aber auch. Die Implementation dieser Methoden sieht jeweils sehr unterschiedlich aus.
Anders gefragt: welchen Sinn hätte es Collection als Klasse zu implementieren? Gibt es irgendeine Methode oder Variable, welche man in ihr vordefinieren könnte?


----------



## AlArenal (31. Aug 2005)

Wenn du deine Signaturen auf Basis von Interfaces definierst, bist du unabhängig von der benutzten Implementation. Es gibt eine ganze Reihe von Klassen, die das Interface Collection oder List, o.ä. implementieren, die haben alle je nach Verwendung ihre Vor- und Nachteile. 

Erwarten meine Methoden ein Interface, wird alles entgegen geniommen, was dieses Interface implementiert und ich kann an einer einzigen Stelle später von einer Klasse auf ne andere wechseln (weil sie flotter ist, weniger Speicher braucht, thread-sicher ist, ...), wenn diese dasselbe Interface implementiert.

Würde ich überall ne Abhängigkeit von einer bestimmten Klasse schaffen, hätte ich bei einer solchen Änderung je nach Umfang der Anwendung reichlich Aufwand, überall die Signaturen, Doku, etc. zu ändern...


----------



## kudi82 (31. Aug 2005)

> Die haben zwar einige Methoden die denselben Namen haben, und ähnliche Effekte erzeugen, das wars dann aber auch. Die Implementation dieser Methoden sieht jeweils sehr unterschiedlich aus.
> Anders gefragt: welchen Sinn hätte es Collection als Klasse zu implementieren? Gibt es irgendeine Methode oder Variable, welche man in ihr vordefinieren könnte?



Nun, ich kann eine abstrakte Klasse machen, und dann habe ich dasselbe wie bei einem Interface. Das zeigt aber keinen Vorteil von Interfaces gegenüber Klassen. Das ist nur anders benennt, wenn ich das jetzt richtig verstanden habe. Und falls ja, da es in Java sowieso auch abstrakte Klassen gibt, wieso dann sich auch noch mit Interfaces herumschlagen, wenn sie im Prinzip nichts anderes machen.


----------



## byte (31. Aug 2005)

arbeiten mit interfaces bringt den vorteil, dass du dich nicht auf eine implementierung festlegen musst.

beispiel: interface List aus dem collection framework (die wahl der implementierung, also z.b. ArrayList oder Vector, bleibt offen und flexibel).


----------



## stev.glasow (31. Aug 2005)

AlArenal hat gesagt.:
			
		

> Wenn du deine Signaturen auf Basis von Interfaces definierst, bist du unabhängig von der benutzten Implementation. Es gibt eine ganze Reihe von Klassen, die das Interface Collection oder List, o.ä. implementieren, die haben alle je nach Verwendung ihre Vor- und Nachteile.
> 
> Erwarten meine Methoden ein Interface, wird alles entgegen geniommen, was dieses Interface implementiert und ich kann an einer einzigen Stelle später von einer Klasse auf ne andere wechseln (weil sie flotter ist, weniger Speicher braucht, thread-sicher ist, ...), wenn diese dasselbe Interface implementiert.
> 
> Würde ich überall ne Abhängigkeit von einer bestimmten Klasse schaffen, hätte ich bei einer solchen Änderung je nach Umfang der Anwendung reichlich Aufwand, überall die Signaturen, Doku, etc. zu ändern...


Er wollte wissen warum Collection keine Klasse ist, mit Mehrfachvererbung und "leeren" Methoden hätte das eigentlich 
den gleichen Effekt wie mit dem Interfaces Collection.


----------



## AlArenal (31. Aug 2005)

Bzw. meine Methoden können auch mit Instanzen unterschiedlicher Klassen gleichzeitig umgehen, sofern diese das passende Interface implementieren.

Wäre Shape ein Interface und würden Circle und Triangle dieses Interface implementieren, bräuchte ich nur eine Methode resize(Shape shape, Dimension dim), die für beide Klassen (und jede beliebige andere, die Shape implementiert) funktioniert..


----------



## stev.glasow (31. Aug 2005)

kudi82 hat gesagt.:
			
		

> > Die haben zwar einige Methoden die denselben Namen haben, und ähnliche Effekte erzeugen, das wars dann aber auch. Die Implementation dieser Methoden sieht jeweils sehr unterschiedlich aus.
> > Anders gefragt: welchen Sinn hätte es Collection als Klasse zu implementieren? Gibt es irgendeine Methode oder Variable, welche man in ihr vordefinieren könnte?
> 
> 
> ...


Stimmt mit Mehrfachvererbung kann ich das gleiche machen wie mit Interfaces, aber auch mehr und das ist das Problem, du kannst teilweise unschlüssige Sachen bilden, wurde glaube ich in nem Post weiter obern erklärt


----------



## Bleiglanz (31. Aug 2005)

Anonymous hat gesagt.:
			
		

> > Die haben zwar einige Methoden die denselben Namen haben, und ähnliche Effekte erzeugen, das wars dann aber auch. Die Implementation dieser Methoden sieht jeweils sehr unterschiedlich aus.
> > Anders gefragt: welchen Sinn hätte es Collection als Klasse zu implementieren? Gibt es irgendeine Methode oder Variable, welche man in ihr vordefinieren könnte?
> 
> 
> ...



schön langsam kommst du dahinter...

gerade weil es in Java keine MI gibt (und man also immer nur von EINER Klasse erben kann) braucht man einen Mechanismus, um die "Schnittstelle" einer Klasse von Ihrer eigentlichen Implementierung zu trennen

schau dir mal die Interfaces in java.util. an: Collection, Set, usw., veilleicht kommst du dann drauf wozu die gut sind, oder denk einfach an 

java.lang.Comparable

wie sollte das mit abstrakten Klassen gelöst werden?


----------



## kudi82 (31. Aug 2005)

stevg hat gesagt.:
			
		

> Stimmt mit Mehrfachvererbung kann ich das gleiche machen wie mit Interfaces, aber auch mehr und das ist das Problem, du kannst teilweise unschlüssige Sachen bilden, wurde glaube ich in nem Post weiter obern erklärt



Was passiert denn, wenn ich von zwei Interfaces erbe, und beide eine Methode mit derselben Signatur besitzen? (Ich wage mich hier auf dünnes Eis, da ich nicht bis ins Detail alles kenne)


----------



## Beni (31. Aug 2005)

stevg hat gesagt.:
			
		

> Er wollte wissen warum Collection keine Klasse ist, mit Mehrfachvererbung und "leeren" Methoden hätte das eigentlich den gleichen Effekt wie mit dem Interfaces Collection.


Da hast du völlig recht. Allerdings würde man dann wieder Mehrfachvererbung benötigen, damit alles schön funktioniert. Jetzt dreht man sich im Kreis, die Entwickler von Java entschieden sich schliesslich für Interfaces als eine Art "kastrierte MI".

Persönlich finde ich das keine schleche Idee. Wenn man ein Interface vor sich sieht kann man wirklich sicher sein, dass man nur diese Ding implementieren muss, und dann wird "es" schon funktionieren. Bei Vererbung bleibt die Unsicherheit, ob es nicht doch irgendwann eine zusätzliche Methode/Variable geben wird, die alle beachten sollten.


----------



## AlArenal (31. Aug 2005)

kudi82 hat gesagt.:
			
		

> Was passiert denn, wenn ich von zwei Interfaces erbe, und beide eine Methode mit derselben Signatur besitzen? (Ich wage mich hier auf dünnes Eis, da ich nicht bis ins Detail alles kenne)



Ist nicht zulässig und führt zum Fehler beim Kompilieren, bzw. bei ner guten IDE schon vorher


----------



## kudi82 (31. Aug 2005)

AlArenal hat gesagt.:
			
		

> kudi82 hat gesagt.:
> 
> 
> 
> ...



Nein, das sollte ja eigentlich gar kein Problem sein, da interfaces ja nicht implementiert sind...


----------



## bygones (31. Aug 2005)

kudi82 hat gesagt.:
			
		

> AlArenal hat gesagt.:
> 
> 
> 
> ...


du erbst nicht von Interfaces. Man kann nur von Klassen erben. Man implementiert ein Interface. Wenn 2 Interfaces in deiner Klasse implementierst, die de selbe Signatur haben, hast du logischerweise 2 methoden mit der selben Signatur in deiner Klasse.... wie soll das gehen...


----------



## Beni (31. Aug 2005)

kudi82 hat gesagt.:
			
		

> Was passiert denn, wenn ich von zwei Interfaces erbe, und beide eine Methode mit derselben Signatur besitzen? (Ich wage mich hier auf dünnes Eis, da ich nicht bis ins Detail alles kenne)


Dann hast du ein grosses Problem. Wenn du sehr viel Glück hast, machen "beide" Methoden dasselbe, und du kannst dich noch durchmogeln, wenn du Pech hast... Der "renaming"-Mechanismus von Eiffel hat schon was :wink:

Praktisch hingegen tritt das Problem (fast) nie auf. (Man kann es absichtlich herbeiführen um Code zu sparen, aber das ist ein anderes Thema).
Es gibt sooo viele Signaturen für Methoden, da trifft man sich halt selten.

[Edit: mit inneren Klassen und Delegates (schon wieder) kann man das Problem auch umgehen]


----------



## stev.glasow (31. Aug 2005)

Beni hat gesagt.:
			
		

> stevg hat gesagt.:
> 
> 
> 
> ...



Ganz deiner Meinung 



			
				stevg hat gesagt.:
			
		

> Stimmt mit Mehrfachvererbung kann ich das gleiche machen wie mit Interfaces, aber auch mehr und das ist das Problem, du kannst teilweise unschlüssige Sachen bilden ...


----------



## AlArenal (31. Aug 2005)

kudi82 hat gesagt.:
			
		

> Nein, das sollte ja eigentlich gar kein Problem sein, da interfaces ja nicht implementiert sind...



Der Punkt geht an dich. Habs eben ausprobiert und du liegst richtig 

Dennoch empfinde ich es ad hoc als stilistisches Pfui, ohne mir über weitergehende Konsequenzen Gedanken gemacht zu haben.


----------



## kudi82 (31. Aug 2005)

> Wenn 2 Interfaces in deiner Klasse implementierst, die de selbe Signatur haben, hast du logischerweise 2 methoden mit der selben Signatur in deiner Klasse.... wie soll das gehen...



Da hätte ich jetzt aber genau erwartet, dass Java dann diese sozusagen automatisch merged, da sie ja im Gegenteil zu einer Klasse, nicht schon implementiert sein können, und ich daher nicht bestimmen muss, welche Implementierung gewählt werden soll.


----------



## stev.glasow (31. Aug 2005)

kudi82 hat gesagt.:
			
		

> AlArenal hat gesagt.:
> 
> 
> 
> ...



jop. Wenn man 2 Interfaces die eine gleiche Methode beschreiben implementiert juckt das nicht.


----------



## AlArenal (31. Aug 2005)

Wenn eine Klasse mehrere Interfaces implementiert, die wenigstens eine Methode mit gleicher Sig haben, muss ich mal dringend ein Refactoring durchführen, weil ich beim Design nicht aufgepasst habe. 

Ich denke darauf können wir uns einigen.


----------



## Beni (31. Aug 2005)

kudi82 hat gesagt.:
			
		

> > Wenn 2 Interfaces in deiner Klasse implementierst, die de selbe Signatur haben, hast du logischerweise 2 methoden mit der selben Signatur in deiner Klasse.... wie soll das gehen...
> 
> 
> 
> Da hätte ich jetzt aber genau erwartet, dass Java dann diese sozusagen automatisch merged, da sie ja im Gegenteil zu einer Klasse, nicht schon implementiert sein können, und ich daher nicht bestimmen muss, welche Implementierung gewählt werden soll.


Missverständnis? Genau das tut Java.

Nur: zwar geht es Codemässig, und du kannst immernoch kompilieren, aber ob du eine Logik in die Methode (es ist nach dem Merge ja nur noch eine) bringst, steht auf einem anderen Blatt.


----------



## kudi82 (31. Aug 2005)

AlArenal hat gesagt.:
			
		

> Wenn eine Klasse mehrere Interfaces implementiert, die wenigstens eine Methode mit gleicher Sig haben, muss ich mal dringend ein Refactoring durchführen, weil ich beim Design nicht aufgepasst habe.
> 
> Ich denke darauf können wir uns einigen.



Also da das nur ein Problem der Benennung ist und es nun halt zweideutige Wörter gibt in unserer Sprache, hat es wohl nicht viel mit Design zu tun. Zudem sollte Design ja auch ein iterativer Prozess sein können.


----------



## stev.glasow (31. Aug 2005)

*abgeharkt*


----------



## kudi82 (31. Aug 2005)

Ich glaube auch, das ganze ist ausdiskutiert.


----------



## stev.glasow (31. Aug 2005)

Hats denn geholfen?


----------



## Beni (31. Aug 2005)

Also ich fands lustig 8), hast du noch mehr Fragen kudi82? :bae:


----------



## kudi82 (31. Aug 2005)

Hmm... schwierige Frage? Vom technischen her eigentlich nicht, da ich ja jetzt weiss, dass ich eigentlich so weiter machen muss wie bis jetzt. Das allererste Beispiel von mir war so natürlich schon nicht logisch, ist gut dass ich das nochmals überdenken musste.
Andere Ansichten sind immer interessant und bringen nicht nur mir Erfahrung. Ich würde aber sagen, auch andere haben davon profitiert, was ich so gelesen habe. Einige sind sich ihrer Kenntnisse glaube ich zu sicher, da ja die Probleme bei Kreisen und Punkten entstehen.


----------



## kudi82 (31. Aug 2005)

Beni hat gesagt.:
			
		

> Also ich fands lustig 8), hast du noch mehr Fragen kudi82? :bae:



Nö, jetzt ist eigentlich alles raus. Ich fands auch noch witzig. 

(Lustig sind die Leute, die den Thread eigentlich völlig unnötig finden, aber trotzdem auf jeder Seite wieder irgendwo einen kleinen Kommentar abgegeben haben )


----------



## AlArenal (31. Aug 2005)

Du solltest deine Erfahrung nicht aus Diskussionen beziehen, sondern aus Praxis


----------

