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

DEvent

So etwas können aber die wenigsten Programmiersprachen.

Welche können das den ?

volkard

DEvent schrieb:

Man fast alle Methoden die einer Kategorie angehören in eine Klasse, der Name dieser Klasse beschreibt die Kategorie.

DIN 2342 definiert Begriff als eine "Denkeinheit, die aus einer Menge von Gegenständen unter Ermittlung der diesen Gegenständen gemeinsamen Eigenschaften mittels Abstraktion gebildet wird".
und genau so ein ding brauchte die programmierung.

eine klasse ist eine menge von objekten. klassen sind vereinfachte modelle von begriffen. statt aller begrifflichen beziehungen und gemeinsamer eigenschaften können klassen nur recht wenig ausdrücken.
vor allem
was hat so ein ding?
was kann so ein ding?
was ist so ein ding?

was hat so ein ding? -> die attribute
was kann so ein ding? -> die methoden
was ist so ein ding? -> die basisklassen

du definierst den begriff Math-Objekt und machst die existenz von Gegenständen dieses begriffs notwendig, um doubles zu manipulieren. so dinge heißen in der außenwelt taschenrechner.

double y = new Taschenrechner().sqrt(25);//y=5

*jeder*, der sowas eine zeit lang benutzen muss, schreibt in seine eigene klasse rein:

double sqrt(double x){
   return new Taschenrechner().sqrt(x);
}

na, diese codevervielfachung wollen wir doch nicht provozieren, gell.

die fans globaler funktionen wollen eher die fähigkeiten um doublemanipulationen zu frei verfügbarem wissen erklären, ein wissen, so allgemein, daß jedes objekt auf der welt es benutzen kann. kopfrechnen statt taschenrechner.
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.

volkard

DEvent schrieb:

Welche können das den ?

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

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

Bashar

volkard schrieb:

DEvent schrieb:

Welche können das den ?

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

In Lisp gibt es keine syntaktische Unterscheidung von Funktions- und Methoden. Schon allein die Idee, dass eine Methode zu einer Klasse gehört, ist Lisp fremd.

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?