statische Klasse hässlich! (?)

[Badestrand]

DStefan schrieb:

Es kommt doch wohl darauf an, was damit erreicht werden soll, und die Frage ist, ob man es eleganter (angemessener) formulieren könnte. Beides kann man aus dem Beispiel doch gar nicht ersehen.

Naja, bei einer komplett statischen Klasse würde sich imo doch ein Namespace geradezu aufdrängen

[warum?]

anmerker3 schrieb:

DStefan schrieb:

Qt finde ich wirklich gelungen.

Ja. Vor allem der Präprozessor.

Kann mir hier mal wer erlären, was an dem jetzt soooo verwerflich ist, dass er immer als DER Kritikpunkt an Qt angeführt wird?
Und bitte nicht "man braucht ein extra Tool dafür", das zählt in meinen Augen nicht wirklich, denn das wird ebenso wie uic und rcc mitgeliefert, ist also vorhanden und kann über den PATH (in dem auch die anderen Qt-Tools liegen) gefuden werden.

Es werden auch keine Dateien verändert, auch komplexe Strukturen, wie sie wohl bei dem Standard-C++-Präprozessor möglich sind, werden nicht entstehen, also auch keine (erhebliche) Performancebremse.

[DStefan]

Badestrand schrieb:

DStefan schrieb:

Es kommt doch wohl darauf an, was damit erreicht werden soll, und die Frage ist, ob man es eleganter (angemessener) formulieren könnte. Beides kann man aus dem Beispiel doch gar nicht ersehen.

Naja, bei einer komplett statischen Klasse würde sich imo doch ein Namespace geradezu aufdrängen

Es sei denn, die Klasse hätte Variablen, was nach der gezeigten Dokumentation der Fall zu sein scheint. Außerdem kann man von Klassen ableiten. Undsoweiter.

Ich finde, man kann hier wirklich nicht entscheiden, ob das Design hässlich ist. Es ohne Weiteres als hässlich hinzustellen finde ich (sagen wir mal) übereilt.

Stefan.

[Badestrand]

DStefan schrieb:

Es sei denn, die Klasse hätte Variablen, was nach der gezeigten Dokumentation der Fall zu sein scheint.

Hm, aber dann wohl nur statische, oder? Die lassen sich ja auch bei der Implementation des Namespaces unterbringen.

DStefan schrieb:

Außerdem kann man von Klassen ableiten.

Das stelle ich mir irgendwie komisch vor. Soll jetzt QToolTip von irgendwas erben oder soll von QToolTip geerbt werden? So wie QToolTip für mich aussieht, macht eine Instanz der Klasse nicht viel Sinn. Kann aber auch sein, dass ich da was übersehe(?).

[DStefan]

warum? schrieb:

anmerker3 schrieb:

DStefan schrieb:

Qt finde ich wirklich gelungen.

Ja. Vor allem der Präprozessor.

Kann mir hier mal wer erlären, was an dem jetzt soooo verwerflich ist, dass er immer als DER Kritikpunkt an Qt angeführt wird?
Und bitte nicht "man braucht ein extra Tool dafür", das zählt in meinen Augen nicht wirklich, denn das wird ebenso wie uic und rcc mitgeliefert, ist also vorhanden und kann über den PATH (in dem auch die anderen Qt-Tools liegen) gefuden werden.

Es werden auch keine Dateien verändert, auch komplexe Strukturen, wie sie wohl bei dem Standard-C++-Präprozessor möglich sind, werden nicht entstehen, also auch keine (erhebliche) Performancebremse.

Der Qt-Präprozessor ist nicht Standard. Das genügt mir als Kritikpunkt. Das führt für mich allerdings nicht so weit, dass ich Qt nicht einsetzen möchte. Vor allem dann, wenn ich portable GUIs erstellen möchte, ist Qt für mich eine gute Alternative.

Grundsätzlich aber wünsche ich mir Libraries, die mit Standardmitteln auskommen.

