Ich hasse Java

[Krishty]

… ich bin (leider) nie dazu gekommen, auch nur eine Zeile darin zu schreiben, geschweige denn, mir über Monate eine Meinung zu bilden. Als Mensch habe ich da auch keine Zeit zu, und als Entwickler keinen Drang.

Microsoft sagt, C# ein besseres Java; Goslin sagt, es sei ein schlechteres Java. Wenn sie sich schon in dem einen Punkt einig sind, glaube ich auch, dass es eine Art Java ist. Wie J# und J++ zuvor.

Und diesen Absatz kriege ich irgendwie unmöglich formuliert, ohne jemanden zu beleidigen. Darum reduziere ich es auf: Der Gedanke, wie viel Geld, Zeit und Bugs man gespart hätte, wenn man einfach Visual Basic generalüberholt hätte statt alle zwei Jahre eine managed Sprache auf den Markt zu werfen, die gegenüber Java und den n Plagiaten alles anders, aber nichts besser macht, sagt für mich enorm viel über den Stand der kommerziellen Software-Entwicklung an sich aus.

[Chromanoid]

Also ich persönlich finde C# besser (als Java) wenn es um Sprachkonstrukte geht und schlechter wenn es um Paket/Klassenverarbeitung geht. Alles einfach dll zu nennen finde ich nervig und ich vermisse die Paketstruktur von Java - ich mag diesen Assembly-Kram überhaupt nicht...
Wenn du in deine Engine mal eine Art Scriptsprache oder so einbaust, könntest du es ja mal mit C# versuchen :).

[BeRsErKeR]

Erschreckend das vom Text her die Bilder oben auch auf C# passen :).

Ich bin auch großer Java Verächter, sogar soo sehr, das ich nichtmal Kaffe trinke ;)
Aber dagegen ein sehr großer C# Freund, passt das oder nennt man das schon Fanboy? ;)

Ich persönlich mag beides nicht und finde es auch recht ähnlich. Aber ich will, wegen des Threadtitels, mal bei Java bleiben.

Ich finde diese "Alles muss in eine Klasse"-Philosophie sowas von daneben. Es ist nicht nur völlig sinnfrei, sondern teilweise auch kein guter Weg. Wenn ich einmalig genutzte Codefragmente oder Funktionen wie eine einmalige globale Initialisierung, mathematische Funktionen oder die main-Funktion habe, wozu dann Klassen? Und dann noch Garbage Collection. Da kommt einem echt das gruseln. Wenn ich sowas brauche, dann mach ich was falsch. Es würde ja nicht mal stören, wenn man durch so ein aufgezwungenes Feature nicht einen Haufen an Performance einbußen würde. Sowas gehört mMn einfach nicht in eine Programmiersprache.

Man versucht heutzutage immer mehr dem Programmierer unter die Arme zu greifen. Halt z.B. mit Dingen wie GC. Aber sowas will man nicht unbedingt und teilweise hat man einfach keine Wahl. Das ist leider auch ein Grund, weshalb ich die neue C++ Version eher unfreudig begutachte. Ich möchte selbst entscheiden wie ich programmiere und passe selbst auf was ich tue. Wenn mir alles abgenommen wird oder untransparent wird, dann lerne ich auch weniger finde ich. Jemand, der nur Java programmiert wird vielleicht nicht verstehen was Pointer sind oder wie sie funktionieren und somit erst gar nicht mit bestimmten Problemstellungen konfrontiert werden. Aber ist das gut? Ist es nicht viel lernreicher, mit Problemen konfrontiert zu werden und Lösungen dafür zu finden?

Ein Vergleich: Am Anfang sind Programmierer wie kleine Kinder, die keine Ahnung von der Welt haben (bezogen auf die Programmierung). Java-Programmierer sind wohl behütet von ihren Eltern (z.B. dem Garbage Collector) und müssen sich nicht um Memory-Management kümmern (sie haben keine Ahnung davon). Der C-Programmierer kommt nach kurzer Zeit nicht mehr ohne Pointer und Memory-Management aus. Er macht seine eigenen Erfahrungen, scheitert ab und an, aber kommt letztlich zu einem hohen Wissensstand darüber und beherrscht die Thematiken größtenteils. Mir gefallen die C-Kinder irgendwie besser. :)

