Discussion :

[AnthoVégé]

Bonjour à tous

Je ne sais pas si cela est possible et si oui quel est le terme technique pour le désigner. Mes recherches dans les moteurs de recherches et FAQ ne m'ont pas permis de trouver la solution. Excusez-moi si ce sujet aurait éventuellement déjà été posté.

Je souhaite écrire une classe qui hérite d'une autre qui contient beaucoup de fonctions membres. Mon but étant d'ajouter quelques méthodes pour m'en faciliter l'usage, mais je souhaite aussi respecter mon protocole de codage. Dans ce dernier, J'écris mes méthodes en commençant par une majuscule, et j'utilise aussi les termes GLuint, GLfloat, ... au lieu de unsigned int, float, ... La classe dont j'aimerais hériter appartient à une librairie (la SFML) et les méthodes commence par des minuscules, ... bref, n'est pas compatible avec mon protocole. Bien que je ne change pas toutes les classes et méthodes de la librairie que j'utilise dans mon code, je ne voudrais pas écrire ma classe héritière autrement qu'à ma façon pour mieux me repérer dans mon projet.

Ma première idée consistait à appeler les fonctions de la classe d'origine dans des fonctions de l'héritière, mais d'une part, je devrais réécrire toutes les fonctions et je crains que cela pose un problème d'optimisation à l'avenir. Je me demande donc si il est possible de tout simplement redéfinir le nom des fonctions membres que l'héritière tient de la classe d'origine de sorte à respecter mon protocole de codage. Si oui, comment procède-t-on ? Sinon, quelle alternative ?

Merci d'avance de votre aide

[ternel]

Coté optimisation, ca n'est pas trop lourd.
Il y a la technique de la facade (c'est le nom d'un design pattern).

