Espace de noms + fonctions versus méthodes statiques sur une classe

Disons que j'ai ou vais écrire un ensemble de fonctions connexes. Disons qu'ils sont liés aux mathématiques. Sur le plan organisationnel, dois-je:

1. Écrire ces fonctions et les mettre dans mon MyMathespace de noms et y faire référence viaMyMath::XYZ()
2. Créez une classe appelée MyMathet rendez ces méthodes statiques et reportez-vous de la même manièreMyMath::XYZ()

Pourquoi devrais-je choisir l'un plutôt que l'autre pour organiser mon logiciel?

Par défaut, utilisez les fonctions d'espaces de noms.

Les classes doivent créer des objets et non remplacer des espaces de noms.

En code orienté objet

Scott Meyers a écrit un article entier pour son livre Effective C ++ sur ce sujet, "Préférez les fonctions non-membres non-amis aux fonctions membres". J'ai trouvé une référence en ligne à ce principe dans un article de Herb Sutter:http://www.gotw.ca/gotw/084.htm

La chose importante à savoir est la suivante: En C ++, les fonctions du même espace de noms qu'une classe appartiennent à l'interface de cette classe (car ADL recherchera ces fonctions lors de la résolution des appels de fonction).

Les fonctions à espace de nom, sauf si elles sont déclarées «ami», n'ont pas accès aux internes de la classe, contrairement aux méthodes statiques.

Cela signifie, par exemple, que lors de la maintenance de votre classe, si vous devez modifier les internes de votre classe, vous devrez rechercher des effets secondaires dans toutes ses méthodes, y compris les effets statiques.

Extension I

Ajout de code à l'interface d'une classe.

En C #, vous pouvez ajouter des méthodes à une classe même si vous n'y avez pas accès. Mais en C ++, c'est impossible.

Mais, toujours en C ++, vous pouvez toujours ajouter une fonction d'espacement de noms, même à une classe que quelqu'un a écrite pour vous.

Voyez de l'autre côté, cela est important lors de la conception de votre code, car en plaçant vos fonctions dans un espace de noms, vous autoriserez vos utilisateurs à augmenter / compléter l'interface de la classe.

Extension II

Un effet secondaire du point précédent, il est impossible de déclarer des méthodes statiques dans plusieurs en-têtes. Chaque méthode doit être déclarée dans la même classe.