[Krishty]

Man versucht heutzutage immer mehr dem Programmierer unter die Arme zu greifen. Halt z.B. mit Dingen wie GC. Aber sowas will man nicht unbedingt und teilweise hat man einfach keine Wahl. Das ist leider auch ein Grund, weshalb ich die neue C++ Version eher unfreudig begutachte.

Wo wird einem dort die Wahl genommen?

[rüp]

Ein Vergleich: Am Anfang sind Programmierer wie kleine Kinder, die keine Ahnung von der Welt haben (bezogen auf die Programmierung). Java-Programmierer sind wohl behütet von ihren Eltern (z.B. dem Garbage Collector) und müssen sich nicht um Memory-Management kümmern (sie haben keine Ahnung davon). Der C-Programmierer kommt nach kurzer Zeit nicht mehr ohne Pointer und Memory-Management aus. Er macht seine eigenen Erfahrungen, scheitert ab und an, aber kommt letztlich zu einem hohen Wissensstand darüber und beherrscht die Thematiken größtenteils. Mir gefallen die C-Kinder irgendwie besser. :)

Man kann aber auch so argumentieren, dass der C-Programmierer bis ins hohe Alter Fehler beim Speichermanagement machen wird, während der Java-Programmierer am Ende einfach mal 8 Millionen Dollar verdient hat. ;)

[The_Real_Black]

Man kann aber auch so argumentieren, dass der C-Programmierer bis ins hohe Alter Fehler beim Speichermanagement machen wird, während der Java-Programmierer am Ende einfach mal 8 Millionen Dollar verdient hat. ;)

Oder der C# Entwickler... ;-)

Ein anderes Argument ist das C++ Entwickler viel aufwand treiben bzw getrieben haben um genau auf solche Systeme zukommen wie sie in C# bzw Java bereits implementiert sind. Eine Speicherverwaltung selbst zuschreiben ist ein riesen Aufwand welches am Ende keinen Profit abwirft und nur viele Arbeitsstunden kostet. Oben wurde auch das Klassen Konzept bemängelt, aber Klassen bieten eine natürlichere Art Programme zu entwerfen da man auch in der Realität solche Einteilungen treffen kann. (Mein Beispiel ist immer "Tier": Tier ist ein Lebewesen, ein Eichhörnchen ist ein Tier, eine Ente ist ein Tier... und wenn man von Ente, Eichhörnchen, Hase und Hirsch gleichzeitig ableitet bekommt man einen Wolpertinger!?? Für welche die nicht wissen wovon ich rede: http://de.wikipedia.org/wiki/Wolpertinger ) Objektorientiertheit hat sich entwickelt da man versucht hat möglicht seine Daten gewönht zu verwalten also ist dieser Trend zu begrüßen.

PS kennt einer Singularity?
http://de.wikipedia.org/wiki/Singularity
Da sieht man was die Zukunft bringen wird...

[Schrompf]

Ein anderes Argument ist das C++ Entwickler viel aufwand treiben bzw getrieben haben um genau auf solche Systeme zukommen wie sie in C# bzw Java bereits implementiert sind.

Nein. Das ist nur ein klassisches Klischee. In Wirklichkeit betreibt man oft, aber wenig Aufwand, um praktische Lösungen für vielfältige spezifische Lebenszeitprobleme von Resourcen zu finden. Wenn Du viel Aufwand betreibst, nur um am Ende eine AllesErledigt-Lösung zu bekommen, die es eh schon gibt (z.B. der GC in Java), dann hast Du nur Deinen Job ineffizient gemacht.

[BeRsErKeR]

Man versucht heutzutage immer mehr dem Programmierer unter die Arme zu greifen. Halt z.B. mit Dingen wie GC. Aber sowas will man nicht unbedingt und teilweise hat man einfach keine Wahl. Das ist leider auch ein Grund, weshalb ich die neue C++ Version eher unfreudig begutachte.

Wo wird einem dort die Wahl genommen?

