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

Marc++us

DEvent schrieb:

In eine 100% OOP-Sprache machma das aber so.

Aber eher notgedrungen, nicht weil es irgendwas mit OOP zu tun hat. Man packt hier "freie" Funktionen eben in eine Klasse, weil die Sprache nichts anderes unterstützt. Das ist einfach nur eine Emulation von freien Funktionen in einem Namespace. So wie man in C Klassen, virtuelle Methoden und Objekte durch Strukturen und Zeiger emulieren kann, muß man hier Funktionen durch Klassen emulieren. Mehr steckt doch nicht dahinter.

Liest man sich die Designratschläge zu OO-Designs durch, so ist gerade diese Vorgehensweise "alles was noch übrig ist in eine Hilfsklasse stecken" eine ziemliche Todsünde.

Offensichtlich zeigen solche Dinge eher, daß Sprachen, die ein Paradigma "zu 100%" erfüllen, schon zwangsläufig irgendwo unschöne Kompromisse enthalten müssen.

rüdiger

DEvent schrieb:

rüdiger schrieb:

[...]

Das ist keine Objekt Orientierte Programmierung. Ein Code ist ja nicht OO nur weil es das Wort class missbraucht äh enthält. Für so etwas gibt es in C++ übrigens Namespaces

In eine 100% OOP-Sprache machma das aber so.
C++ ist ja keine 100% OOP-Sprache, es vereint ja viele Programmierparadigmen in einer Sprache.

In einer 100% OOP-Sprache programmiert man nicht OO? Ich verstehe irgend wie nicht was du mir sagen willst.

DEvent

"alles was noch übrig ist in eine Hilfsklasse stecken"

Man fast alle Methoden die einer Kategorie angehören in eine Klasse, der Name dieser Klasse beschreibt die Kategorie.
Ich verstehe nicht wo das Problem ist, man kann auch auf statische Methoden verzichten und sowas schreiben:
[quote]

class Mathe
{
   private double nummer;

   public Mathe(double nummer)
   {
       this.nummer = nummer;
   }

   public double sqr(double potenz)
   {
       double y = nummer;
       for ( int i = 0; i < potenz; i++ ) y *= y;
       return y;
   }

   // weitere mathematische Funktionen
}

// verwendung:
void main()
{
    double x = 5.0;
    double y = new Mathe(x).sqr(5);
}

Man kann es natürlich auch ganz cool machen:

class double
{
    public double(/* irgendwas was ein fixnum ist*/ x)
    {
        /* x intern speichern */
    }

    public double sqr(double potenz);

   // weitere mathematische Funktionen
}

// verwendung:
{
    double x = 5.0;
    double y = x.sqr(10);
}

Allerdings es das etwas übertrieben und so gibt es halt statische Methoden. Damit werden Klassen einfach nur auf eine Art package reduziert, weil man auf Instanzierung und Vererbung verzichtet. Wenn man die beiden Dinge nicht braucht, wozu das einem aufzwingen?
Im Gegensatzt zu frei liegen Funktionen hat man aber den Vorteil das man diese Funktionen zusammengefasst hat. Sie sind nicht mehr kontexfrei.
Zum Beispiel verhält sich die Funktion Betrag anders, wenn man sie bei Zahlen oder bei Vektoren verwendet wird.
Bei einer Zahl ist Betrag einfach nur

Zahl betrag(Zahl x) { return |x|; }

Bei Vektor ist es

Zahl betrag(Vektor x) { return wurzel(x.a0 * x.a1 * ... x.an); }

So machtman die eine Funktion in die Klasse Mathe und die andere in die Klasse Vektor.
Ein namespace ist dann dazu da, verschiede Klassen in ein Modul zusammen zufassen. Z.B. gehören die Klassen Mathe und Vektor in das Modul Mathematik. In das Modul System gehören die Klassen InputOutput, File, Peripherie...

Liest man sich die Designratschläge zu OO-Designs durch, so ist gerade diese Vorgehensweise "alles was noch übrig ist in eine Hilfsklasse stecken" eine ziemliche Todsünde.

Man hat ja normalerweise nichts übrig. Wie oben beschrieben steckt man jede "Funktion" der Kategorie nach in eine Klasse. Gut, Klassen die nur statische Methoden haben sind degenerierte Klassen. Aber das ist ja nur Faultheit des Programmierers (siehe Beispiel ganz oben).

rüdiger

@DEvent
Eine Klasse ist keine Kategorie. Da hast du OOP falsch verstanden.

Der richtige Ansatz für sqrt, wenn man es OO machen will, wäre, wie volkard schon gesagt hat

class double {
// ...
public:
  double sqrt() const;
};

12.15.sqrt();
double c=9.0;
c.sqrt();

So etwas können aber die wenigsten Programmiersprachen. Java und C# zwingen dich einfach dazu, das du Klassen missbrauchst.

Das hat nichts mit Objekt Orientierter Programmierung zu tun. (Es heißt ja nicht Klassen Orientierte Programmierung. Klassen sind für OOP überhaupt nicht wichtig, sie sind nur ein Hilfsmittel einiger Programmiersprachen)

Apollon

@ DEvent: Du hast einige sehr schoene Bilder auf deiner Homepage. Da kriege ich fast schon Heimweh. Trotzdem hast Du Unrecht was OOP angeht.

DEvent

So etwas können aber die wenigsten Programmiersprachen.

Welche können das den ?

@Apollon: danke

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.