sollte man Methoden, die nicht auf Membervariablen operieren, grundsätzlich als "static" deklarieren?
Welche Vor- und Nachteile gibt es?

Gruß, Thomas

ich meine, man sollte überlegen, ob sie überhaupt Memberfunktionen sein müssen.
Wenn sie wirklich derart intensiv mit einer Klasse verheiratet sind (und ich glaube, das sind sie deutlich seltener, als man das spontan meint), ist die Frage, was man mit dieser Funktion "später einmal" machen will: virtual und static geht halt nicht.

Gruß,

Simon2.

ich habe eine Klasse, die recht umfangreiche Objekte erzeugt. An einer Stelle im Programm brauche ich eine Teil-Funktionalität der Klasse, bei der ich nicht erst ein ganzes Objekt erzeugen will, um auf die Funktion zugreifen zu können.

Um mal ein Beispiel zu nennen:

class Zeichenobjekt
{
public:
  static bool isRund(objektID id);
};

und im Programm:

bool b = Zeichenobjekt::isRund(Zeichenobjekt::ID_Kreis);

an einer Stelle, wo ich ein Objekt "Kreis" einfach nicht habe bzw. nicht brauche.

Gruß, Thomas

bool isRund(objektID id);

bool b = isRund(Zeichenobjekt::ID_Kreis);

?

Die Einordnung in einem Zeichenobjekt (gerade einer "is-Funktion") suggeriert doch, dass man eine Eigenschaft des umschließenden Objekts abfragen will...
Da Du statische Funktionen ja auch mit "." aufrufen kannst, wir spätestens das verwirrend:

Quadrat z; // Annahme: Quadrat erbt von Zeichenobjekt
if(z.isRund(Zeichenobjekt::ID_Kreis)) {
 // ... ??

ODER (wenn ich es mir recht überlege): Es schreit eigentlich eher nach einer virtuellen Funktion, denn diese "ID-Typisierung" ist einfach schrecklich/aufwendig/fehleranfällig/...

Gruß,

Simon2.

ja aber wo packe ich diese "freie" Funktion am besten hin? Ich finde, sie ist im Kontext dieser Klasse ganz gut aufgehoben, vor allem auch da sie einen innerhalb der Klasse definierten Argumenttypen verwendet.
Ich teile Deine Bedenken, dass suggeriert werden könnte, man frage eine Objekteigenschaft ab. Aber eine "freieFunktionen.cpp" mit Funktionen, die aus den verschiedendsten Kontexten stammen, in mein Projekt einzubinden, finde ich auch nicht besonders attraktiv.

Gruß, Thomas

Hi,

ja aber wo packe ich diese "freie" Funktion am besten hin? ...

In denselben namespace wie Deine Zeichenobjekt-IDs, denn eigentlich beschreiben sie keine Eigenschaft Deiner Zeichenobjekte, sondern der ZeichenObejktIDs.

Also entweder:

namespace Th0m4s_Zeichenwelt {
   enum ZeichenObjektID {
         Kreis,
         Quadrad
   };
   bool isRund(ZeichenObjektID);

   class ZeichenObjekt {
      ZeichenObjektID id;
   };
}

oder

class ZeichenObjekt {
   public:
      virtual bool isRund() const = 0;
   };

   class Kreis : public ZeichenObjekt {
   public:
      virtual bool isRund() const { return true; }
   };

   class Quadrat : public ZeichenObjekt {
   public:
      virtual bool isRund() const { return false; }
   };

(wobei es auch gute Gründe gegen so eine Spezialisierung in diesem speziellen Fall gibt (habe ich hier im Forum mal gelesen, bekomme ich aber nicht mehr voreinander - ich habe es hier aber einfach mal als Weg aufgezeigt)

Gruß,

Simon2.

Hi,

ja aber wo packe ich diese "freie" Funktion am besten hin? Ich finde, sie ist im Kontext dieser Klasse ganz gut aufgehoben, vor allem auch da sie einen innerhalb der Klasse definierten Argumenttypen verwendet.
Ich teile Deine Bedenken, dass suggeriert werden könnte, man frage eine Objekteigenschaft ab. Aber eine "freieFunktionen.cpp" mit Funktionen, die aus den verschiedendsten Kontexten stammen, in mein Projekt einzubinden, finde ich auch nicht besonders attraktiv.

Gruß, Thomas

Schaff doch eine Klasse "Utility", mach ein Singleton daraus un dbring die Funktionen dort unter.
Damit erhältst Du einen aussagekräftigen Namensraum (nämlich den Klassennamen); musst die Funktionen nicht durch ein evtl fehlleitendes "static" kennzeichnen und kannst sogar Polymorphie nutzen.

Ausserdem werden freie Funktionen in der UML durch sog. "Klassenutilities" dargestellt; mit einer "class Utility" kann demnach wohl auch jeder etwas anfangen der ein wenig UML kennt.

Grüsse

*this

Schaff doch eine Klasse "Utility", mach ein Singleton daraus un dbring die Funktionen dort unter.
Damit erhältst Du einen aussagekräftigen Namensraum (nämlich den Klassennamen); musst die Funktionen nicht durch ein evtl fehlleitendes "static" kennzeichnen und kannst sogar Polymorphie nutzen.

So einen Quatsch macht man nur in Sprachen, die keine freien Funktionen kennt. Eine Klasse deklariere ich, wenn ich eine Klasse benötige. Was soll denn die Klasse "Utility" tun? Sie ist nur ein Namensraum. Warum verwendest Du dann nicht "namespace"? Als Klasse hat sie keine Aufgabe und damit keine Existenzberechtigung.

Prinzipiell finde ich die Idee, die Funktion als statisches Member der Klasse zu deklarieren sinnvoll, da sie thematisch eng mit der Klasse verknüpft ist. Allerdings stimme ich da mit Simon2 überein, daß die virtuelle Funktion die richtige Methode ist. Konstanten für Typ-IDs weisen in der Regel auf einen Designfehler hin.

Gast++ schrieb:

Schaff doch eine Klasse "Utility", mach ein Singleton daraus un dbring die Funktionen dort unter.
Damit erhältst Du einen aussagekräftigen Namensraum (nämlich den Klassennamen); musst die Funktionen nicht durch ein evtl fehlleitendes "static" kennzeichnen und kannst sogar Polymorphie nutzen.

So einen Quatsch macht man nur in Sprachen, die keine freien Funktionen kennt. Eine Klasse deklariere ich, wenn ich eine Klasse benötige. Was soll denn die Klasse "Utility" tun? Sie ist nur ein Namensraum. Warum verwendest Du dann nicht "namespace"? Als Klasse hat sie keine Aufgabe und damit keine Existenzberechtigung.

Prinzipiell finde ich die Idee, die Funktion als statisches Member der Klasse zu deklarieren sinnvoll, da sie thematisch eng mit der Klasse verknüpft ist. Allerdings stimme ich da mit Simon2 überein, daß die virtuelle Funktion die richtige Methode ist. Konstanten für Typ-IDs weisen in der Regel auf einen Designfehler hin.

zustimm

...
Prinzipiell finde ich die Idee, die Funktion als statisches Member der Klasse zu deklarieren sinnvoll, da sie thematisch eng mit der Klasse verknüpft ist. ...

WENN sie denn thematisch mit ihr verknüpft ist ... und in diesem Fall ist sie es nicht wirklich (sondern eher mit ObjektID). Ich empfinde statische Funktionen aber inzwischen zunehmend als unnötige Verwirrung - vA, wenn es sich gleich um einen ganze Zoo handelt (und gab's da nicht noch so'ne "protected-Sonderlocke" beim Erben einer static Function ?).

Gruß,

Simon2.

So einen Quatsch macht man nur in Sprachen, die keine freien Funktionen kennt.

(kennen)

Hast Du grade Stress auf der Arbeit?

Eine Klasse deklariere ich, wenn ich eine Klasse benötige. Was soll denn die Klasse "Utility" tun? Sie ist nur ein Namensraum. Warum verwendest Du dann nicht "namespace"? Als Klasse hat sie keine Aufgabe und damit keine Existenzberechtigung.

Also keine Klasse?
(Btw sie ermöglichte Polymorphie.)

Prinzipiell finde ich die Idee, die Funktion als statisches Member der Klasse zu deklarieren sinnvoll,

Aber die Member eben der Klasse die wir vermeiden machen wir dann statisch?

da sie thematisch eng mit der Klasse verknüpft ist.

Nur bezog sich die letzte Frage des OP auf Funktionen bei denen das eben nicht gilt. Aber egal!

...die virtuelle Funktion die richtige Methode ist.[...]Konstanten für Typ-IDs weisen in der Regel auf einen Designfehler hin.

In diesem konkreten Fall stimmt beides.

Das war aber nicht die Frage auf die ich mich bezog wie aus dem Zitat auch für Nicht-Polemiker eindeutig hervorgeht.

Reiss Dich mal etwas zusammen!

Grüsse

*this