Hmm das hab ich falsch formuliert. Die neue C++ Version stört mich eher in der Hinsicht, dass sie sich Sprachen wie C# oder Java annähert. Und selbst ein GC war ja mal angedacht. Außerdem stören mich schlecht nachvollziehbare Konstrukte wie "auto", lambda expressions oder user-defined literals/suffixes.

Ein Vergleich: Am Anfang sind Programmierer wie kleine Kinder, die keine Ahnung von der Welt haben (bezogen auf die Programmierung). Java-Programmierer sind wohl behütet von ihren Eltern (z.B. dem Garbage Collector) und müssen sich nicht um Memory-Management kümmern (sie haben keine Ahnung davon). Der C-Programmierer kommt nach kurzer Zeit nicht mehr ohne Pointer und Memory-Management aus. Er macht seine eigenen Erfahrungen, scheitert ab und an, aber kommt letztlich zu einem hohen Wissensstand darüber und beherrscht die Thematiken größtenteils. Mir gefallen die C-Kinder irgendwie besser. :)

Man kann aber auch so argumentieren, dass der C-Programmierer bis ins hohe Alter Fehler beim Speichermanagement machen wird, während der Java-Programmierer am Ende einfach mal 8 Millionen Dollar verdient hat. ;)

Kann man. Es ist ja auch nur meine ganz persönliche Wertung. Ich bin halt jemand, der gern etwas lernt und versteht und nicht einfach viel Geld verdienen will obwohl ich nur die Hälfte verstehe. Für mich ist das ähnlich wie GameMaker und Programmiersprache. Wenn ich ein Spiel machen will kann ich mit einem GameMaker schneller zum Ziel kommen, aber wie man ein Spiel programmiert sehe ich dann meist nicht.

[unique75]

Frage: Was ist schlimmer als ein abgebissener Apfel mit einer Made drin?
Antwort: Ein abgebissener Apfel mit einer halben Made drin.

Ich überlasse es jedem selbst zu entscheiden, was davon Java oder C# ist.

Ich halte es aber für verkehrt daraus einen allgemeingültigen Rückschluß für alle Äpfel zu machen. Genauso ist es mit dem GC. Ein guter GC verbraucht zu Spitzenzeiten nicht mehr als 10% und das auch nur wenn man eine für die Applikation ungeeignete Memorypolicy eingestellt hat. Hat man einen GC so baut man auch viel komplexere und aus OOP-Sicht sinnvollere Objektbeziehungen, weil es nicht mehr interessiert WER/WANN/Wo es freigegeben wird.

Hier noch ein paar andere Anmerkungen:

- wir arbeiten filebasiert, weil das VisualStudio/Eclipse und überhaupt die ganze Welt so macht, also muss das richtig sein
- wir schreiben 100 Methoden in ein File, weil das so ungemein die Wartbarkeit und Lesbarkeit erhöht
- wir lieben Files, denn wir haben einen netten Compiler, der uns auf zyklische Referenzen aufmerksam macht
- wir lieben den Compiler, denn die Menge "aufmerksam machen" verknüpft mit der Menge "hilfreich" ergibt in unserer Welt die leere Menge
- wir brauchen keinen GC, es ist viel performanter es selbst zu tun, so lasten wir unsere CPU nur 4% aus, anstatt 5%
- wir brauchen keinen GC, wir sind unfehlbar und überblicken alle 100000 Objektbeziehungen und -querverweise
- da wir so unfehlbar sind gibt es auch so selten Programme mit Pufferüberläufen, Abstürzen und Memoryleaks
- wir sind sogar so unfehlbar, dass wir ganze Klassenhierarchien final/private machen
- wir brauchen Typen, und weil die so geil sind, schreiben wir die gleich 3x hin, Microsoft sagt, das muss so sein
- wir brauchen native Datentypen, denn das bringt Performance... für den Rest haben wir ja Boxed
- wir brauchen native Datentypen, denn wir wollen mit Bytegrenzen rechnen, anstatt mit mathematisch unbegrenzten Zahlenräumen
- wir alignen auf 2 Bytes, Speicherlayout ist eben geil, in der realen Welt nehm ich ja auch ne Schraube die exakt 20 Holzspanbreiten braucht
- und das wichtigste... wir brauchen eine performante Sprache... denn ich möchte gleich ein paar printfs machen