Stefan.

[DStefan]

Badestrand schrieb:

DStefan schrieb:

Es sei denn, die Klasse hätte Variablen, was nach der gezeigten Dokumentation der Fall zu sein scheint.

Hm, aber dann wohl nur statische, oder? Die lassen sich ja auch bei der Implementation des Namespaces unterbringen.

DStefan schrieb:

Außerdem kann man von Klassen ableiten.

Das stelle ich mir irgendwie komisch vor. Soll jetzt QToolTip von irgendwas erben oder soll von QToolTip geerbt werden? So wie QToolTip für mich aussieht, macht eine Instanz der Klasse nicht viel Sinn. Kann aber auch sein, dass ich da was übersehe(?).

Naja, die Behauptung war ja, das Design sei hässlich. Und bitte: Ich wollte nicht mehr sagen, als dass man es anhand der gezeigten Dokumentation nicht entscheiden kann. Wir müssen einfach zu viel raten.

Angenommen, es gäbe Variablen, dann erscheint mir die Implementierung als Klasse "natürlicher" als eine Implementierung per Namespace mit globalen Variablen. Findest du nicht?

Man könnte von der Klasse ableiten. Ich behaupte nicht, dass es nützlich wäre, denn ich verwende diese Klasse ja nicht. Aber vielleicht fanden die Designer es nützlich und vielleicht hatten sie Recht. Nochmal: Man weiß es nicht! Und man hat meiner Meinung nach keine Grundlage, von einem hässlichen Design zu sprechen.

Stefan.

[cute girl]

DStefan schrieb:

Badestrand schrieb:

DStefan schrieb:

Es sei denn, die Klasse hätte Variablen, was nach der gezeigten Dokumentation der Fall zu sein scheint.

Hm, aber dann wohl nur statische, oder? Die lassen sich ja auch bei der Implementation des Namespaces unterbringen.

DStefan schrieb:

Außerdem kann man von Klassen ableiten.

Das stelle ich mir irgendwie komisch vor. Soll jetzt QToolTip von irgendwas erben oder soll von QToolTip geerbt werden? So wie QToolTip für mich aussieht, macht eine Instanz der Klasse nicht viel Sinn. Kann aber auch sein, dass ich da was übersehe(?).

Naja, die Behauptung war ja, das Design sei hässlich. Und bitte: Ich wollte nicht mehr sagen, als dass man es anhand der gezeigten Dokumentation nicht entscheiden kann. Wir müssen einfach zu viel raten.

Angenommen, es gäbe Variablen, dann erscheint mir die Implementierung als Klasse "natürlicher" als eine Implementierung per Namespace mit globalen Variablen. Findest du nicht?

Man könnte von der Klasse ableiten. Ich behaupte nicht, dass es nützlich wäre, denn ich verwende diese Klasse ja nicht. Aber vielleicht fanden die Designer es nützlich und vielleicht hatten sie Recht. Nochmal: Man weiß es nicht! Und man hat meiner Meinung nach keine Grundlage, von einem hässlichen Design zu sprechen.

Stefan.

a) Wenn die Klasse Variablen hätte, stünde das auch in der Doku. (siehe andere Qt Klassen)
b) Ist gibt nicht den geringsten Grund - nicht den allerkleinsten Nutzen der bei der Instantiierung von QToolTip entsteht
c) Dementsprechend unsinnig ist Polymorphie wie auch immer sie geartet sein soll.

Im übrigens habe ich Qt sehr gerne und arbeite fast ausschließlich damit wenn ich GUIs erstelle. Dennoch fallen solche Schnitzer immer wieder auf. QPoint hat zum Beispiel Getter,Setter und Referenzen. Die Tastache, dass auch dieses Framework mit Wasser kocht und die Fähigkeiten dieser Klasse legen den Schluss nahe dass das Design auch an dieser Stelle etwas stirnrunzelungswürdig ist. Oder nicht?

