J'ai un objet instancié lors de la compilation en fonction de la configuration de construction. En ce qui concerne les logiciels environnants pris en compte, l'objet expose la même interface. Je voudrais modéliser le fait que la décision d'instanciation est prise pendant la compilation (c'est-à-dire Y a-t-il un moyen de décrire un polymorphisme statique dans Voici plus ou moins ce dont j'ai besoin:
évidemment, une seule des définitions de type ci-dessus sera instanciée à la compilation. polymorphisme statique ), par opposition au polymorphisme dynamique habituel.
UML diagramme de classe ?
5 Réponses :
Je pense que la représentation UML sera la même pour le polymorphisme statique et dynamique. UML est sur la manière dont les classes interagissent à l'exécution - je ne crois pas qu'il existe un format UML pour décrire des modèles, mais je pourrais me tromper.
UML n'est pas sur la manière dont les classes interagissent au moment de l'exécution. Les diagrammes de classe sont à propos de statique relations entre différentes entités. D'autres diagrammes UML peuvent être utilisés pour décrire le comportement d'exécution.
Oui, je suis d'accord qu'il représente des relations statiques au moment de l'exécution. Mais je pense toujours qu'il n'y a aucun moyen de différencier le polymorphisme statique / dynamique.
Eh bien, c'est la différence entre le polymorphisme dynamique et statique - en premier concerne les relations au moment de l'exécution et la seconde sur les relations à la compilation.
Il existe en effet une manière UML de décrire des modèles, un rectangle dans le coin supérieur droit de la classe qui répertorie les types de modèles. Il existe également un moyen de désigner une liaison de modèle en tant que type spécial d'héritage.
Stackoverflow.com/Questtions/860501/...
@flup c'est intéressant, merci. Cependant, ma question est légèrement différente - je souhaite choisir entre les différentes variantes d'héritages à la compilation.
@icePack Oui, je pense que votre question a peu à voir avec les modèles UML. Ils sont utilisés dans le modèle de gabarit curieusement récurrent, qui est un type de polymorphisme statique différent. L'affiche a copié un peu trop de la réponse de quelqu'un d'autre à une autre question :)
J'utiliserais des stéréotypes pour résoudre le problème. Donc, vous pouvez marquer dynamique et statique
Mais cela entraînerait un diagramme pas si clair. Supposons que je marque statique sur interface -> Connexion de classe dérivée. Cela signifie naturellement que les dérivations statiques statiques , tandis que l'intention est d'en avoir une seule (nous parlons de polymorphisme après tout). En fait, je viens d'ajouter une notation XOR entre les 2 dérivations du diagramme de classe. Peut-être que je vais le combiner avec votre suggestion, merci.
Votre idée avec XOR sonne pas chauve-souris.
Utilisez un utilitaire de classe vide avec stéréotype édité forte> (en réponse à un commentaire) p> Pseudo-C ++ - Code: P> singleton code> avec un paramètre booléen générique nommé par exemple. #ifdef (your_flag) code>, dont la spécialisation code> true code> a l'instance en tant que membre statique de visibilité publique ou de mise en œuvre. class Foo;
template <
Boolean #ifdef(WHATEVER)
> struct Bar {};
template <>
struct Bar<true> {
public:
static Foo the_foo;
};
Pas sûr que je comprenne. Pouvez-vous ajouter un exemple de diagramme?
Une chose que je trouve dérangeant à propos de UML est que le dessin de ce que les diagrammes amusants prend souvent plus de temps que de rédiger le code; pls vois mon édition ci-dessus.
C'est la mise en œuvre. Je ne demande pas Comment pour mettre en œuvre un polymorphisme statique, mais comment la décrire dans le diagramme. En fait, j'ai quelque chose de similaire à votre extrait (bien que je ne vois pas la signification du membre statique dans votre exemple - je ne veux pas restreindre le nombre d'objets avec une spécialisation spécifique, je veux choisir une des spécialisations existantes lors de la compilation).
Non ce n'est pas la mise en œuvre. C'est une description textuelle de ce que vous pouvez dessiner dans votre diagramme.
Eh bien, c'est exactement la question. Je sais comment décrire mes intentions et vouloir utiliser UML à des fins de conception au lieu de descriptions textuelles.
Je pense en quelque sorte que je le disais déjà clairement, mais de toute façon: 1.Draw une classe de modèle (comme ma première "barre"). 2. Dessinez une classe de modèle instanciée (comme ma deuxième "bar"). 3. Ajouter un lien "Instanciations" entre eux. 4. Ajoutez les étiquettes stéréotypes que j'ai mentionnées.
1. Quelle est la classe de modèle en UML? Je ne connais pas cette notation. Quoi qu'il en soit, j'ai une classe régulière dessinée à l'aide du modèle C ++ Naming Sémantics (<...>), mais cela ne fait pas partie de la spécification UML formelle, autant que je sache. 2. Le plus important - je ne vois pas comment vos stéréotypes clarifient le but (et le singleton n'est pas lié au problème du tout)
Donc, vous savez ce qu'est un modèle C ++, mais vous ne pouvez pas traduire cela en UML?
Y a-t-il un but pour cette question? Le concept de modèle est lié à la mise en œuvre, non à la conception et à ce titre, il devrait être dérivé de la conception, et non inversement. Rien dans la question n'implique que l'utilisation des modèles, un résultat similaire peut être obtenu avec #Ifdefs ou créer une configuration.
Ok, finissons ça, tu gaspillons mon temps. Je vous ai dit plusieurs fois ce que le pseudo-code était destiné et comment travailler avec cela. Il suffit de prendre ou de le laisser. Au revoir.
Vous avez posté quelque chose de sans rapport avec la question et vous prétendez maintenant que je gaspillons votre temps en essayant de vous remettre quelque chose d'utile? Cette réponse serait mieux supprimée. Je vous suggère de commencer à prendre en compte vos actions. Au revoir.
Combinaison de @chiragdesai et @ user2004268 Réponses et question liée ( Définition et mise en œuvre du polymorphisme statique ):
Je pense que votre diagramme va bien. Ce que vous décrivez semble être décrit comme un diagramme de séquence décrivant votre processus de compilation. (Genre de comme comment vous dessineriez un diagramme de séquence d'usine, je suppose)
Lorsque vous signalez correctement, les interactions au moment de l'exécution se produisent avec une chose concrète inconnue derrière l'interface, de sorte que vous n'avez jamais vraiment à vous soucier de classes concrètes dans ces séquences ou diagrammes d'interaction. C'est complètement non pertinent là-bas.
S'il y a beaucoup de choses à faire, un diagramme de déploiement pourrait également être une bonne idée d'aider à montrer quelles circonstances dans quelles circonstances.
Vous voudriez documenter des cours qui implémentent vos interfaces bien sûr, et c'est juste un diagramme de classe normal exactement comme vous l'avez tiré.
Insights intéressants! Jamais pensé au diagramme de séquence pour la compilation - un peu non conventionnel mais pourquoi pas? Le diagramme de déploiement ressemble également à une bonne idée. Merci +1
Stackoverflow.com/questions/4557141/...
Les appelants des méthodes de l'interface connaissent-ils lors de la compilation de la mise en œuvre explicite de la sous-classe à appeler? Si oui, comment cela est-il atteint?
@flup - Non, ils ne savent pas. Sinon, tout le but du polymorphisme aurait été perdu. La mise en œuvre explicite est dérivée de la configuration de l'environnement de construction.
Si je vous comprends bien, les appelants sont compilés pour utiliser l'interface et la fonction concrète à l'appel est déterminée au moment de l'exécution. Donc c'est un polymorphisme dynamique / sous-type. Que se passe-t-il au moment de la compilation, c'est l'injection de dépendance?
@FLUP Non, la mise en œuvre concrète est décidée au moment de la compilation selon un drapeau de préprocesseur qui diffère par configuration de construction. L'interface pour les deux implémentations est la même.