Ich hoffe ich konnte helfen :D

[Krishty]

Ein anderes Argument ist das C++ Entwickler viel aufwand treiben bzw getrieben haben um genau auf solche Systeme zukommen wie sie in C# bzw Java bereits implementiert sind. Eine Speicherverwaltung selbst zuschreiben ist ein riesen Aufwand welches am Ende keinen Profit abwirft und nur viele Arbeitsstunden kostet.

Das Argument geht jedes Mal komplett am Problem vorbei – C++ hat eine Speicherverwaltung, die genau so automatisch ist wie Javas – und eben zusätzlich noch deterministisch. Selber schreiben muss man garnichts.
Der enorme Vorteil ist, dass bei C++ Ressourcen automatisch verwaltet werden, während in Java nur Speicher verwaltet wird (und es dafür noch nicht einmal Garantien gibt, da auch ein GC, der nie etwas tut, ein gültiger GC ist). Solche Fehler wie CodingCats Dateien, deren Speicherabbilder sich gegenseitig abschießen weil es keine deterministische Freigabemethode gibt, sind in Java sehr hässlich bis unmöglich zu lösen; in C++ ist die Lösung jedoch bereits Teil des Sprachkonzepts, da es im Gegensatz zu Java und C# garantierte Finalisierung bietet (nicht nur manuelle Finalisierung durch finally). Und es gibt in „echten“ Anwendungen jede Menge nicht-Speicher-Ressourcen …

Oben wurde auch das Klassen Konzept bemängelt, aber Klassen bieten eine natürlichere Art Programme zu entwerfen da man auch in der Realität solche Einteilungen treffen kann.

Unsinn. OOP hilft, aber es zu erzwingen ist ein katastrophaler Fehler. In welche Klasse gehört min()?

PS kennt einer Singularity?
http://de.wikipedia.org/wiki/Singularity
Da sieht man was die Zukunft bringen wird...

Das Ziel von Singularity war afaik primär, C# an die Grenzen zu bringen und, sekundär, die Verbesserung von statischer Analyse sowie die Vorbereitung darauf, den NT-Kernel in Richtung eines Mikrokernels zu entwickeln. Singularity selber (oder ähnliche Projekte) wird der Kunde auch die nächsten 20 Jahre nicht sehen.

Man versucht heutzutage immer mehr dem Programmierer unter die Arme zu greifen. Halt z.B. mit Dingen wie GC. Aber sowas will man nicht unbedingt und teilweise hat man einfach keine Wahl. Das ist leider auch ein Grund, weshalb ich die neue C++ Version eher unfreudig begutachte.

Wo wird einem dort die Wahl genommen?

Hmm das hab ich falsch formuliert. Die neue C++ Version stört mich eher in der Hinsicht, dass sie sich Sprachen wie C# oder Java annähert. Und selbst ein GC war ja mal angedacht. Außerdem stören mich schlecht nachvollziehbare Konstrukte wie "auto", lambda expressions oder user-defined literals/suffixes.

Ja, das meiste davon finde ich auch hässlich. Jedoch hat es seine Existenzberechtigung und wenn man nicht will, kann man der Syntax fernbleiben – man wird sicher nie „versehentlich“ ein Lambda deklarieren, wenn man was anderes meinte.

[unique75]

min() gehört in die Klasse Number und von der sollten Dinge wie Int, Float, Fraction etc abgeleitet sein. Da C++ aber native Datentypen hat wars das mit dem schönen OOP. Sobald man:

int x;

hinschreibt, sollte der Compiler automatisch eine Instanz der Klasse Int anlegen, nichts anderes. Das was C++/Java/C# usw. tun ist einfach nur miserabel.

[Krishty]

min() gehört in die Klasse Number und von der sollten Dinge wie Int, Float, Fraction etc abgeleitet sein.

min() ist nicht vom internen Aufbau einer Zahl abhängig, also nein.

[unique75]

Was meinst du denn mit "internen" Aufbau einer Zahl?

[Krishty]

