multiple inheritance - irgendwann?

[kudi82]

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]

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]

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]

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]

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]

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]

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?

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Jedenfalls schöner als:

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

 

[Beni]

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]

Du könntest das Delegate-Pattern anwenden:

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

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

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

 

[Sky]

Du könntest das Delegate-Pattern anwenden:

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

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

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

Dann verwende einfach nicht Java !

 

[kudi82]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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?

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]

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

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

 

[Beni]

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]

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]

"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]

@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]

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]

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]

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]

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

Zwei Doofe, ein Gedanke

 

[Bleiglanz]

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]

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]

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]

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]

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]

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:

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]

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]

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]

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:

f()
{   LinkedList list = new LinkedList();
    //...
    g( list );
}

g( LinkedList list )
{
    list.add( ... );
    g2( list )
}

Now suppose a new requirement for fast lookup has emerged, so the LinkedList isn't working out. You need to replace it with a HashSet. In the existing code, that change is not localized since you must modify not only f() but also g() (which takes a LinkedList argument), and anything g() passes the list to.

Rewriting the code like this:

f()
{   Collection list = new LinkedList();
    //...
    g( list );
}

g( Collection list )
{
    list.add( ... );
    g2( list )
}

makes it possible to change the linked list to a hash table simply by replacing the new LinkedList() with a new HashSet(). That's it. No other changes are necessary.