[aber]

wieso ist ein namespace für sowas besser als eine Klasse mit statischen Methoden? Gibts da nen Grund oder ist das so, weils immer so gesagt wird? Irgendwie seh ich da keinen großen unterschied

[aber doch]

aber schrieb:

wieso ist ein namespace für sowas besser als eine Klasse mit statischen Methoden? Gibts da nen Grund oder ist das so, weils immer so gesagt wird? Irgendwie seh ich da keinen großen unterschied

Wir sind hier nicht bei Java wo jeder Unsinn zwanhaft in eine Klasse zu stopfen ist - obwohl es keinen Sinn macht! Für sowas gibt es globale Funktionen und in diesem Fall bietet sich optional ein namespace an.

[static-er]

und wofür sind dann statische Funktionen da?

[aber]

aber doch schrieb:

aber schrieb:

wieso ist ein namespace für sowas besser als eine Klasse mit statischen Methoden? Gibts da nen Grund oder ist das so, weils immer so gesagt wird? Irgendwie seh ich da keinen großen unterschied

Wir sind hier nicht bei Java wo jeder Unsinn zwanhaft in eine Klasse zu stopfen ist - obwohl es keinen Sinn macht! Für sowas gibt es globale Funktionen und in diesem Fall bietet sich optional ein namespace an.

Also ist der einzige Grund, dass man es nicht so machen will wie in Java oder gibts noch nen richtigen?

[Stiller Teilhaber]

static-er schrieb:

und wofür sind dann statische Funktionen da?

Die sind dafür gedacht, wenn eine Funktion eindeutig mit einer Klasse verbunden ist, aber keine Instanz braucht um zu laufen. Um bei Qt zu bleiben, gibt es z.B. zu QFileDialog statische Methoden, um auf unkomplizierte Weise z.B. einen Filedialog zum Öffnen mehrerer Dateien zu bekommen. Ein QFileDialog-Objekt kann man trotzdem selber instanziieren und konfigurieren, wenn man was "spezielles" braucht.

[unskilled]

aber schrieb:

aber doch schrieb:

aber schrieb:

wieso ist ein namespace für sowas besser als eine Klasse mit statischen Methoden? Gibts da nen Grund oder ist das so, weils immer so gesagt wird? Irgendwie seh ich da keinen großen unterschied

Wir sind hier nicht bei Java wo jeder Unsinn zwanhaft in eine Klasse zu stopfen ist - obwohl es keinen Sinn macht! Für sowas gibt es globale Funktionen und in diesem Fall bietet sich optional ein namespace an.

Also ist der einzige Grund, dass man es nicht so machen will wie in Java oder gibts noch nen richtigen?

nein - der grund ist, dass es keinen sinn machen würde...
wenn ich keine klasse brauche, nehm ich keine klasse - sonst muss der anwender wieder viel mehr doku lesen, weil vll gibts ja doch irgend nen grund, warum es ne klasse ist, den man nur nicht gut dokumentiert hat oder wie auch immer...

bb

[Badestrand]

aber schrieb:

also ist der einzige Grund, dass man es nicht so machen will wie in Java oder gibts noch nen richtigen?

Nein, mit Java hat das nichts zu tun. Wenn man eine Klasse entwickelt, sollte es für den Nutzer so wenig Möglichkeiten zum falsch-machen geben wie nur mögich. In den allermeisten Fällen sind Klassen dafür da, um Instanzen von ihnen erstellen zu können (oder sie abstrakter referenzieren zu können, im Fall von Basisklassen). Und Namensräume werden genutzt, um Funktionalitäten zu gruppieren. Die QToolTip-Klasse gruppiert mit einer Klasse, von der man keine Instanzen erstellen kann/soll. Das ist unintuitiv und deshalb verwirrend. Und Verwirrung will wohl keiner

[DStefan]

cute girl schrieb:

