Je cherche a construire les règles de développement d'un projet C++.
Quand une classe a pour role de conserver de l'information et a un
constructeur de recopie et un operateur d'affectation, on peut dire
qu'elle a une sémantique de valeur.
Mais pour les classes qui ont pour rôle d'inter-agir sur les autres
classes et qui "naturellement" n'ont pas de raison d'avoir un
constructeur par recopie et d'opérateur d'affectation (déclarés private
par exemple), quel nom peut-on leur donner? Controleur? Acteur? Quel nom
la "littérature c++" leur donne t-elle?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
James Kanze
Pascal wrote:
Je cherche a construire les règles de développement d'un projet C++.
Quand une classe a pour role de conserver de l'information et a un constructeur de recopie et un operateur d'affectation, on peut dire qu'elle a une sémantique de valeur.
Mais pour les classes qui ont pour rôle d'inter-agir sur les autres classes et qui "naturellement" n'ont pas de raison d'avoir un constructeur par recopie et d'opérateur d'affectation (déclarés private par exemple), quel nom peut-on leur donner? Controleur? Acteur? Quel nom la "littérature c++" leur donne t-elle?
Je ne crois pas qu'il y a un consensus là-dessus. Je sais que je me suis posé la question longtemps aussi. Actuellement, j'ai adopté la nomenclature de Kevlin Henney, en les appelant des classes d'entité (« entity classes » -- c'est mieux en anglais). Sans en être 100% convaincu, mais sans pouvoir proposer un meilleur alternatif non plus.
Quant aux autres noms que tu proposes, ils ont tous une acceptation plus restreinte dans le communité OO, ou au moins dans certaines parties de cette communité. Donc, par exemple, si tu dis « controleur », je pense tout de suite aux controlleurs de MVC, et pour certains, un acteur, c'est une classe sans état (encore que je ne crois pas que cette utilisation soit très répandue).
Note aussi qu'une certaine littérature OO n'en reconnaît pas d'autres types de classes.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Pascal wrote:
Je cherche a construire les règles de développement d'un
projet C++.
Quand une classe a pour role de conserver de l'information et
a un constructeur de recopie et un operateur d'affectation, on
peut dire qu'elle a une sémantique de valeur.
Mais pour les classes qui ont pour rôle d'inter-agir sur les
autres classes et qui "naturellement" n'ont pas de raison
d'avoir un constructeur par recopie et d'opérateur
d'affectation (déclarés private par exemple), quel nom peut-on
leur donner? Controleur? Acteur? Quel nom la "littérature c++"
leur donne t-elle?
Je ne crois pas qu'il y a un consensus là-dessus. Je sais que je
me suis posé la question longtemps aussi. Actuellement, j'ai
adopté la nomenclature de Kevlin Henney, en les appelant des
classes d'entité (« entity classes » -- c'est mieux en anglais).
Sans en être 100% convaincu, mais sans pouvoir proposer un
meilleur alternatif non plus.
Quant aux autres noms que tu proposes, ils ont tous une
acceptation plus restreinte dans le communité OO, ou au moins
dans certaines parties de cette communité. Donc, par exemple, si
tu dis « controleur », je pense tout de suite aux controlleurs
de MVC, et pour certains, un acteur, c'est une classe sans état
(encore que je ne crois pas que cette utilisation soit très
répandue).
Note aussi qu'une certaine littérature OO n'en reconnaît pas
d'autres types de classes.
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Je cherche a construire les règles de développement d'un projet C++.
Quand une classe a pour role de conserver de l'information et a un constructeur de recopie et un operateur d'affectation, on peut dire qu'elle a une sémantique de valeur.
Mais pour les classes qui ont pour rôle d'inter-agir sur les autres classes et qui "naturellement" n'ont pas de raison d'avoir un constructeur par recopie et d'opérateur d'affectation (déclarés private par exemple), quel nom peut-on leur donner? Controleur? Acteur? Quel nom la "littérature c++" leur donne t-elle?
Je ne crois pas qu'il y a un consensus là-dessus. Je sais que je me suis posé la question longtemps aussi. Actuellement, j'ai adopté la nomenclature de Kevlin Henney, en les appelant des classes d'entité (« entity classes » -- c'est mieux en anglais). Sans en être 100% convaincu, mais sans pouvoir proposer un meilleur alternatif non plus.
Quant aux autres noms que tu proposes, ils ont tous une acceptation plus restreinte dans le communité OO, ou au moins dans certaines parties de cette communité. Donc, par exemple, si tu dis « controleur », je pense tout de suite aux controlleurs de MVC, et pour certains, un acteur, c'est une classe sans état (encore que je ne crois pas que cette utilisation soit très répandue).
Note aussi qu'une certaine littérature OO n'en reconnaît pas d'autres types de classes.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Pascal B.
In article <4245a547$0$22743$, James Kanze wrote:
Je ne crois pas qu'il y a un consensus l{-dessus. Je sais que je me suis post la question longtemps aussi. Actuellement, j'ai adoptt la nomenclature de Kevlin Henney, en les appelant des classes d'entitt (Ç entity classes È -- c'est mieux en anglais). Sans en vtre 100% convaincu, mais sans pouvoir proposer un meilleur alternatif non plus.
Je pense que pour commencer, je vais garder "entity" qui me parait assez largement utilisé. Le début de l'article suivant me parait interessant à ce sujet.
Quant aux autres noms que tu proposes, ils ont tous une acceptation plus restreinte dans le communitt OO, ou au moins dans certaines parties de cette communitt. Donc, par exemple, si tu dis Ç controleur È, je pense tout de suite aux controlleurs de MVC,
Et moi aussi, mais je trouvais que "controleur de données" permettait de bien comprendre le role d'une telle classe, indépendemment du sens que lui donne MVC.
D'ou l'interêt en début de projet de fixer rigoureusement le vocabulaire technique utilisé.
et pour certains, un acteur, c'est une classe sans ttat (encore que je ne crois pas que cette utilisation soit trus rtpandue).
Le problème c'est qu'en début de codage, ou plutot en phase de conception, il n'est pas évident de savoir à coup sur qu'une classe identifiée comme "entity" possède ou non un état. Et donc il est dommage de spécialiser le vocabulaire utilisé pour une telle classe.
D'autant qu'une classe sans état me fait penser a un "trait", classe qui pour a mon sens n'est pas "entity" mais plutot une collection de fonctions (sans état) conçu dans un but de généricité (template etc...). Le fait qu'un classe "entity" n'aie pas d'état me parait absolument secondaire.
Note aussi qu'une certaine litttrature OO n'en reconnazt pas d'autres types de classes.
Je vais continuer mes recherches en prenant Kevlin Henney comme point de départ. Il est déroutant de constater qu'il est si difficile d'exprimer les choses qu'on modélise si bien dans sa tête, mais il me semble que cet effort est nécessaire pour développer un logiciel homogène quand plusieurs développeurs travaillent ensemble.
-- pascal
In article <4245a547$0$22743$626a14ce@news.free.fr>,
James Kanze <kanze@none> wrote:
Je ne crois pas qu'il y a un consensus l{-dessus. Je sais que je
me suis post la question longtemps aussi. Actuellement, j'ai
adoptt la nomenclature de Kevlin Henney, en les appelant des
classes d'entitt (Ç entity classes È -- c'est mieux en anglais).
Sans en vtre 100% convaincu, mais sans pouvoir proposer un
meilleur alternatif non plus.
Je pense que pour commencer, je vais garder "entity" qui me parait assez
largement utilisé. Le début de l'article suivant me parait interessant à
ce sujet.
Quant aux autres noms que tu proposes, ils ont tous une
acceptation plus restreinte dans le communitt OO, ou au moins
dans certaines parties de cette communitt. Donc, par exemple, si
tu dis Ç controleur È, je pense tout de suite aux controlleurs
de MVC,
Et moi aussi, mais je trouvais que "controleur de données" permettait de
bien comprendre le role d'une telle classe, indépendemment du sens que
lui donne MVC.
D'ou l'interêt en début de projet de fixer rigoureusement le vocabulaire
technique utilisé.
et pour certains, un acteur, c'est une classe sans ttat
(encore que je ne crois pas que cette utilisation soit trus
rtpandue).
Le problème c'est qu'en début de codage, ou plutot en phase de
conception, il n'est pas évident de savoir à coup sur qu'une classe
identifiée comme "entity" possède ou non un état. Et donc il est dommage
de spécialiser le vocabulaire utilisé pour une telle classe.
D'autant qu'une classe sans état me fait penser a un "trait", classe qui
pour a mon sens n'est pas "entity" mais plutot une collection de
fonctions (sans état) conçu dans un but de généricité (template etc...).
Le fait qu'un classe "entity" n'aie pas d'état me parait absolument
secondaire.
Note aussi qu'une certaine litttrature OO n'en reconnazt pas
d'autres types de classes.
Je vais continuer mes recherches en prenant Kevlin Henney comme point de
départ. Il est déroutant de constater qu'il est si difficile d'exprimer
les choses qu'on modélise si bien dans sa tête, mais il me semble que
cet effort est nécessaire pour développer un logiciel homogène quand
plusieurs développeurs travaillent ensemble.
Je ne crois pas qu'il y a un consensus l{-dessus. Je sais que je me suis post la question longtemps aussi. Actuellement, j'ai adoptt la nomenclature de Kevlin Henney, en les appelant des classes d'entitt (Ç entity classes È -- c'est mieux en anglais). Sans en vtre 100% convaincu, mais sans pouvoir proposer un meilleur alternatif non plus.
Je pense que pour commencer, je vais garder "entity" qui me parait assez largement utilisé. Le début de l'article suivant me parait interessant à ce sujet.
Quant aux autres noms que tu proposes, ils ont tous une acceptation plus restreinte dans le communitt OO, ou au moins dans certaines parties de cette communitt. Donc, par exemple, si tu dis Ç controleur È, je pense tout de suite aux controlleurs de MVC,
Et moi aussi, mais je trouvais que "controleur de données" permettait de bien comprendre le role d'une telle classe, indépendemment du sens que lui donne MVC.
D'ou l'interêt en début de projet de fixer rigoureusement le vocabulaire technique utilisé.
et pour certains, un acteur, c'est une classe sans ttat (encore que je ne crois pas que cette utilisation soit trus rtpandue).
Le problème c'est qu'en début de codage, ou plutot en phase de conception, il n'est pas évident de savoir à coup sur qu'une classe identifiée comme "entity" possède ou non un état. Et donc il est dommage de spécialiser le vocabulaire utilisé pour une telle classe.
D'autant qu'une classe sans état me fait penser a un "trait", classe qui pour a mon sens n'est pas "entity" mais plutot une collection de fonctions (sans état) conçu dans un but de généricité (template etc...). Le fait qu'un classe "entity" n'aie pas d'état me parait absolument secondaire.
Note aussi qu'une certaine litttrature OO n'en reconnazt pas d'autres types de classes.
Je vais continuer mes recherches en prenant Kevlin Henney comme point de départ. Il est déroutant de constater qu'il est si difficile d'exprimer les choses qu'on modélise si bien dans sa tête, mais il me semble que cet effort est nécessaire pour développer un logiciel homogène quand plusieurs développeurs travaillent ensemble.
