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

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.

otze

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"

schön, dass du hier die analogie zu einem namespace benutzt. Richtig ist, dass das java beispiel hier namespace funktionalität simuliert.
Leider gehts in diesem Thread um die Frage, ob man alles in eine Klasse stecken soll und nicht darum, wie man einen namespace in java simuliert.
Du merkst doch selbst, dass sqrt danach schreit, ohne objekt oder klassenbezug aufgerufen zu werden, deshalb wurde hier auch import static vorgeschlagen. Was also ist dann deiner Meinung nach an der aussage falsch, dass es falsch ist, sqrt in eine Klasse zu packen?
Dass java es nicht kann ist eine sache, eine andere sache ist, dann daran festzuhalten, dass dieses Beispiel ein gutes beispiel dafür ist, alles in eine Klasse packen zu können.

schon lustig, wie sich anhänger einer sprache, deren workaround für die doch-nicht-so-tolle strenge typisierung zufällig turing-vollständig war, und nun für alles missbraucht wird, was in anderen sprachen schöner und einfacher lösbar ist, über die krücken von anderen sprachen so lange und ausgiebig zerfetzen können.

sozialologe schrieb:

schon lustig, wie sich anhänger einer sprache, deren workaround für die doch-nicht-so-tolle strenge typisierung zufällig turing-vollständig war, und nun für alles missbraucht wird, was in anderen sprachen schöner und einfacher lösbar ist, über die krücken von anderen sprachen so lange und ausgiebig zerfetzen können.

C++ rockt eben alles weg

Dass java es nicht kann ist eine sache, eine andere sache ist, dann daran festzuhalten, dass dieses Beispiel ein gutes beispiel dafür ist, alles in eine Klasse packen zu können.

Das kommt eben auf den Standpunkt an, den man vertritt. Wenn man davon ausgeht freie Funktionen nicht zu erlauben um das Konzept der Sprache nicht zu brechen, bzw. keine Außnahmen zu schaffen, dann macht es einfach Sinn "alles in eine Klasse packen zu können".

C++ ist eine Multiparadigma-Sprache, Java nicht. Freie Funktionen bergen keinen derartigen Vorteil für Java Programmierer, der es rechtfertigen würde eine derartige Außnahme in die Sprache aufzunehmen. Die selbe Diskussion gibt es in Java Communities derzeit bezüglich Closures (weil es in diesem Thread angesprochen wurde), da Closures vom Prinzip her eine Außnahme bilden würden und freien Funktionen sehr nahe kommen würde (eigenes Class Objekt für sämtliche Closures, also eigentlich nicht wirklich einer Klasse zuordenbar).

interessierter schrieb:

Dass java es nicht kann ist eine sache, eine andere sache ist, dann daran festzuhalten, dass dieses Beispiel ein gutes beispiel dafür ist, alles in eine Klasse packen zu können.

Das kommt eben auf den Standpunkt an, den man vertritt. Wenn man davon ausgeht freie Funktionen nicht zu erlauben um das Konzept der Sprache nicht zu brechen, bzw. keine Außnahmen zu schaffen, dann macht es einfach Sinn "alles in eine Klasse packen zu können".

Ich will aber ausdrücken, was gemeint ist, und mich nicht von Regeln der Sprache beschränken lassen.

DEvent

1310-Logik schrieb:

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..

Das wäre wirklich cool gewesen für Java. Wenn es noch mit Fließkommazahlen ginge:

2.34^32.3456

byto

^ ist halt das bitweise XOR, soviel ich weiss nicht nur in Java sondern auch in C++.

volkard

byto schrieb:

^ ist halt das bitweise XOR, soviel ich weiss nicht nur in Java sondern auch in C++.

geh einfach mal davon aus, daß das bekannt ist, und man sich dennoch 2.34^32.3456 zum potenzieren wünscht. dafür kann ^ ruhig die bedeutung von xor verlieren. braucht eh keiner, weil xor hübscher ist.

int x = 3 xor 4;

byto