Ich weiß nicht, wie Methoden in Smalltalk realisiert sind, also sag, wenn ich falsch liege – aber in C++/C#/Java haben Klassenmethoden vollen Zugriff auf private Attribute und Methoden der Klasse. Und das würde im Fall von min() die Kapselung verletzen, weil die Beziehung „kleiner als“ öffentlich abrufbar und unabhängig von der konkreten Implementierung einer Zahl ist. Zudem gehört min() in kein Objekt, weil die beiden Zahlen bei dieser Operation gleichberechtigt sind.

[unique75]

Ich glaube du hängst viel zu sehr in der C++ Welt mit seinen nativen Datentypen. Mit den Klassenmethoden und Zugriffsrechten hast du Recht, das ist auch in Smalltalk und sicherlich jeder anderen Programmiersprache so. Stell dir vor du hast eine Klasse String, und diese hat eine Instanz-Methode add(char*). Dann schreibst du doch sicherlich auch sowas wie:

String str;
str.add("Hallo");

Es ist doch mehr als naheliegend dieselbe Annahme auch für eine Zahl zu treffen. Ich schreibe eine Klasse Integer mit der Instanzmethode min(int).

Integer i;
i.min(5)

Wenn jetzt der Compiler noch so intelligent wäre und die Klasse Integer vordefiniert hätte und alle kleingeschriebenen "int" als "Integer" deuten würde und sofort als Instanz der Klasse Integer intern anlegen würde, dann hättest du genau das was ich geschrieben habe. Aber der C++ Compiler ist halt dämlich und alle Welt will immer die nativen Datentypen.

[unique75]

Aber eine Frage bitte noch... das mit dem "kleiner als" hab ich nicht ganz verstanden... was meinst du damit und wieso ist es schlimm wenn das öffentlich abrufbar ist?

[Biolunar]

Was ist wenn ich zwei Häuser mit einander vergleichen will? Das Haus mit den wenigeren Fenstern sei das "kleinere" Haus. Um das Minimum davon zu bekommen, soll ich Haus von Number ableiten oder was?

[Aramis]

Wenn ich das richtig sehe, sind wir hier an einem Problem angekommen das funktionale (d.h. !OOP) Programmiersprachen (z.b. Haskell) durch „Meta”–Klassen (Typklassen) loesen. Alle Typen, die eine Kleiner–Als–Operation unterstuetzen, werden in einer Typklasse zusammengefasst und fuer diese wird dann die Min()–Funktion bereitgestellt. C++0x–Concepts (die ja leider aufgegeben wurden) sowie C++–Templates im Allgemeinen gehen in eine aehnliche Richtung.

Schlussendlich ist das C++/Java/C#–Klassenkonzept ziemlich engstirnig. Daher kritisiere ich bei Java auch den Zwang, alles in Klassen packen zu muessen – damit lassen sich nur zweidimensionale Strukturen abbilden, waehrend grade min() ein Beispiel fuer eine eher auf Meta-Ebene angesiedelte Funktionalitaet ist (genauer: man wird dazu gezwungen alles abzuflachen und in eine Klassenhierarchie zu pressen – das ist zwar moeglich, neigt aber dazu ziemlich verbose und ueberladen zu werden …).

[Krishty]

@unique75: Ah, ich sehe das Missverständnis … du sprichst von einer Funktion, die das Ergebnis direkt dem linken Operanden zuweist und ich von einer, die den kleineren Operanden zurückgibt …
(Mal mit aussagekräftigeren Funktionsnamen:) Ja, deine Version – i.ceilTo(5); gehört zur Methode gemacht, weil sie eine der Zahlen verändert.
Meine Version ohne Wirkung – x = getMininumOf(i, 5); darf hingegen keine Methode sein.
Darauf, welche Version erstrebenswerter ist, möchte ich mich nicht direkt festlegen. Persönlich würde ich meine bevorzugen, weil sie weniger Abhängigkeiten hat und ich Funktionen mit Wirkungen meide.

Aber eine Frage bitte noch... das mit dem "kleiner als" hab ich nicht ganz verstanden... was meinst du damit und wieso ist es schlimm wenn das öffentlich abrufbar ist?

