OOP: soll man jetzt alles in ne Klasse packen oder watt?

[Kenner des Ruby]

Doktor Prokt schrieb:

volkard schrieb:

DEvent schrieb:

Welche können das den ?

ich würd's zuerst probieren bei smalltalk, lisp und forth.

Mal sehen, wie es in Ruby aussieht:

class Float
  def sqrt
    return Math.sqrt(self)
   end
end

print 9.8696044.sqrt

Ruby ist doch kagge

[Delryn]

Zumindest die Syntax ist echt hässlich, da sieht man ja gar nicht wo was anfängt

[DEvent]

jetzt braucht nicht mehr jeder, der mit doubles rechnen will, zum taschenrechner zu rennen. jetzt geht es genauso wie +, -, * und /. du wirst nicht bezweifeln, daß jeder schreiben kann double x; double y=x+5; die arithmetischen operatoren sind solche frei verfügbares wissen. und genauso verfügbar darf die kunst des radizierens sein.

Ja ist doch.

double y = Math.sqrt(5.0);

Kannst überall aufrufen, nur muss die Klasse Math bekannt sein. Ich habe doch schon erklärt das solche Klassen eine vereinfachte Form von deinem Taschenrechner sind. Man erspart sich halt erst ein Taschenrechner-Objekt zu erstellen. Faultheit des Programmierers halt.

[otze]

trotzdem würde ich, nachdem ich das 3millionste mal "Math." geschrieben hab, mir ne freie funktion wünschen. das "Math." bringt mir ja nicht irgendwelche wichtigen weiteren informationen.

oder ums anders auszudrücken: wieso ist es so wichtig, dass es Math.sqrt ist, und nicht einfach sqrt?

[byto]

In Java gibts dafür Static Imports:

import static java.lang.Math.*;
...
double y = sqrt(5.0);

[Bashar]

LOL
von der einstigen Einfachheit von Java ist vor lauter Frickelei bald nicht mehr viel übrig

[volkard]

Bashar schrieb:

LOL
von der einstigen Einfachheit von Java ist vor lauter Frickelei bald nicht mehr viel übrig

och, wie nehmen halt

using namespace std;
double y = sqrt(5.0);

weil jemand der meinung war, man solle sqrt in einen namespace sperren. jetzt bleibt wohl nur noch die diskussion übrig, warum man eine klasse verwendet, wo ein namespace es sagen würde. und das führt dann wohl zur einsicht, daß java-klassen (wo man objekte machen kann) sowohl klasse als auch namespaces (mit import) sind. seltsame welt.
und es bleibt zu erwähnen, daß keineswegst die objektorientierung dazu treibt, sqrt in eine klasse zu stopfen. bereits früh wurde statt eines anschaulichen objekts taschenrechner auf sachen gesetzt, so nix mehr mit objektorientierung zu tun haben.

[Gregor]

Bashar schrieb:

LOL
von der einstigen Einfachheit von Java ist vor lauter Frickelei bald nicht mehr viel übrig

Java verändert sich in letzter Zeit tatsächlich ziemlich stark und einige der neuen Features (und der kommenden Features) haben das Zeug dazu, das typische Aussehen von Javacode extrem zu verändern. Oder sie haben zumindest das Zeug dazu alternative "Programmierstile" für Java zu etablieren. Seit Java 5 trifft das wohl vor allem auf die neuen Annotations zu. In Java 6 kommt kein neues Sprachfeature. Und in Java 7 sind momentan Closures im Gespräch, die sicherlich einiges verändern könnten.

...ich bin mir nicht so ganz sicher, was davon zu halten ist.

[volkard]

Gregor schrieb:

...ich bin mir nicht so ganz sicher, was davon zu halten ist.

bald isses vielleicht nur noch c++ in einem anderen gewand.

[Gregor]

volkard schrieb:

bald isses vielleicht nur noch c++ in einem anderen gewand.

Sieht für mich nicht so aus, als ob die sich bei der Weiterentwicklung von Java an C++ orientieren.

[byto]

Bashar schrieb:

LOL
von der einstigen Einfachheit von Java ist vor lauter Frickelei bald nicht mehr viel übrig

Irgendwie ist die Argumentation hier manchmal mehr als merkwürdig. Ein paar Beiträge zuvor wurde noch bemängelt, dass man schreiben muss Math.sqrt() anstatt einfach sqrt(). Jetzt - da es ja offenbar mit static imports doch geht - ist das aber auch wieder falsch. Was denn nun...

[volkard]

byto schrieb:

