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

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.

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.

volkard schrieb:

ich erinnere mich auch mit schrecken an
class BubbleSort:public SortAlgorithm...

Wieso? Wenn SortAlgorithm ein allgemeiens Interface ist, kann mans z.B. dazu verwenden, um alle möglichen Listen mit seinem Algo zu sortieren.

Gregor schrieb:

BTW: Wie macht man eigentlich folgendes, wenn man nicht OOP betreiben möchte...

Man hat einen Algorithmus, der sehr lange braucht, deshalb will man den Fortschritt durch eine Art ProgressBar visualisieren.

Im OOP-Fall würde ich mir da praktisch so ne Klasse basteln, wie volkard sie gerade mit dem Sortieren vorgeschlagen hat. Die Objekte dieser Klasse hätten dann halt einen inneren Zustand, der den aktuellen Fortschritt repräsentiert, den man von außen abfragen könnte. Wie macht man das ohne OOP? Da müsste man wohl mit Funktionen arbeiten, die Nebenwirkungen haben - wie auch die entsprechende Methode im OOP-Fall. Diese Nebenwirkungen wären aber nicht gerade lokal oder so... Wie baut man soetwas also vernünftig auf?

Da hätte ich jetzt auch sofort ans Observer Pattern gedacht bzw. Listener, wie es in Java üblich ist.

Math.sqrt ist jetzt nicht wirklich tolles OOP, aber eigentlich ganz praktisch, man muss nur Math schreiben und auf Punkt drücken und schon sieht man alle Math-Funktionen die man hat.

THX 1138

Bitte geben Sie einen Ben schrieb:

volkard schrieb:

ich erinnere mich auch mit schrecken an
class BubbleSort:public SortAlgorithm...

Wieso? Wenn SortAlgorithm ein allgemeiens Interface ist, kann mans z.B. dazu verwenden, um alle möglichen Listen mit seinem Algo zu sortieren.

..siehe STL

Bitte geben Sie einen Ben schrieb:

...
Math.sqrt ist jetzt nicht wirklich tolles OOP, aber eigentlich ganz praktisch, man muss nur Math schreiben und auf Punkt drücken und schon sieht man alle Math-Funktionen die man hat.

Warum hat man eigentlich operator^ nicht reserviert? Jetzt haben gewisse Leute das mit so 'ner Art sauberem Zeiger (brr) überladen.

...ne im Ernst...wenn Du double um sqrt erweitern willst, musst Du es adaptieren, kapseln, was auch immer. Wenn du sqrt auf alle Typen anwenden willst, mach'n template (Generikum? k^Kann k^ein Java..) und pack's in 'nen Namespace...und wenn du gut genug bist, schaffst du es nach std

Bashar

1310-Logik schrieb:

Bitte geben Sie einen Ben schrieb:

Wieso? Wenn SortAlgorithm ein allgemeiens Interface ist, kann mans z.B. dazu verwenden, um alle möglichen Listen mit seinem Algo zu sortieren.

..siehe STL

Wo bietet die STL so ein allgemeines Interface? std::sort ist jedenfalls kein solches. Man kann sich den benutzten Algorithmus nicht (dynamisch) aussuchen.

BTW ich weiss nicht, ob SortAlgorithm jetzt ueberhaupt ein tolles Beispiel fuer eine sinnvolle Klasse ist. Alle Sortieralgorithmen haben das gleiche Interface, OK. Sie haben sogar das gleiche Interface wie jede Funktion, die eine Sequenz (mit bestimmten Eigenschaften) sortiert. Also warum sollte das ein Punkt fuer die OOP sein, wenn man einfach mit der entsprechenden Funktion direkt hantieren koennte? (Vernuempftige funktionale Sprachfeatures vorausgesetzt)

THX 1138

Bashar schrieb:

1310-Logik schrieb:

Bitte geben Sie einen Ben schrieb:

Wieso? Wenn SortAlgorithm ein allgemeiens Interface ist, kann mans z.B. dazu verwenden, um alle möglichen Listen mit seinem Algo zu sortieren.

..siehe STL

Wo bietet die STL so ein allgemeines Interface? std::sort ist jedenfalls kein solches. Man kann sich den benutzten Algorithmus nicht (dynamisch) aussuchen.

Dann siehe Boost Graph Library. Ich meinte eher allgemein die Generizität der STL.

Wieso eine Mathe Klasse?

template<typename T>
struct Add
{
    T operator()( const T& lhs, const T& rhs )
    {
        return lhs + rhs;
    }
}

eventuell noch spezialisieren, das wars.
Aufruf

int result = Add<int>( 17, 42 );

Da brauch ich kein Objekt extra anzugeben ala

Math.Add( 17, 42 )

Soviel zu dem

otze

byto schrieb:

In Java gibts dafür Static Imports:
import static java.lang.Math.*;
...
double y = sqrt(5.0);

drücken diese beiden zeilen nicht eigentlich folgendes aus?

"eigentlich ist es scheisse, dass sqrt in eine Klasse gesteckt wurde"

byto

Die Klasse Math in Java enthält ja nicht diese trivialen Operationen sondern die etwas komplexeren Funktionen wie sqrt, log, sin etc. sowie die Konstanten E und PI. Diese Methoden sind statisch und öffentlich, so dass man sie ohne Objektinstanzierung überall verwenden kann. Die trivialen Methoden der Addition, Subtraktion, ... sind für die primitiven Typen ganz normal über die +, -, ... Operatoren verfügbar.

byto schrieb:

Die Klasse Math in Java enthält ja nicht diese trivialen Operationen sondern die etwas komplexeren Funktionen wie sqrt, log, sin etc. sowie die Konstanten E und PI. Diese Methoden sind statisch und öffentlich, so dass man sie ohne Objektinstanzierung überall verwenden kann. Die trivialen Methoden der Addition, Subtraktion, ... sind für die primitiven Typen ganz normal über die +, -, ... Operatoren verfügbar.

Das ist jetzt aber kein Gegenargument zu otze.

byto

wotze schrieb:

Das ist jetzt aber kein Gegenargument zu otze.

Race condition...

DEvent

otze schrieb:

byto schrieb:
In Java gibts dafür Static Imports:
import static java.lang.Math.*;
...
double y = sqrt(5.0);
drücken diese beiden zeilen nicht eigentlich folgendes aus?

"eigentlich ist es scheisse, dass sqrt in eine Klasse gesteckt wurde"

using namespace std;

{
    string blaaa;
}

"eigentlich ist es scheisse, dass string in einen Namespace gesteckt wurde"