Discussion :

[oodini]

Hello,

Est-ce mal vu de faire des fonctions globales ?

Doit-on tout encapsuler ces fonctions dans des classes pour faire "plus propre" ?

[r0d]

Je pense que sur ce sujet, les avis vont diverger.

Mon avis personnel c'est que je n'aime pas les fonction globales. Je dirais plutôt "flottantes". Pourquoi?

- Généralement, ça cache une erreur de conception. Je dis bien généralement, car il y a des cas où l'on ne peut pas faire autrement. Mais en général, l'idée de la poo est que chaque objet possède ce qu'il faut pour les manipuler, ou bien, lorsque c'est compliqué ou que la structure du programme le demande, on passe par un proxy, un médiateur, etc.

- Dans le cas où on ne peut vraiment pas encapsuler la fonctionnalité, je pense qu'il est tout de même une bonne chose de "classer" proprement cette fonctionnalité. Donc mettre ces fonctions flottantes dans un namespace ou en statique dans une classe (ce qui, pour moi, revient au même, mais là encore il peut y avoir débat). C'est plus dans un soucis de maintenabilité que de "beauté du code".

My cent

[Jean-Marc.Bourguet]

Dans quelle classe encapsuler quelque chose comme "sin"? Tout ce qu'on pourra faire sera artificiel, alors autant s'en passer.

[oodini]

Hmmm... Après réflexion, je crois que je vais pouvoir les encapsuler de manière statique dans des objets que je dois créer bien plus tard, mais qui sémantiquement correspondent.

Merci de ton avis.

[nikko34]

tu peux les mettre dans un namespace.

Mais je ne vois pas de raison, comme tu le décris, de les mettre dans une classe.

[r0d]

Dans quelle classe encapsuler quelque chose comme "sin"? Tout ce qu'on pourra faire sera artificiel, alors autant s'en passer.

Une classe NomProjet_Math, par exemple. L'expérience m'a montré que lorsqu'on commence à implémenté une fonction de ce type, il en arrive rapidement d'autres. Donc autant créer un "espace sémantique" (classe, namespace, ...) dès le début.

edit: sans compter que de tout encapsuler évite les erreurs bêtes de redéclaration de variables (qui peut deveniir problématique dans certains cas, comme par exemple lorsqu'on utililse plsin de libs).

[screetch]

c'est utile pour eviter les conflits de nommage, mais une fonction "globale" reste une fonction "globale" que l'on mette des termes de POO devant ou pas.
J'ai vu des projets ou du coup ils avaient une classe

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class Utils
{
  static void sinus(float angle);
  static void print(const char *str);
  static bool isDebuggerAttached();
  static Coffe doCoffee(bool sugar, bool milk);
};

je vois pas l'interet. ah si, c'est de l'objet...

[Jean-Marc.Bourguet]

Une classe NomProjet_Math, par exemple. L'expérience m'a montré que lorsqu'on commence à implémenté une fonction de ce type, il en arrive rapidement d'autres. Donc autant créer un "espace sémantique" (classe, namespace, ...) dès le début.

Il est question de classes, pas de namespace (j'ai rien contre les namespaces; il y a des cas ou introduire des classes avec que des membres statiques est utile -- on peut par exemple les faire template ou les passer en parametre template -- mais introduire systematiquement des classes ne me semble pas necessaire).

[capitN.flam]

Personellement, je pense que dans le cas de la fonction sin: un namespace "math" car comme le dit r0d en général quand on commence avec ce genre de fonction on arrive vite à en avoir plein et puis on va certainement rajouter des types: complex, vector3, mat4, ... donc un namespace est certainement la meilleure solution pour ce cas ci.

Mais cela ne peut pas être une règle générale, il y aura toujours des cas ou une classe utilitaire sera mieux ou même une fonction globale.

[Obsidian]

Hello,

Est-ce mal vu de faire des fonctions globales ?

Doit-on tout encapsuler ces fonctions dans des classes pour faire "plus propre" ?

Presque tout est dit au-dessus. J'ajouterais donc que cela dépend beaucoup de langage. Java, par exemple, ne te laissera pas le choix. En revanche, surtout en C++, je ne vois pas pourquoi il faudrait obligatoirement définir une classe si celle-ci ne contient que des fonctions membres statiques et qu'il n'y a rien à instancier. À dire vrai, c'est de la transformation de fonction en méthode et, à mon avis, elle n'a pas lieu d'être.

En plus, il y aura des moments où tu n'auras pas le choix non plus, typiquement lorsque tu redéfiniras des opérateurs pour faire interagir tes objets avec des types natifs ou d'autres classes d'objets déja existantes.

Donc, c'est le bon sens qui s'applique ici : si ta fonction est principalement destinée à modifier les membres d'un objet, alors elle doit (si possible) faire partie de l'objet lui-même et donc être une de ses méthodes.

Dans le cas contraire, tu peux définir une fonction indépendante et d'intérêt générale, si c'en est bien une. Tu peux utiliser les namespaces si tu crains une collision, mais attention : si c'est le cas, c'est peut-être dû au fait qu'elle devrait en fait être une méthode. Mais si c'est pour séparer des fonctions similaires dans des bibliothèques différentes, c'est parfaitement indiqué, et c'est même valable pour les classes.