a) Wenn die Klasse Variablen hätte, stünde das auch in der Doku. (siehe andere Qt Klassen)
b) Ist gibt nicht den geringsten Grund - nicht den allerkleinsten Nutzen der bei der Instantiierung von QToolTip entsteht
c) Dementsprechend unsinnig ist Polymorphie wie auch immer sie geartet sein soll.

Im übrigens habe ich Qt sehr gerne und arbeite fast ausschließlich damit wenn ich GUIs erstelle. Dennoch fallen solche Schnitzer immer wieder auf. QPoint hat zum Beispiel Getter,Setter und Referenzen. Die Tastache, dass auch dieses Framework mit Wasser kocht und die Fähigkeiten dieser Klasse legen den Schluss nahe dass das Design auch an dieser Stelle etwas stirnrunzelungswürdig ist. Oder nicht?

zu a) Das ist stimmt nicht. Zumindest hab ich in der Doku nirgendwo Dokumentation privater Variablen gesehen.

zu b) Da hast du Recht.

zu c) Ich rede nicht von Polymorphie sondern von Erben. Polymorphie ist nur ein Effekt des Erbens, ein anderer ist schlicht, Ist-Ein-Beziehungen zu modellieren bzw. auszunutzen.

Deine Kritik an QPoint verstehe ich nicht. Vielleicht kenne ich mich hierzu nicht gut genug mit Qt aus? Aber das ist doch ganz egal, du hattest behauptet, die ToolTip-Klasse sei hässlich, nicht QPoint.

"stirnrunzelungswürdig" finde ich ein klasse Adjektiv

aber schrieb:

wieso ist ein namespace für sowas besser als eine Klasse mit statischen Methoden? Gibts da nen Grund oder ist das so, weils immer so gesagt wird? Irgendwie seh ich da keinen großen unterschied

Es gibt tatsächlich kaum einen Unterschied zwischen einer Klasse mit ausschließlich static Methoden (falls diese alle public sind) und globalen Funktionen in einem Namespace. Beide Vorgehensweisen "bündeln" Funktionen unter einem Namen und vermeiden so Namenskollisionen. In C++ ist es einfach guter Stil, den globalen Namespace nicht mit Bezeichnern zu fluten.

In diesem letzten Punkt finde ich übrigens Qt wirklich hässlich: Die Lib legt alle Bezeichner in den globalen Namespace, was vermutlich historische Gründe hat.

Man sollte dann einen Namespaces mit globalen Funktionen bevorzugen, wenn keine Klassen-Eingenschaften verwendet werden, wenn man also beispielsweise keine (static) Variablen hat und es nicht sinnvoll ist, erben zu können.

Trotzdem: Der Unterschied ist so gering, dass ich weder die eine noch die anderere Wahl "stirnrunzelungswürdig" finde

Stefan.

[rosa radl0r]

Bevor das hier jetzt in wilde Spekulationen ausartet, hier der Header von ToolTip:

#ifndef QTOOLTIP_H
#define QTOOLTIP_H

#include <QtGui/qwidget.h>

QT_BEGIN_HEADER

QT_BEGIN_NAMESPACE

QT_MODULE(Gui)

#ifndef QT_NO_TOOLTIP

class Q_GUI_EXPORT QToolTip
{
    QToolTip();
public:
    static void showText(const QPoint &pos, const QString &text, QWidget *w = 0);
    static void showText(const QPoint &pos, const QString &text, QWidget *w, const QRect &rect);
    static inline void hideText() { showText(QPoint(), QString()); }

    static bool isVisible();
    static QString text();

    static QPalette palette();
    static void setPalette(const QPalette &);
    static QFont font();
    static void setFont(const QFont &);
#ifdef QT3_SUPPORT
    static inline QT3_SUPPORT void add(QWidget *w, const QString &s) { w->setToolTip(s); }
    static inline QT3_SUPPORT void add(QWidget *w, const QRect &, const QString &s)
    { w->setToolTip(s); }
    static inline QT3_SUPPORT void remove(QWidget *w) { w->setToolTip(QString()); }
#endif
};

