Oui, car on peut considérer qu'une forme éditable est bien une spécialisation d'une forme.
Et non, car on peut considérer que ce n'en est pas une ; p.ex. parce qu'une forme éditable est une représentation manipulable d'une forme-de-calcul, et la relation « est une représentation manipulable » peut être considérée comme de l'utilisation. De plus, suivant les différences d'utilisation, en gros le nombre d'attributs et de fonctions utilisés seulement dans le calcul ou seulement dans l'UI, il peut être intéressant d'avoir une classe mère commune et abstraite (mais qui n'empêche pas la relation « est une représentation manipulable » de se retrouver sous la forme d'une agrégation).
Au passage, je serais enclin à penser que les classes internes à la hiérarchie devraient être abstraites (= pas d'instance).
Prenons un autre cas, celui des objets CORBA. Les objets qui passent dans les tubes CORBA ont besoin d'être du même type pour pouvoir être manipulés de la même façon, ils ont aussi besoin d'une structure commune pour contenir un état relatif à CORBA. En plus, les types CORBA sont déjà organisés en hiérarchie. Les objets CORBA sont donc des classes.
Maintenant, on a déjà nos classes et nous voulons les CORBAtiser.
Si nos classes héritent déjà d'autres classes qui ne sont pas CORBAtisables, comment leur donner la possibilité d'être CORBAtisables ?
Une solution est la délégation, et on se retrouve avec des classes helper, holder et des fonctions d'indirection (p.ex. _this pour récupérer l'objet CORBA correspondant à this). Certains trouvent cela élégant. D'autres trouvent cela très lourd et très moche. (Moi, ça dépend des jours :o)
Une autre solution est l'héritage multiple (hériter de CORBA::Object en plus de son héritage normal). Mais cet héritage n'est pas de la même sorte que l'héritage précédent (qui est un héritage dû à la modélisation : on est proche du « monde réel » modélisé, la CORBAtitude est un aspect de la mise en 1⁄2uvre du système d'information, pas de son modèle). Mélanger les deux héritages (le premier est « conceptuel », le second (CORBA) est « pratique ») dans le code n'est pas considéré comme très propre. Certains aiment, d'autres non.
Une troisième solution est le mixin : la CORBAtitude est un aspect, un ensemble de services, ajouté à la classe et il existe aussi en dehors de la classe (pas forcément sous la forme d'une classe complète). C'est la solution que je préfère : elle est propre conceptuellement et claire dans le code.
Pour revenir aux formes géométriques et sur le fait q'une « forme visuellement éditable est une forme, et en plus elle est visuellement éditable », et pour expliciter le fait que l'on peut considérer que non, on peut prendre l'exemple d'un formulaire pour une BD : le formulaire contient des champs et donc une structure similaire à celle de l'entrée de la BD qu'il permet d'éditer. Pourtant, dans ce cas, je vois mal quiconque soutenir que la classe Formulaire devrait hériter de la classe ObjetDeLaBDquivabien (même si les champs du formulaire ne sont pas directement représentés par des Textfield). Avec les formes géométriques, la séparation est plus subtile : on avait String contre Textfield pour le formulaire, avec les formes, on a ensemble de points contre ensemble de points, mais on peut toujours discuter de cette distinction.
Pour finir, il faut aussi dire que les discussions sur des cas théoriques, dont le « monde réel » est coupé ou mal cerné, peuvent être considérées comme de la masturbation intellectuelle. Dans un cas réel, il y a toujours différentes solutions, chacune avec ses avantages et ses inconvénients, et les circonstances feront en choisir une. Dans la théorie, il n'y a pas d'absolu, tout est discutable.
Au moins tu n'y vas pas avec le dos de la cuillère.
Ben si, j'ai dit « pourrait sembler le faire penser » :oP
[^] # Re: Mes deux centimes ...
Posté par Sylvain Sauvage . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 3.
Oui et non.
Oui, car on peut considérer qu'une forme éditable est bien une spécialisation d'une forme.
Et non, car on peut considérer que ce n'en est pas une ; p.ex. parce qu'une forme éditable est une représentation manipulable d'une forme-de-calcul, et la relation « est une représentation manipulable » peut être considérée comme de l'utilisation. De plus, suivant les différences d'utilisation, en gros le nombre d'attributs et de fonctions utilisés seulement dans le calcul ou seulement dans l'UI, il peut être intéressant d'avoir une classe mère commune et abstraite (mais qui n'empêche pas la relation « est une représentation manipulable » de se retrouver sous la forme d'une agrégation).
Au passage, je serais enclin à penser que les classes internes à la hiérarchie devraient être abstraites (= pas d'instance).
Prenons un autre cas, celui des objets CORBA. Les objets qui passent dans les tubes CORBA ont besoin d'être du même type pour pouvoir être manipulés de la même façon, ils ont aussi besoin d'une structure commune pour contenir un état relatif à CORBA. En plus, les types CORBA sont déjà organisés en hiérarchie. Les objets CORBA sont donc des classes.
Maintenant, on a déjà nos classes et nous voulons les CORBAtiser.
Si nos classes héritent déjà d'autres classes qui ne sont pas CORBAtisables, comment leur donner la possibilité d'être CORBAtisables ?
Une solution est la délégation, et on se retrouve avec des classes helper, holder et des fonctions d'indirection (p.ex. _this pour récupérer l'objet CORBA correspondant à this). Certains trouvent cela élégant. D'autres trouvent cela très lourd et très moche. (Moi, ça dépend des jours :o)
Une autre solution est l'héritage multiple (hériter de CORBA::Object en plus de son héritage normal). Mais cet héritage n'est pas de la même sorte que l'héritage précédent (qui est un héritage dû à la modélisation : on est proche du « monde réel » modélisé, la CORBAtitude est un aspect de la mise en 1⁄2uvre du système d'information, pas de son modèle). Mélanger les deux héritages (le premier est « conceptuel », le second (CORBA) est « pratique ») dans le code n'est pas considéré comme très propre. Certains aiment, d'autres non.
Une troisième solution est le mixin : la CORBAtitude est un aspect, un ensemble de services, ajouté à la classe et il existe aussi en dehors de la classe (pas forcément sous la forme d'une classe complète). C'est la solution que je préfère : elle est propre conceptuellement et claire dans le code.
Pour revenir aux formes géométriques et sur le fait q'une « forme visuellement éditable est une forme, et en plus elle est visuellement éditable », et pour expliciter le fait que l'on peut considérer que non, on peut prendre l'exemple d'un formulaire pour une BD : le formulaire contient des champs et donc une structure similaire à celle de l'entrée de la BD qu'il permet d'éditer. Pourtant, dans ce cas, je vois mal quiconque soutenir que la classe Formulaire devrait hériter de la classe ObjetDeLaBDquivabien (même si les champs du formulaire ne sont pas directement représentés par des Textfield). Avec les formes géométriques, la séparation est plus subtile : on avait String contre Textfield pour le formulaire, avec les formes, on a ensemble de points contre ensemble de points, mais on peut toujours discuter de cette distinction.
Pour finir, il faut aussi dire que les discussions sur des cas théoriques, dont le « monde réel » est coupé ou mal cerné, peuvent être considérées comme de la masturbation intellectuelle. Dans un cas réel, il y a toujours différentes solutions, chacune avec ses avantages et ses inconvénients, et les circonstances feront en choisir une. Dans la théorie, il n'y a pas d'absolu, tout est discutable.
Ben si, j'ai dit « pourrait sembler le faire penser » :oP