Version imprimable
Hello,
Soit une fonction membre méritant un découpage.
Si les fonctions ainsi créées n'ont pas besoin de données membres de la classe, préférez-vous faire une fonction non membre non amie, ou une fonction membre statique ?
Je sais que la première est généralement conseillée, mais j'apprécie la seconde forme (même si elle m'ouvre des droits supplémentaires dont je n'ai pas usage), notamment quand je dois faire quelques schémas UML.
Soit la fonction a un sens à être externe à la classe, manipulation ultra haut niveau de données génériques, et je la mets non membre non amie afin qu'elle soit utilisable par d'autres.
Soit la fonction sera utilisée uniquement dans le cadre de cette classe, manipulation de données internes ou structures internes, et static private, ou membre private parce que personne en dehors de la classe n'en a utilité.
Bonjour,
Cela va dépendre de ce que représente ta class\struct.
La première forme est absolument pas envisageable de mon coté, c'est comme du gros C dégeux. La seule fois ou je me permets ça c'est d'avoir une fonction statique global à mon cpp.
Invisible des autres unités elle permets de factoriser le fonctionnement interne d'un "Module"\"class"\"struct" et de le cacher à 100% à l'utilisateur si tu fait une librairie dynamique ou statique. Mais c'est tout!
Pour une fonction utilisable par l'utilisateur, j'ai toujours choisi la seconde forme avec des fonctions statique de class car cela permet de les catégorisés! Et c'est important, ne serait-ce que pour la modularisation de ton code.
Elle permets de savoir que ta fonction:static int32 Printf(const widechar* MsgFmt, ...); est une fonctionnalité de la console et donc de la noté comme suit:
Elle permets également de pouvoir faire de la spécification par plateforme!Code:
2
3
4struct Console { static int32 Printf(const widechar* MsgFmt, ...); };
Exemple:
La console commun, qui fourni une "interface" ou service commun à différent système:
La console Windows, qui fourni une spécialisation pour la plateforme Windows:Code:
2
3
4struct CommonConsole { static int32 Printf(const widechar* MsgFmt, ...); };
La console de ton application est en fait un typedef de la console de plus bas niveau de hiérarchie:Code:
2
3
4struct WindowsConsole : public CommonConsole { static int32 Printf(const widechar* MsgFmt, ...); };
Ainsi tu utilises comme suit:Code:typedef WindowsConsole TheConsole;
Code:TheConsole::Printf("Ok!");
Lorsque tu ajoutes un nouveau système, tu n'as qu'a hérité de CommonConsole, comme par exemple une console Unix avec ces spécificités et ces propres types de base.
Ainsi donc un cpp "WindowsConsole.cpp" tu n'as cas définir ta fonction pour Windows uniquement.
L'utilisateur n'y vois que du feux, et sait que le printf est pour la console, tu pourrais très bien avoir un printf pour autre chose qu'une console après tout.
Scott Meyers promeut pourtant cet usage, estimant que cela renforce l'encapsulation (et sa démonstration est convaincante).Citation:
Envoyé par Astraya
Je t'invite à relire son article (fin de la page 1).
En fait, ma question portait sur ce cas. Mais j'ai omis de le préciser...Citation:
Envoyé par Astraya
Pour la catégorisation, il y a la possibilité de rajouter un namespace.Citation:
Envoyé par Astraya
Toutefois, j'ai l'impression que ce sujet est de nature religieuse.
Il y a un critère objectif (encapsulation), et d'autres plus subjectifs (lisibilité, documentation, raisonnement purement à base de classes pour ceux qui viennent de java ou C#.
Salut,
De manière générale, le respect de l'ISP devrait prévaloir dans ton choix sur ce thème. Du coup, par défaut, tu devrais choisir une fonction libre non amie.
Cela n'a que des avantages, ne serait-ce que parce que tu peux alors placer la fonction dans un fichier d'en-tête clairement séparé ;)Je ne vois pas pourquoi tu fais le parallèle entre des fonctions libres et du gros C dégeux!Citation:
Envoyé par Astraya
Nous ne sommes pas en java ou en C# avec les restrictions techniques que ces langages imposent: nous développons en C++, qui a le bon gout d'être véritablement un langage multi-paradigme.
Bien au contraire, le fait de devoir déclarer la fonction principale comme étant une fonction statique est une aberration (j'ai eu envie de dire une abomination) conceptuelle en java. Bien sur, il y a de bonnes raisons techniques à cette nécessité et elles portent deux noms : machine virtuelle et garbage collector :P
Mais, en C++, alors que l'on a la chance de pouvoir choisir le paradigme que l'on utilise de manière très modulaire, il serait aberrant de refuser de manière systématique l'utilisation de fonctions libres.
Car il arrive souvent que tu veuille disposer d'un service particulier qui ne s'avère être utile que dans certaines circonstances particulière.
Un exemple frappant de ce que je veux exprimer est la notion de matrice. A tord ou à raison, la première chose à laquelle on pense (en tant qu'informaticien) quand on parle de matrice, c'est à la représentation d'un tableau à deux dimensions. Et il se peut que, parfois, on en vienne à envisager la notion de matrice telle qu'elle nous est servie en mathématique. Avec, entre autres, le besoin d'en calculer le déterminant.
On pourrait donc faire une fonction membre de notre classe Matrice qui permettrait de calculer le déterminant, mais cela aurait pour résultat que notre notion de matrice fournit "l'indispensable et le superflu", car on n'a pas forcément besoin de pouvoir calculer le déterminant d'une matrice lorsque la notion de matrice se limite à la notion de "représentation d'un tableau à deux dimensions".
En créant une fonction libre pour calculer le déterminant, tu te mets en position, comme je l'ai dit, de déclarer cette fonction dans un autre fichier d'en-tête, et tu aurais dés lors Matrix.hpp qui fournit la notion "informaticienne" de matrice, et un fichier MatrixOperations.hpp (par exemple) qui exposeraient les opérations (de mathématique) matricielle "qui vont bien" pour un mathématicien ;)
Si la function global est dans un cpp je n'y vois pas d'inconvénient, je l'utilise souvent.Citation:
Scott Meyers promeut pourtant cet usage, estimant que cela renforce l'encapsulation (et sa démonstration est convaincante).
Je t'invite à relire son article (fin de la page 1).
Ce que je vois dans son exemple c'est que même sa fonction Widget* make( /* params */ ); est "Encapsuler" dans un namespace. Donc a partir de là je dirais que c'est plus une histoire de convention d'écriture vu que la fonction global est englober dans un namespace ou struct au final. Je pense que la décision final sera vraiment du cas par cas.
Et comme il dit tout à la finCitation:
there is a weakness to this design when templates enter the picture.
Le namespace ne te permettra pas d'overload de function si je dis vrai.Citation:
Pour la catégorisation, il y a la possibilité de rajouter un namespace.
Et les collisions de nom? Je le répète, dans un cpp no souci, dans un header vraiment pas...Citation:
Envoyé par koala01
Le fait d'avoir 2 headers ajoute aussi une complexité non négligeable sur la gestion de version.... ( Git à le même soucis avec ces systèmes de modules qui peut apporter des bonnes régressions )Citation:
Envoyé par koala01
Une matrice est un sens mathématique, un arrays est un sens "Autres".
Prenons par exemple matlab qui différencie les deux https://fr.mathworks.com/help/matlab/learn_matlab/matrices-and-arrays.html?requestedDomain=www.mathworks.com
Une matrix peut aussi être une spécialisation (Dans le sens héritages) avec des fonctions supplémentaires. Un array est une classe template<X,Y> Array et une matrix est template<> Matrix : public Array<4,4>De plus, le fait d'avoir la class Mvatrix avec c'est fonctions membres permets d'obtenir une "Documentation" sur ce qui est possible ou pas.
Mais encore une fois, j'ai plus l'impression que c'est une question religieuse que d'efficacité. Le multiparadigm permets beaucoup de chose comme tu le dis koala.
Je préfère la fonction libre non amie.
S'il y a besoin de cacher son existence, il suffit de la mettre dans un espace de noms anonymes.
Il faut dire que je n'aime pas trop les fonctions statiques. Je trouve que cela a trop souvent un arrière goût de maladresse -- il y a des cas où c'est pertinent mais aussi beaucoup de cas où elles pourraient soit être libres, soit membres statiques d'une tierce classe (quand il y a des attributs statiques en plus).
Le truc est que si tu n'as même pas besoin d'amitié dans le fonction libre, il me parait alors encore plus étrange de faire une fonction statique vu qu'il n'y a besoin d'aucun accès privilégié.
De surcharger oui, de masquer non.Citation:
Envoyé par Astraya
Pour faciliter la modélisation en UML.Citation:
Envoyé par Luc Hermitte
Mais je peux tricher, et dans le diagramme en faire une fonction statique avec un stéréotype { free }...
Pourquoi vouloir la faire apparaitre dans la classe dans ton UML, si elle n'est pas dedans?
L'uml ne supporte-t-il pas les fonctions libre?
Pour faire apparaître l'interface de la classe.Citation:
Envoyé par ternel
Non.Citation:
Envoyé par ternel
Et les espaces de noms, c'est fait pour les chiens :question:Citation:
Envoyé par Astraya
Si tu as des fonctionnalités qui sont corrélées d'une manière ou d'une autre, tu les places dans un espace de noms identique, et basta ;)
La gestion de versions concurrente a toujours été un problème. Mais ce n'est pas là que le bât blesse...Citation:
Le fait d'avoir 2 headers ajoute aussi une complexité non négligeable sur la gestion de version.... ( Git à le même soucis avec ces systèmes de modules qui peut apporter des bonnes régressions )
Là où le bât blesse, en terme de régression, c'est en termes de tests unitaire; pour que l'on puisse garantir que, quelle que soit la fonctionnalité envisagée, elle réagira effectivement de la manière qui est attendue.
Et de mon point de vue, il est toujours plus facile de s'y retrouver dans dix fichiers de 100 lignes que dans un seul fichier de 1000 ;)
Donc on en revient à le mettre dans un namespace/struct... Comme dis dans l'article de Scott Meyers :Citation:
Envoyé par koala01
Maintenant j'ai l'impression que le débat est stérile car le choix entre l'un ou l'autre dépendra principalement de l'objectif d'une telle fonction.Citation:
there is a weakness to this design when templates enter the picture.
L'avantage majeur de la statique est l'overwrite de fonction, l'auto-documentation, le regroupement, la simplicité et facilité de lecture, la gestion de version.
Pour la global dans un header, je vous laisse faire la liste je l'utilise que trop rarement, je vois uniquement le fait de pouvoir composer un namespace en le déclarant dans plusieurs headers différent, ce que je trouve dégueulasse et personnellement, car sans outils d'édition ( Visual Assist,...) la recherche peut vite devenir un cauchemar dans de très gros projet.
Dans une équipe de plusieurs dizaines de développeurs certaines choses prévale sur le simple fait d'augmenter l'encapsulation au prix de header/namespace supplémentaires
a- Oui entièrement d'accord. Les objectifs vont beaucoup influer.Citation:
Envoyé par Astraya
b-
- overwrite> je ne vois pas le masquage comme un avantage. Plus comme un truc dégueulasse. On peut faire pareil avec des espaces de noms. Maintenant, si c'est pour lier des classes instanciables à des fonctions qui ne prennent aucun objet de ces classes, mais qui peuvent avoir un rapport lointain. Ok pour le statique, cela ne va pas me choquer. Mais je préfère make_A(), ou make<A>(), à A::make(), quand je ne suis pas dans un cas de fonction générique -- mais pour ce cas précis, nous allons maintenant avoir le C++17.
- auto-documentation> ? Je ne vois pas en quoi std::abs n'est pas autodocumenté. Si c'est pour la doc générée, il me semble que certains outils ont des tags dédiés
- regroupement> C'est là pour moi un faiblesse du statique, car c'est un regroupement fort, fermé, et non évolutif
- simplicité et facilité de lecture> Juste une habitude pour ceux qui n'ont pas d'espaces de noms dans les langages d'où ils viennent.
- gestion de version> Cf les espaces de noms inline depuis le C++11
c- La recherche de ? Des définitions des fonctions liées? Avec vim et ctags, je n'ai pas de grande difficulté pour retrouver une fonction. Même pas besoin d'un visual assist. Après, n'étant pas sûr du point exact de ta critique, si j'ai une fonction libre f() qui doit appartenir à l'interface généralisée de la classe Toto, avec un espace de noms, f() sera déclarée dans toto.hpp et définie dans toto.cpp. Exactement comme si elle avait été statique.