#endif // QT_NO_TOOLTIP

QT_END_NAMESPACE

QT_END_HEADER

#endif // QTOOLTIP_H

Keine Member, einzig ein privater Konstruktor, der aber nirgendwo definiert ist.
Aber was ich nicht weiß, in wie weit man per Q_GUI_EXPORT einen namespace exportieren kann (da hab ich 0 Ahnung...). Vielleicht ist das der Grund (für alle Checker: Q_GUI_EXPORT ist definiert in <qt_src_root>/src/corelib/global/qglobal.h, in Version 4.5.1 ab Zeile 1121)

[aber]

Badestrand schrieb:

aber schrieb:

also ist der einzige Grund, dass man es nicht so machen will wie in Java oder gibts noch nen richtigen?

Nein, mit Java hat das nichts zu tun. Wenn man eine Klasse entwickelt, sollte es für den Nutzer so wenig Möglichkeiten zum falsch-machen geben wie nur mögich. In den allermeisten Fällen sind Klassen dafür da, um Instanzen von ihnen erstellen zu können (oder sie abstrakter referenzieren zu können, im Fall von Basisklassen). Und Namensräume werden genutzt, um Funktionalitäten zu gruppieren. Die QToolTip-Klasse gruppiert mit einer Klasse, von der man keine Instanzen erstellen kann/soll. Das ist unintuitiv und deshalb verwirrend. Und Verwirrung will wohl keiner

Dann ist aber doch der Namensraum std ein schlechtes Beispiel für die Verwendung von Namensräumen. Im prinzip gruppiert er nichts, sondern wirft alles von Algorithmen über Container bis Streams in einen Topf. Warum gibts da keine unterschiedlichen Namensräume?

[DStefan]

aber schrieb:

Badestrand schrieb:

aber schrieb:

also ist der einzige Grund, dass man es nicht so machen will wie in Java oder gibts noch nen richtigen?

Nein, mit Java hat das nichts zu tun. Wenn man eine Klasse entwickelt, sollte es für den Nutzer so wenig Möglichkeiten zum falsch-machen geben wie nur mögich. In den allermeisten Fällen sind Klassen dafür da, um Instanzen von ihnen erstellen zu können (oder sie abstrakter referenzieren zu können, im Fall von Basisklassen). Und Namensräume werden genutzt, um Funktionalitäten zu gruppieren. Die QToolTip-Klasse gruppiert mit einer Klasse, von der man keine Instanzen erstellen kann/soll. Das ist unintuitiv und deshalb verwirrend. Und Verwirrung will wohl keiner

Dann ist aber doch der Namensraum std ein schlechtes Beispiel für die Verwendung von Namensräumen. Im prinzip gruppiert er nichts, sondern wirft alles von Algorithmen über Container bis Streams in einen Topf. Warum gibts da keine unterschiedlichen Namensräume?

Ich verstehe Namespaces ein bischen anders. Ihr primäres Ziel ist es, die Eindeutigkeit von C++-Bezeichnern zu gewährleisten. Es soll also beispielsweise gewährleistet werden, dass man problemlos Librarys zwei verschiedener Hersteller (oder meinetwegen die STL und eine weitere Library) verwenden kann, ohne dass man Ärger mit Compiler oder Linker kriegt, weil beide Libs denselben Namen, etwa einer Klasse, verwenden.

Man kann natürlich hergehen und Namespaces zur Gruppierung verwenden, wie etwa boost es macht. Vielleicht ist das sogar eine gute Idee, aber wichtig oder gar entscheidend ist das nicht. Eine Gruppierung per Klasse, wie mit dem gezeigten Beispiel ist in meinen Augen völlig in Ordnung und eine akzeptable Design-Entscheidung.

Stefan.