Cela dit, il est très très rare d'utiliser une majuscule pour nommer une fonction.
Pourquoi? parce qu'on appelle beaucoup plus de fonction qu'on utilise des types.
(Personnellement, je vais plus loin, je n'utilise pas de majuscule en première lettre. je préfère _type pour les typedef/using dans une classe, à la size_type)

Le mieux restant tout de même d'apprendre à utiliser la façon standard.
Pour te retrouver dans ton code, il y a une solution simple: utiliser un namespace qui te soit propre.

La bibliothèque standard est dans std::, boost dans boost::, la SFML dans sf::
Tu peux par exemple utiliser perso:: ou avg:: (initiales de ton pseudo)

Quand tu vois un std::vector, tu sais très bien ce que c'est. De même qu'un sf::Drawable.
Tu sens tout de suite que ce n'est pas ton code.


D'un point de vue plus général, j'ai l'impression que si tu as un problème à ce niveau, c'est parce que tu ne sépares pas assez les choses.

[AnthoVégé]

J'utilise un namespace, et même plusieurs car je conçois en même temps, au fil de mes besoins, une boîte à outils que j'utilise dans mon projet actuel.
Je ne connaissais pas la technique de la façade, et pourtant je l'utilisais

Concernant l'utilisation des majuscules pour les fonctions, c'est un truc enseigné par un prof à l'université, comme l'indication des types sur les variables (ui, f, ...). J'ai jeté un œil à la façon standard de faire, et si ne pas mettre de majuscules aux fonctions ne me gène pas, je n'en dirais pas autant de l'absence de ces indications de type qui m'ont bien aidé plusieurs fois.
En tout cas, si j'essaye de me rapprocher suffisamment du protocole standard, ça règle mon problème puisque je n'aurais pas à réécrire les fonctions provenant des classes SFML

[foetus]

Pour ce que tu veux faire, je pense à un truc très simple , ... mais ce n'est peut-être pas le bon truc à faire

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class A {
public:
 
    void ugly_name(/* .... */);
};
 
 
class B : public A {
 
// Facade
public:
 
    inline void my_name(/* .... */) { ugly_name(/* .... */) }
};

J'ai jeté un œil à la façon standard de faire, et si ne pas mettre de majuscules aux fonctions ne me gène pas, je n'en dirais pas autant de l'absence de ces indications de type qui m'ont bien aidé plusieurs fois.

Cela s'appelle la notation hongroise

Mais avec un langage objet cette notation a des limites parce que tu peux créer des types .
Par exemple, Logger, File_Manager, Dialog_Configuration ...

Il faut mieux avoir une rigueur comme celle ci

• tout en anglais
• les noms des méthodes: [verbe d'action fort]{_[extra]}_[type]{_[extra]}, avec {facultatif}

Par exemple: add_log, setup_manager, sort_first_10_numbers, set_get_mutex, ...

[AnthoVégé]

Merci pour le terme de notation hongroise. J'ai pu explorer les notations existantes, et j'aime bien celle-ci donc, mais aussi le CamelCase
Finalement, ça me plairait bien de continuer comme je fais et simplement indiquer mes conventions dans un fichier associé au projet pour mes futurs collaborateurs (c'est un projet open-source).

Je n'avais plus du tout pensé à l'emploi du inline pour optimiser mes méthodes de façade.
Je pensais à quelque chose. Je me disais que je pourrais hériter la classe d'origine à l'aide du mot clé protected de sorte à n'appeler dans ma classe héritière que les fonctions que je propose. L'idée étant que si j'ai besoin de fonctions qui n'ont pas encore de façade, je peux en ajouter bien entendu selon mes besoins. Est-ce que c'est une bonne idée ?

[ternel]

Honnêtement, je trouve qu'en C++, il n'y a pas besoin de la notation hongroise.
Normalement, les variables sont très locales.

D'ailleurs, je me demande bien qu'utiliser pour une template.

Il y a une possibilité intéressante toute fois, c'est que les noms des arguments de fonctions peuvent changer entre la déclaration et la définition.
Ainsi, dans la déclaration, comme le type est juste a coté, ce n'est pas la peine d'utiliser la notation hongroise.

Code :

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

1
2
3
4
5
6
7
8
//realises the swirl product of a and b.
template <typename T> T swirl(T const& a, T const& b)
 
//et plus loin
 
template <typename T> T swirl(T const& in_left, T const& in_right) {
    return (in_left-in_right) * (in_left+in_right);
}

a priori le swirl product n'existe pas vraiment... sauf dans un projet perso qui ne verra probablement jamais le public

[foetus]

Je me disais que je pourrais hériter la classe d'origine à l'aide du mot clé protected de sorte à n'appeler dans ma classe héritière que les fonctions que je propose. L'idée étant que si j'ai besoin de fonctions qui n'ont pas encore de façade, je peux en ajouter bien entendu selon mes besoins. Est-ce que c'est une bonne idée ?

J'y avais pensé , mais c'est plus une considération de développeur, à savoir si cela apporte un plus ou pas (même un plus psychologique )

Mais cela n'impactera pas l’utilisateur final

Il y a une possibilité intéressante toute fois, c'est que les noms des arguments de fonctions peuvent changer entre la déclaration et la définition.

On peut même les supprimer dans la déclaration:
Lorsqu'on a des add_log ou sort_array, les noms des paramètres est [un peu] redondant avec le nom de la méthode et son type.

Code :

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

1
2
3
4
5
6
7
8
9
10
//realises the swirl product.
template <typename T> T swirl(T const& /*left*/, T const& /*right*/);
 
void add_log(const Log&);
 
//et plus loin
 
template <typename T> T swirl(T const& in_left, T const& in_right) {
    return (in_left-in_right) * (in_left+in_right);
}

[AnthoVégé]

Cette propriété, je l'ai découverte récemment, mais je préfère garder les noms des arguments parce que j'utilise doxygen et je définis les paramètres dans le document final. J'écris le code doxygen dans le hpp, donc forcément