Pour les espaces de noms, les fonctions du même espace de noms peuvent être déclarées dans plusieurs en-têtes (la fonction d'échange presque standard en est le meilleur exemple).

Extension III

La fraîcheur de base d'un espace de noms est que dans certains codes, vous pouvez éviter de le mentionner, si vous utilisez le mot-clé "using":

#include <string>
#include <vector>

// Etc.
{
   using namespace std ;
   // Now, everything from std is accessible without qualification
   string s ; // Ok
   vector v ; // Ok
}

string ss ; // COMPILATION ERROR
vector vv ; // COMPILATION ERROR

Et vous pouvez même limiter la "pollution" à une seule classe:

#include <string>
#include <vector>

{
   using std::string ;
   string s ; // Ok
   vector v ; // COMPILATION ERROR
}

string ss ; // COMPILATION ERROR
vector vv ; // COMPILATION ERROR

Ce «modèle» est obligatoire pour la bonne utilisation de l'idiome d'échange presque standard.

Et cela est impossible à faire avec des méthodes statiques dans les classes.

Ainsi, les espaces de noms C ++ ont leur propre sémantique.

Mais cela va plus loin, car vous pouvez combiner des espaces de noms d'une manière similaire à l'héritage.

Par exemple, si vous avez un espace de noms A avec une fonction AAA, un espace de noms B avec une fonction BBB, vous pouvez déclarer un espace de noms C et amener AAA et BBB dans cet espace de noms avec le mot-clé using.

Conclusion

Les espaces de noms sont pour les espaces de noms. Les cours sont pour les cours.

C ++ a été conçu pour que chaque concept soit différent et soit utilisé différemment, dans différents cas, comme solution à différents problèmes.

N'utilisez pas de classes lorsque vous avez besoin d'espaces de noms.

Et dans votre cas, vous avez besoin d'espaces de noms.

Il y a beaucoup de gens qui ne seraient pas d'accord avec moi, mais voici comment je le vois:

Une classe est essentiellement une définition d'un certain type d'objet. Les méthodes statiques doivent définir des opérations intimement liées à cette définition d'objet.

Si vous allez simplement avoir un groupe de fonctions connexes non associées à un objet sous-jacent ou à la définition d'un type d'objet , alors je dirais aller avec un espace de noms uniquement. Juste pour moi, conceptuellement, c'est beaucoup plus sensé.

Par exemple, dans votre cas, demandez-vous: "Qu'est-ce qu'un MyMath?" Si MyMathne définit pas une sorte d'objet, alors je dirais: n'en faites pas une classe.

Mais comme je l'ai dit, je sais qu'il y a beaucoup de gens qui seraient (même avec véhémence) en désaccord avec moi à ce sujet (en particulier, les développeurs Java et C #).

• Si vous avez besoin de données statiques, utilisez des méthodes statiques.
• S'il s'agit de fonctions de modèle et que vous souhaitez pouvoir spécifier un ensemble de paramètres de modèle pour toutes les fonctions ensemble, utilisez des méthodes statiques dans une classe de modèle.

Sinon, utilisez des fonctions d'espaces de noms.

En réponse aux commentaires: oui, les méthodes statiques et les données statiques ont tendance à être sur-utilisées. C'est pourquoi je n'ai proposé que deux scénarios connexes où je pense qu'ils peuvent être utiles. Dans l'exemple spécifique de l'OP (un ensemble de routines mathématiques), s'il voulait pouvoir spécifier des paramètres - par exemple, un type de données de base et une précision de sortie - qui seraient appliqués à toutes les routines, il pourrait faire quelque chose comme:

template<typename T, int decimalPlaces>
class MyMath
{
   // routines operate on datatype T, preserving at least decimalPlaces precision
};

// math routines for manufacturing calculations
typedef MyMath<double, 4> CAMMath;
// math routines for on-screen displays
typedef MyMath<float, 2> PreviewMath;

Si vous n'avez pas besoin que, puis par tous les moyens d' utiliser un espace de noms.

Vous devez utiliser un espace de noms, car un espace de noms présente de nombreux avantages par rapport à une classe:

• Vous n'avez pas à tout définir dans le même en-tête
• Vous n'avez pas besoin d'exposer toute votre implémentation dans l'en-tête
• Vous ne pouvez pas usingun membre de la classe; vous pouvez usingun membre d'espace de noms
• Vous ne pouvez pas using class, mais ce using namespacen'est pas souvent une bonne idée
• L'utilisation d'une classe implique qu'il y a un objet à créer alors qu'il n'y en a vraiment pas

Les membres statiques sont, à mon avis, très très surutilisés. Ils ne sont pas une réelle nécessité dans la plupart des cas. Les fonctions de membres statiques sont probablement mieux loties que les fonctions de portée de fichier, et les membres de données statiques ne sont que des objets globaux avec une meilleure réputation non méritée.

Je préférerais les espaces de noms, de cette façon, vous pouvez avoir des données privées dans un espace de noms anonyme dans le fichier d'implémentation (il n'a donc pas du tout à apparaître dans l'en-tête par opposition aux privatemembres). Un autre avantage est que, par usingvotre espace de noms, les clients des méthodes peuvent refuser de spécifierMyMath::

Une raison de plus pour utiliser la classe - Option pour utiliser des spécificateurs d'accès. Vous pouvez ensuite éventuellement diviser votre méthode statique publique en méthodes privées plus petites. La méthode publique peut appeler plusieurs méthodes privées.

L'espace de noms et la méthode de classe ont leurs utilisations. L'espace de noms peut être réparti sur plusieurs fichiers, mais c'est une faiblesse si vous devez appliquer tout le code associé pour aller dans un seul fichier. Comme mentionné ci-dessus, la classe vous permet également de créer des membres statiques privés dans la classe. Vous pouvez l'avoir dans l'espace de noms anonyme du fichier d'implémentation, mais il est toujours plus étendu que de les avoir dans la classe.