Ein paar Beiträge zuvor wurde noch bemängelt, dass man schreiben muss Math.sqrt() anstatt einfach sqrt(). Jetzt - da es ja offenbar mit static imports doch geht - ist das aber auch wieder falsch. Was denn nun...

naja, statt sqrt global zu machen,

wird eine klasse Math gabaut, die funktion sqrt in der klasse Math als methode reingesteckt, die methode sqrt wird zum gemeinbesitz aller objekte der klasse Math erklärt, damit man von der klasse kein objekt braucht, und dann sagt man, sich an das ziel der ganzen sache erinnernd, "ich will so tun, als sei das eine globale funktion".

ob das nun gefrickel ist, sei dahingestellt, aber es ist verständlich, wenn zartbesaitete gemüter dabei unglücklich werden.

[byto]

Nicht ganz richtig. Mit Hilfe von static den globalen Zugriff ohne Objektinstanzierung zu gewährleisten, ist lediglich ein Anwendungsfall von static. Er setzt voraus, dass die Methode oder Variable nicht nur static sondern auch public ist. Ich kann aber genauso gut die Variable auf private static setzen. Somit ist sie nur für Objekte diesen Typs sichtbar, somit also nicht global.

Es macht mehr als Sinn, dass statische Methoden/Variablen in Klassen definiert werden. Es bietet einfach vielfältige Möglichkeiten, Zugriff auf Objekte zu ermöglichen (s. Fabrikmethoden, ...). Dass zustandslose Funktionalität mit globalem Zugriff sich nicht ohne weiteres in die OOP pressen lässt, ist klar. Aber wie groß ist der Anteil solcher Funktionalität in komplexen Softwareprojekten: < 1% oder doch <0.1% ?

[volkard]

byto schrieb:

Aber wie groß ist der Anteil solcher Funktionalität in komplexen Softwareprojekten: < 1% oder doch <0.1% ?

die selbstgeschriebenen globalen funktionen wiegen unter 10kbyte, egal wie groß die software wird.

[Gregor]

volkard schrieb:

byto schrieb:

Aber wie groß ist der Anteil solcher Funktionalität in komplexen Softwareprojekten: < 1% oder doch <0.1% ?

die selbstgeschriebenen globalen funktionen wiegen unter 10kbyte, egal wie groß die software wird.

Dabei zählst Du Funktionen, die in einem Namespace sind, nicht zu den globalen Funktionen, oder?

[volkard]

Gregor schrieb:

Dabei zählst Du Funktionen, die in einem Namespace sind, nicht zu den globalen Funktionen, oder?

doch.

[Gregor]

volkard schrieb:

Gregor schrieb:

Dabei zählst Du Funktionen, die in einem Namespace sind, nicht zu den globalen Funktionen, oder?

doch.

Wie kommst Du damit auf 10kByte? Ich bin gerade mit einem kleinen C++Projekt beschäftigt und stelle zumindest bei mir fest, dass der Anteil der globalen Funktionen enorm ist. Hier sind gerade etwa 30/40 kByte globale Funktionen.

...naja, vielleicht entspricht mein kleines Projekt hier nicht gerade dem Durchschnitt, das kann sein.

[Bashar]

byto schrieb:

Irgendwie ist die Argumentation hier manchmal mehr als merkwürdig. Ein paar Beiträge zuvor wurde noch bemängelt, dass man schreiben muss Math.sqrt() anstatt einfach sqrt(). Jetzt - da es ja offenbar mit static imports doch geht - ist das aber auch wieder falsch. Was denn nun...

Welche Argumentation genau meinst du? Ich hab weder das eine noch das andere gesagt.

[qwerty`]

In Java 6 kommt kein neues Sprachfeature. Und in Java 7 sind momentan Closures im Gespräch, die sicherlich einiges verändern könnten.

Was mich daran wirklich stört ist der allgemeine Trend dahingehend. C# wird in der nächsten Version auch mit derartigen Features überhäuft, so dass einem bald wirklich nichts mehr überbleibt als auf der Welle mitzureiten. Ich für meinen Teil beginne Java 1.4 zu vermissen ..

[volkard]

Gregor schrieb:

Ich bin gerade mit einem kleinen C++Projekt beschäftigt und stelle zumindest bei mir fest, dass der Anteil der globalen Funktionen enorm ist. Hier sind gerade etwa 30/40 kByte globale Funktionen.

ok, es mögen auch 40kByte werden. aber irgendwie hüpfen dann immer wiedermal ganze gruppen dieser funktionen doch in ne klasse rein. sofern man sich die zeit dazu nimmt, immer wieder mal aufzuräumen.