Um ehrlich zu sein, ist mir das ziemlich wurscht. Ich brauche weder pow noch sqrt noch irgendwelche anderen höheren mathematischen Funktionen häufig. Der Anteil funktionaler Programmteile tendiert bei mir in der Regel gegen null. Aber wenn ich mal C++ lerne, dann werde ich auch mal einen Taschenrechner programmieren und mich des Lebens freuen über diese großartige Operatorüberladung und so weiter... :p

kartoffelsack

Das sqrt-Beispiel ist ein gutes Beispiel dafür, dass es - nur weil es eine 'objektorientierte' Sprache ist - nicht immer sinnvoll ist, alles objektorientiert zu machen (bzw. dass Java eben doch keine 100% oo-Sprache ist, sonst ginge ja 1.1.sqrt() )

Trotzdem ist es letztlich kein Unterschied, ob sqrt jetzt in einem namespace 'math' oder als statische Funktion in einer Klasse 'Math' liegt. C++ erlaubt einem hier halt genauer auszudrücken was man will, was prinzipiell gut ist, das ganze aber auch schwieriger macht. D.h. C++ hat zwar objektiv die Möglichkeit es besser auszudrücken, aber alle die C++ verwenden müssen diese Möglichkeit auch kennen und dieselbe Auffassung über diese Möglichkeit haben. Dazu braucht man aber halt mehr Erfahrung als in Java, wo es eben nur eine Möglichkeit gibt, die zwar nicht so perfekt passt aber im Endeffekt dasselbe erreicht.

Das kann man vielleicht allgemein so sagen (*duck*):
Ein guter C++Programmierer kann in C++ wahrscheinlich 'bessere' (im Sinn von ausdrucksstärkere Formulierungen und allem was daraus in Sachen Wartbarkeit etc. erwächst) Programme schreiben als ein guter Java-Programmierer, weil ihm die Sprache mehr Möglichkeiten dafür lässt. Dafür kann ein schlechter C++Programmierer sicherlich auch schlechtere Programme als ein schlechter Java-Programmierer schreiben.
(PS. dabei red ich zuerst mal ausschließlich von den Sprachen an sich, nicht von fertigen Bibliotheken, Werkzeugen etc.)

kartoffelsack schrieb:

Ein guter C++Programmierer kann in C++ wahrscheinlich 'bessere' (im Sinn von ausdrucksstärkere Formulierungen und allem was daraus in Sachen Wartbarkeit etc. erwächst) Programme schreiben als ein guter Java-Programmierer, weil ihm die Sprache mehr Möglichkeiten dafür lässt.

Nein. Java ist viel einfacher und deshalb auch besser wartbar.

Shade Of Mine

kartoffelsack schrieb:

Das sqrt-Beispiel ist ein gutes Beispiel dafür, dass es - nur weil es eine 'objektorientierte' Sprache ist - nicht immer sinnvoll ist, alles objektorientiert zu machen (bzw. dass Java eben doch keine 100% oo-Sprache ist, sonst ginge ja 1.1.sqrt() )

Math.add()
ist _nicht_ objekt orientiert.

ich sehe hier keine objekte.

Dazu braucht man aber halt mehr Erfahrung als in Java, wo es eben nur eine Möglichkeit gibt, die zwar nicht so perfekt passt aber im Endeffekt dasselbe erreicht.

es gibt genug andere moeglichkeiten. zB eben 2.sqrt() waere eine davon

aber worum es geht ist, dass Math.add() kein bisschen objekt orientiert ist. Es ist nichts anderes als ein kompliziertes int add(int, int);

und fuehrt dazu dass klassen in java oft nichts anderes sind als namespace ersatz.

ob das jetzt gut ist oder nicht, weill ich mal nicht bewerten. es geht eher mehr darum dass die leute verstehen muessen dass eine klasse erstmal rein garnichts mit OOP zu tun hat. Und Java ist kein bisschen 100% OOP oder so... ich habe schon genug C programme in Java gesehen: klappt super, da Java C so aehnlich ist kann man da viel 1 zu 1 uebernehmen. Und nur weil es dann Foo.bar() heisst statt foo_bar() macht es das nicht OO