Wenn es öffentlich abrufbar ist, braucht man keinen Zugriff auf private Methoden und Attribute, um die Aufgabe zu erledigen. Wenn die Funktion eine Methode ist, bekommt man diesen Zugriff aber, und erhöht dadurch das Risiko, die Funktion von der Implementierung des Objekts abhängig zu machen, wo es nicht sein muss; schwächt also die Kohäsion. Öffentliche Methoden, die nur andere öffentliche Methoden aufrufen, sind i.d.R. Zeichen schlechten Entwurfs.

[unique75]

Ich muss beiden (Biolunar und Aramis) widersprechen, aber ihr denkt alle irgendwie viel zu kompliziert. Ihr müsst euch endlich mal von der engstirnigen C++ Denkweise lösen und mal über den Tellerrand schauen (ist nicht böse gemeint, ich hab vor ein paar Jahren noch selber so gedacht, deswegen weiss ich wie verdammt schwer das ist).

min() ist eine stinknormale Instanzmethode. Es kann eine Klasse Haus geben, wenn ich zwei Häuser vergleichen will, überlade ich üblicherweise den = operator oder im Falle von "kleiner als" den < operator. Die min() Methode wird meist auf Basis des < implementiert. Will ich also 2 Häuser per min() vergleichen, so habe ich diese Methode einfach mal in der Klasse Haus zu implementieren... AUF INSTANZ-SEITE... und nicht in irgendeiner magischen Hilfsklasse auf Klassenseite. Was soll denn so ein grottenhässliches OOP :-)

Und was für ein Haus oder einen String gilt, soll einfach mal für eine Zahl ebenso gelten. Also implementiere ich eine Klasse Number, die ein min() implementiert. Es ist doch absolut schwachsinnig ein min(Haus, Haus), min(String, String), min(int, int) in irgendeiner nichtssagenden Klasse als static-Methoden zu haben. Aber dieses absolut OOP-hässliche Konzept seh ich auch ständig bei dem .NET Klassenframework. Da gibt es String-Concate Methoden auf Klassenseite, wo man es doch eigentlich der Stringinstanz selbst schicken kann, anstatt diese als 1. Parameter zu übergeben.

Lieber Aramis... mit Metaklassen hat das an der Stelle noch nix zu tun. Wenn ich dann damit anfange dann begreift keiner mehr was, weil sich viele nicht vorstellen können, dass auch eine Klasse eine stinknormale Instanz sein kann, der man genauso Methoden schicken kann.

[Krishty]

Ich muss beiden (Biolunar und Aramis) widersprechen, aber ihr denkt alle irgendwie viel zu kompliziert.

Ich glaube eher, Biolunar denkt für dich zu sarkastisch :)

[Aramis]

Ganz im Gegenteil: min() ist eine Operation, die ich fuer jeden Typ definieren kann, der eine Kleiner-Als-Operation kennt. Natuerlich kann man das OOisieren indem ich eine Basisklassen anlege, die den Kleiner-Gleich-Operator vorschreibt und in Abhaengigkeit davon min() definiert. Ebenso kann man auch in jeder Klasse, die ein min() unterstuetzt, es auf's Neue als a<b?a:b definieren.

Beides ziemlich, wie ich schon sagte, ueberladen. Ich haette lieber eine Notation um auszudruecken was min() eigentlich ist: eine direkt aus der Praesenz eines < ableitbare Operation. Oder von mir aus auch eine aus der Negation eines max() ableitbare Operation. Daher mag ich C++'s std::min – es ist sehr praegnant und kompakt. Was man von allen Versuchen, das ganze OOisch zu loesen, nicht sagen kann.

Nochmal: ich behaupte nicht, dass man mit strikter OO nicht all das modellieren kann. Ich sage nur, dass ich mir fuer viele Dinge praegnantere Notationen wuensche.

[unique75]

Krishty versteht mich grad auch nicht, also mach ichs mal konkret als C++ Code :-)

Code: Alles auswählen

class Integer
    {
    public:
          Integer(int i) {value = i;}
          bool operator<(const Number& param) {return this.value < param.value;}
          Integer& min(const Integer& param) {if (this < param) return this; else return param;}
    private:
           int   value;
    }

Integer var1 = 5;
Integer var2 = 7;
Integer var3 = var1.min(var2);

