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

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"

DEvent

volkard schrieb:

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.

*hust* so wie die Funktion sqrt() *hust* ?

DEvent

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

Was meinste eigentlich damit ?

PS: sry für 3fach Post, aber bin grad zu faul das sauber in einen Post zu quoten.

DEvent schrieb:

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"

Falsch!
1. Eine Klasse und ein Namespace sind was ganz anderes.
2. string verhält sich zu std NICHT wie sqrt zu math.

DocJunioR schrieb:

Aaallsoooo...
...
Klassen sind Funktionsgruppen.
Beispielsweise sämtliche Sachen, die mit Textdateien in einem Textprogramm zu tun haben könnten in eine Klasse (also laden, speichern, löschen, ...)
...

Genau so funktioniert OOP _NICHT_ - Du missbrauchst Klassen als
Namespaces, ist ein klassischer Fehler von Umsteigern. in ganz
seltenen Fällen macht sowas Sinn (das double-Beispel von Volkard),
da nennt sich das dann Util-Klasse und durch static imports
lässt sich das dann sehr elegant nutzen.

Aber Klassen als Funktionsgruppen zu bezeichnen ist IMHO irreführend.

Gruss,

Stefan

THX 1138

DEvent schrieb:

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

Was meinste eigentlich damit ?

PS: sry für 3fach Post, aber bin grad zu faul das sauber in einen Post zu quoten.

Weil 2^32 logischer Gebrauch wäre, anstatt pow(2, 32) oder was auch immer..

volkard

Und was ist mit Tee? schrieb:

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

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

Bashar

Ich glaub ich versteh grad den Witz nicht

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

Wirklich sehr schön aufzurufen und noch dazu derartig selbsterklärend im Vergleich zu folgendem:

class Math {
    public:
        template<typename T>
        static T add(T lhs, T rhs) {
            return lhs + rhs;
        }
};

// ...

int result = Math.add(17, 42);

volkard

interessierter schrieb:

int result = Add<int>()( 17, 42 );
Wirklich sehr schön aufzurufen und noch dazu derartig selbsterklärend im Vergleich zu folgendem:
class Math {
    public:
        template<typename T>
        static T add(T lhs, T rhs) {
            return lhs + rhs;
        }
};
// ...
int result = Math.add(17, 42);

da haste nicht aufgepasst.

#define addInt Add<int>
...
int result=addInt(17,42);

ich will den schmarrn doch gar nicht, sondern ne globale funktion (und wo angemessen natürlich nen überladenen operator).

da haste nicht aufgepasst.
#define addInt Add<int>
...
int result=addInt(17,42);

Jetzt versuchst du aber schon sehr zwanghaft etwas zu verteidigen, nur um es zu verteidigen.

#define add(a, b) Math.add(a, b)

int i = add(3, 2);
double d = add(3.0, 2.0);

volkard

interessierter schrieb:

da haste nicht aufgepasst.
#define addInt Add<int>
...
int result=addInt(17,42);
Jetzt versuchst du aber schon sehr zwanghaft etwas zu verteidigen, nur um es zu verteidigen.

ich lehne doch

template<typename T> 
struct Add

ab. der hat dabei die fehler gemacht, die ich den Math-benutzern vorwerfe. und ne schreibverkomplizierung dazu, die er gar nicht bemerkt hatte.