Ich bitte die schreckliche Formatierung zu entschuldigen, ich bin nicht so der Forenfan :-)
Wenn der Compiler halbwegs intelligent wäre hätte er so eine Klasse vordefiniert und würde jedes int als Instanz dieser Klasse anlegen. Wenn man die Klassenhierarchie richtig baut, hätte man als Oberklasse eine Klasse Number, die bestimmte Methoden polymorph vorhält, so z.B. min(). Aber das würde dann den C++ Programmieren wieder garnicht gefallen, weil sie dann virtuals brauchen, wenn mans richtig macht :-)

[Krishty]

Autsch. Nein, das ist weder gekapselt, noch generisch, noch erträglich zu lesen. Und hör auf, über den Compiler zu meckern und ihn mit dem Sprachstandard zu verwechseln; du kannst dir deine Zahlenklassen ja durchaus selber bauen.

[unique75]

Wegen der Lesbarkeit hab ich mich ja entschuldigt und was ist daran nicht gekapselt? Generisch muss das nicht sein, will man ein float so gibt es eine Klasse Float. Dann hat man auch den Vorteil Dinge wie << und >> nur in Integer zu implementieren, weil das Bitgeschiebe bei einer Float keinen Sinn macht. Da versagt übrigens die typische Bit-und-Speicher-Denkweise. Vermutlich erschlägt sich der C++ Programmierer aber wieder mal mit Templatesyntax und kritzelt 20 Methoden rein, die garnicht für floats sinnvoll sind. Ausserdem kann man mit dem obigen Konzept auch sinnvoll Dinge wie ne Klasse Fraction implementieren.

Generische Programmierung ist sowieso ein Graus wegen der Typen.

[Krishty]

was ist daran nicht gekapselt?

Zum dritten Mal: min() hat Zugriff auf die Interna der Zahl, wo es nicht nötig ist. Integer ist also unzureichend gekapselt. Wenn man für solche Kümmelfunktionen Zugriff gewährt, kann man gleich alles überall öffentlich machen.

Ausserdem kann man mit dem obigen Konzept auch sinnvoll Dinge wie ne Klasse Fraction implementieren.

Kann man auch ohne.

Generische Programmierung ist sowieso ein Graus wegen der Typen.

Gerade generische Programmierung erlaubt das Komponieren von Klassen, die du von Hand ausschreibst – ein Musterbeispiel sind die automatisch generierten Operatoren in boost, mit denen jedes Implementieren oder Verbieten aller vorstellbaren arithmetischen Operationen für beliebige Typen zum Zweizeiler wird.

[Aramis]

Generische Programmierung ist sowieso ein Graus wegen der Typen.

Wieso? Generische Programmierung im Allgemeinen oder ihre Implementierung in den gaengigen imperativen Programmiersprachen. Bei ersterem wuerde ich nicht zustimmen, bei letzterem schon.

Vermutlich erschlägt sich der C++ Programmierer aber wieder mal mit Templatesyntax und kritzelt 20 Methoden rein, die garnicht für floats sinnvoll sind.

Nein, das macht der C++-Programmierer nicht. Wie wir alle wissen, debugged er 24/7 seinen Speichermanager.

[unique75]

Lieber Aramis

ne ich meinte wirklich nur die Implementierung in den Sprachen. Es ist einfach grausam was da abgeht um Reflection, Lamdas usw. in die Sprache zu pressen. Es wird komplizierter und komplizierter und man kann schlussendlich einen winzigen Bruchteil von dem machen, was in einer echten dynamischen Sprache möglich ist. Das versuchen sie ja seit Ewigkeiten in Java/C# und jetzt wohl auch noch in C++ hinzukriegen. Wird nur nix Vernünftiges draus :-)

Meine Kommentare sind auch ein bisschen zynisch, ich weiss... also bitte nicht allzu sehr auf die Goldwaage legen wenn ich mal irgendwelche Zahlen rauswerfe :-)

[BeRsErKeR]

Krishty versteht mich grad auch nicht, also mach ichs mal konkret als C++ Code :-)

Code: Alles auswählen

class Integer
    {
    public:
          Integer(int i) {value = i;}
          bool operator<(const Number& param) {return this.value < param.value;}
          Integer& min(const Integer& param) {if (this < param) return this; else return param;}
    private:
           int   value;
    }

Integer var1 = 5;
Integer var2 = 7;
Integer var3 = var1.min(var2);

Ich bitte die schreckliche Formatierung zu entschuldigen, ich bin nicht so der Forenfan :-)
Wenn der Compiler halbwegs intelligent wäre hätte er so eine Klasse vordefiniert und würde jedes int als Instanz dieser Klasse anlegen. Wenn man die Klassenhierarchie richtig baut, hätte man als Oberklasse eine Klasse Number, die bestimmte Methoden polymorph vorhält, so z.B. min(). Aber das würde dann den C++ Programmieren wieder garnicht gefallen, weil sie dann virtuals brauchen, wenn mans richtig macht :-)

Für mich sind Methoden Aktionen, die ein Objekt durchführen kann oder Anfragen, die ich an das Objekt stellen kann. Eine min/max-Funktionalität ist aber nichts was ich direkt (ohne anderes Objekt) abfragen kann oder auf dem Objekt anwenden kann. Es ändert das Objekt nicht und fragt nicht explizit nur Eigenschaften des einen Objektes ab, daher finde ich es nicht nur häßlich, sondern auch unlogisch, min/max direkt als Methode zu implementieren. Methoden dienen doch dazu ein sicheres Interface nach außen anzubieten, damit man nicht direkt auf die Member zugreifen kann. Wie Krishty schon sagte, ansonsten kann ich gleich alles public deklarieren. Wenn die Methoden nichts mit internen Membern machen, dann brauch die Methode nicht Teil der Klasse sein, dann tut es eine globale Funktion genauso und ist zudem logischer.

Dein vorher erwähntes String::add ist wieder was anderes. Es greift auf interne Member des Strings zu und ändert somit das Objekt. Es kann gar nicht global realisiert werden ohne die Member von String public zu deklarieren.

Aber gerade durch den '<' Operator sind min und max dafür prädestiniert global (oder halt im namespace) zu sein. Es macht einfach keinen Sinn soetwas an ein Objekt zu binden. Das Objekt ist nicht dazu da, etwas zu vergleichen! Es wird verglichen!

[Alexander Kornrumpf]

Ich unterbreche euch ja nur ungerne aber ich glaube das min Beispiel ist total ungeeignet ist um irgendwas sinnvolles herauszubekommen.

1) Etwas was an Java total nervt, ist dass es überhaupt Primitive gibt, für die völlig andere Regeln gelten als für alles andere. Weil es die Konsistenz aus der Sprache nimmt. Das strikt objektorientierte, was Java als Vorteil verkaufen will wurde eben nicht bis zum Ende durchgezogen. Das kann man C++ nicht vorwerfen, da C++ wenigstens in sich konsistent ist. Die meisten Typen können so entworfen werden dass sie sich in der Verwendung relativ ähnlich zu int verhalten.

Natürlich kann man jetzt über eine hypothetische Sprache philosophieren, die tatsächlich vollkommen objektorientiert ist, und auch über deren Sinnhaftigkeit. In Java hat man aber eben nur die Möglichkeit min(int,int) als statisches Member von Math o.ä. zu definieren. Und darüber hatte Krishty sich ja schon ganz zu Anfang amüsiert.

2) Ich verstehe nicht, was das ganze Argument mit den "Interna einer Zahl" soll. Die einzigen Interna die eine Zahl haben kann ist ihr Wert. Und den muss man kennen um min zu bestimmen. Ob man da jetzt direkt drankommt, über friend oder über irgendein "getValue" äquivalent, ändert am Grade der Kapselung meiner Meinung nach nicht viel. Wenn man es ganz genau nehmen will trifft bei so einfachen Typen auch jede schnittstelle Annahmen über die interna. Wenn intern ein double gespeichert ist, kann die schnittstelle kein float als vergleichskriterium zurückgeben. Wenn die Klasse z.B. rationale Zahlen als 2 unsigneds + vorzeichen ablegt, brauchst du auch genau diese Konstellation um den Wertvergleich in der selben Genauigkeit durchführen zu können.