J'ai dans cette classe un membre SJ_Intervalle_Temps qui me permet de
déterminer le début et la fin de cette séquence, et que j'utilise pour
calculer la durée de la séquence.
Mais ne serait-il pas plus simple d'utiliser l'héritage dans ce cas de
figure?
J'avoue (encore une fois ;-) ) ne pas être au point sur cette notion.
Si je déclare SJ_Sequence comme héritant de SJ_Intervalle_Temps, les
membres LONGLONG debut et fin seront accessibles depuis SJ_Sequence, c'est
bien ça?
Et donc il n'y aurait plus besoin de définir une fonction DureeSequence
dans SJ_Sequence, la fonction de la classe SJ_Intervalle_Temps étant là?
Tu aurais des infos là dessus, url? Google ou n'importe quel bouqin de conception objet.
Cet après-midi...
Je n'ai pas le contexte pour comprendre ce qu'est une "séquence" dans ton cas, mais si une séquence *est* un intervalle de temps, alors utilise l'héritage, sinon reste avec l'aggregation.
Et comme c'est le cas,
Ah bon? Une séquence est un intervalle de temps? Ca représnte quoi une
séquence exactement?
Une séquence correspond à la durée pendant laquelle une équipe de basket défend ou attaque lors d'un match... Il y a donc un début (une remise en jeu, un rebond...) et une fin (tir, balle perdue...), et donc une durée.
Je trouve ça plus simple comme ça en plus... Mauvaise raison : La question est de savoir si ca a un sens par
rapport à ta modélisation objet.
Tu es le deuxième à me le dire. Ca me semblait en être une ;-)
Arnaud
adebaene@club-internet.fr (Arnaud Debaene) wrote in
news:16a4a8c7.0403040229.54e33375@posting.google.com:
Tu aurais des infos là dessus, url?
Google ou n'importe quel bouqin de conception objet.
Cet après-midi...
Je n'ai pas le contexte pour comprendre ce qu'est une "séquence"
dans ton cas, mais si une séquence *est* un intervalle de temps,
alors utilise l'héritage, sinon reste avec l'aggregation.
Et comme c'est le cas,
Ah bon? Une séquence est un intervalle de temps? Ca représnte quoi une
séquence exactement?
Une séquence correspond à la durée pendant laquelle une équipe de basket
défend ou attaque lors d'un match... Il y a donc un début (une remise en
jeu, un rebond...) et une fin (tir, balle perdue...), et donc une durée.
Je trouve ça plus simple comme ça en plus...
Mauvaise raison : La question est de savoir si ca a un sens par
rapport à ta modélisation objet.
Tu es le deuxième à me le dire. Ca me semblait en être une ;-)
Tu aurais des infos là dessus, url? Google ou n'importe quel bouqin de conception objet.
Cet après-midi...
Je n'ai pas le contexte pour comprendre ce qu'est une "séquence" dans ton cas, mais si une séquence *est* un intervalle de temps, alors utilise l'héritage, sinon reste avec l'aggregation.
Et comme c'est le cas,
Ah bon? Une séquence est un intervalle de temps? Ca représnte quoi une
séquence exactement?
Une séquence correspond à la durée pendant laquelle une équipe de basket défend ou attaque lors d'un match... Il y a donc un début (une remise en jeu, un rebond...) et une fin (tir, balle perdue...), et donc une durée.
Je trouve ça plus simple comme ça en plus... Mauvaise raison : La question est de savoir si ca a un sens par
rapport à ta modélisation objet.
Tu es le deuxième à me le dire. Ca me semblait en être une ;-)
Arnaud
Michel Michaud
Dans news:, Michaël
Une séquence correspond à la durée pendant laquelle une équipe de basket défend ou attaque lors d'un match... Il y a donc un début (une remise en jeu, un rebond...) et une fin (tir, balle perdue...), et donc une durée.
Donc une séquence « a » une durée. Elle « n'est pas » une durée.
C'est la relation dite HAS-A, pour laquelle l'héritage public n'est pas approprié. Il faut la relation IS-A pour la relation.
Prends cet exemple : que feras-tu si tu veux un jour conserver la durée en deux valeurs, une pour la détention du ballon par chaque équipe ?
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:Xns94A2800B5A525zoubidamanhotmailcom@212.27.42.67, Michaël
Une séquence correspond à la durée pendant laquelle une équipe de
basket défend ou attaque lors d'un match... Il y a donc un début
(une remise en jeu, un rebond...) et une fin (tir, balle
perdue...), et donc une durée.
Donc une séquence « a » une durée. Elle « n'est pas » une durée.
C'est la relation dite HAS-A, pour laquelle l'héritage public
n'est pas approprié. Il faut la relation IS-A pour la relation.
Prends cet exemple : que feras-tu si tu veux un jour conserver
la durée en deux valeurs, une pour la détention du ballon par
chaque équipe ?
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Une séquence correspond à la durée pendant laquelle une équipe de basket défend ou attaque lors d'un match... Il y a donc un début (une remise en jeu, un rebond...) et une fin (tir, balle perdue...), et donc une durée.
Donc une séquence « a » une durée. Elle « n'est pas » une durée.
C'est la relation dite HAS-A, pour laquelle l'héritage public n'est pas approprié. Il faut la relation IS-A pour la relation.
Prends cet exemple : que feras-tu si tu veux un jour conserver la durée en deux valeurs, une pour la détention du ballon par chaque équipe ?
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Michel Michaud
Dans news:gwF1c.17010$, Michel
C'est la relation dite HAS-A, pour laquelle l'héritage public n'est pas approprié. Il faut la relation IS-A pour la relation.
Il faut la relation IS-A pour « l'héritage public ».
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:gwF1c.17010$qA2.977909@news20.bellglobal.com, Michel
C'est la relation dite HAS-A, pour laquelle l'héritage public
n'est pas approprié. Il faut la relation IS-A pour la relation.
Il faut la relation IS-A pour « l'héritage public ».
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
"Michel Michaud" wrote in news:gwF1c.17010$qA2.977909 @news20.bellglobal.com:
Donc une séquence « a » une durée. Elle « n'est pas » une durée.
Ben c'est aussi une durée il me semble... Je trouve que l'on peut dire les deux...
C'est la relation dite HAS-A, pour laquelle l'héritage public n'est pas approprié. Il faut la relation IS-A pour la relation.
Prends cet exemple : que feras-tu si tu veux un jour conserver la durée en deux valeurs, une pour la détention du ballon par chaque équipe ?
Excuse moi, mais je suis pas sûr d'avoir bien compris...
Michel Michaud
Dans news:, Michaël
"Michel Michaud" wrote in news:gwF1c.17010$qA2.977909 @news20.bellglobal.com:
Donc une séquence « a » une durée. Elle « n'est pas » une durée.
Ben c'est aussi une durée il me semble... Je trouve que l'on peut dire les deux...
On peut certainement dire les deux, mais c'est par simplification de la langue. Par exemple, avec une durée je m'attends à pouvoir ajouter des secondes, la diviser en deux, etc. Est-ce que je peux faire ça avec un séquence ? Si ces opérations existent pour la durée, alors elles doivent pouvoir s'appliquer correctement sur une séquence (car l'héritage public permet de le faire). Je ne crois pas que ce soit des opérations que tu veuilles faire sur tes séquences, je me trompe ?
C'est la relation dite HAS-A, pour laquelle l'héritage public n'est pas approprié. Il faut la relation IS-A pour la relation.
Prends cet exemple : que feras-tu si tu veux un jour conserver la durée en deux valeurs, une pour la détention du ballon par chaque équipe ?
Excuse moi, mais je suis pas sûr d'avoir bien compris...
Actuellement l'héritage marche (d'après ce que tu dis), mais comment ferais-tu si tu devais conserver deux durées dans une séquence ? Comme tu parlais de séquence de basket, je donnais l'exemple de la durée de possession du ballon. On pourrait aussi dire la durée pendant laquelle une équipe est dans une zone du jeu, etc., et avoir plus que deux durées. Comme l'héritage t'en donne une, tu devrais mettre les autres comme membre. Laquelle serait donnée par l'héritage ? Clairement un séquence n'« est » pas une de ces durées plus qu'une autre. Elle doit simplement contenir des durées...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:Xns94A290B1D30ACzoubidamanhotmailcom@212.27.42.67, Michaël
"Michel Michaud" <mm@gdzid.com> wrote in news:gwF1c.17010$qA2.977909
@news20.bellglobal.com:
Donc une séquence « a » une durée. Elle « n'est pas » une durée.
Ben c'est aussi une durée il me semble... Je trouve que l'on peut
dire les deux...
On peut certainement dire les deux, mais c'est par simplification
de la langue. Par exemple, avec une durée je m'attends à pouvoir
ajouter des secondes, la diviser en deux, etc. Est-ce que je
peux faire ça avec un séquence ? Si ces opérations existent pour
la durée, alors elles doivent pouvoir s'appliquer correctement
sur une séquence (car l'héritage public permet de le faire). Je
ne crois pas que ce soit des opérations que tu veuilles faire
sur tes séquences, je me trompe ?
C'est la relation dite HAS-A, pour laquelle l'héritage public
n'est pas approprié. Il faut la relation IS-A pour la relation.
Prends cet exemple : que feras-tu si tu veux un jour conserver
la durée en deux valeurs, une pour la détention du ballon par
chaque équipe ?
Excuse moi, mais je suis pas sûr d'avoir bien compris...
Actuellement l'héritage marche (d'après ce que tu dis), mais
comment ferais-tu si tu devais conserver deux durées dans une
séquence ? Comme tu parlais de séquence de basket, je donnais
l'exemple de la durée de possession du ballon. On pourrait
aussi dire la durée pendant laquelle une équipe est dans une
zone du jeu, etc., et avoir plus que deux durées. Comme
l'héritage t'en donne une, tu devrais mettre les autres comme
membre. Laquelle serait donnée par l'héritage ? Clairement un
séquence n'« est » pas une de ces durées plus qu'une autre.
Elle doit simplement contenir des durées...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
"Michel Michaud" wrote in news:gwF1c.17010$qA2.977909 @news20.bellglobal.com:
Donc une séquence « a » une durée. Elle « n'est pas » une durée.
Ben c'est aussi une durée il me semble... Je trouve que l'on peut dire les deux...
On peut certainement dire les deux, mais c'est par simplification de la langue. Par exemple, avec une durée je m'attends à pouvoir ajouter des secondes, la diviser en deux, etc. Est-ce que je peux faire ça avec un séquence ? Si ces opérations existent pour la durée, alors elles doivent pouvoir s'appliquer correctement sur une séquence (car l'héritage public permet de le faire). Je ne crois pas que ce soit des opérations que tu veuilles faire sur tes séquences, je me trompe ?
C'est la relation dite HAS-A, pour laquelle l'héritage public n'est pas approprié. Il faut la relation IS-A pour la relation.
Prends cet exemple : que feras-tu si tu veux un jour conserver la durée en deux valeurs, une pour la détention du ballon par chaque équipe ?
Excuse moi, mais je suis pas sûr d'avoir bien compris...
Actuellement l'héritage marche (d'après ce que tu dis), mais comment ferais-tu si tu devais conserver deux durées dans une séquence ? Comme tu parlais de séquence de basket, je donnais l'exemple de la durée de possession du ballon. On pourrait aussi dire la durée pendant laquelle une équipe est dans une zone du jeu, etc., et avoir plus que deux durées. Comme l'héritage t'en donne une, tu devrais mettre les autres comme membre. Laquelle serait donnée par l'héritage ? Clairement un séquence n'« est » pas une de ces durées plus qu'une autre. Elle doit simplement contenir des durées...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Michaël Delva
"Michel Michaud" wrote in news:wdI1c.17448$:
On peut certainement dire les deux, mais c'est par simplification de la langue. Par exemple, avec une durée je m'attends à pouvoir ajouter des secondes, la diviser en deux, etc. Est-ce que je peux faire ça avec un séquence ? Si ces opérations existent pour la durée, alors elles doivent pouvoir s'appliquer correctement sur une séquence (car l'héritage public permet de le faire). Je ne crois pas que ce soit des opérations que tu veuilles faire sur tes séquences, je me trompe ?
Non, mais ce ne sont pas non plus des opérations que je fais pour une durée. Elles sont fixées et ne sont plus appellées à changer.
Actuellement l'héritage marche (d'après ce que tu dis),
;-)
mais comment ferais-tu si tu devais conserver deux durées dans une séquence ? Comme tu parlais de séquence de basket, je donnais l'exemple de la durée de possession du ballon. On pourrait aussi dire la durée pendant laquelle une équipe est dans une zone du jeu, etc., et avoir plus que deux durées. Comme l'héritage t'en donne une, tu devrais mettre les autres comme membre. Laquelle serait donnée par l'héritage ? Clairement un séquence n'« est » pas une de ces durées plus qu'une autre. Elle doit simplement contenir des durées...
Là aussi, dans ma conception, une séquence n'est pas non plus amenée à être modifiée... Une possession = Une Séquence = Une durée
Loin de moi l'idée de vouloir avoir obstinément raison, mais il me semble ne pas être dans le faux sur ce point, même si tous les arguments que tu avances sont incontestables.
"Michel Michaud" <mm@gdzid.com> wrote in
news:wdI1c.17448$qA2.1002267@news20.bellglobal.com:
On peut certainement dire les deux, mais c'est par simplification
de la langue. Par exemple, avec une durée je m'attends à pouvoir
ajouter des secondes, la diviser en deux, etc. Est-ce que je
peux faire ça avec un séquence ? Si ces opérations existent pour
la durée, alors elles doivent pouvoir s'appliquer correctement
sur une séquence (car l'héritage public permet de le faire). Je
ne crois pas que ce soit des opérations que tu veuilles faire
sur tes séquences, je me trompe ?
Non, mais ce ne sont pas non plus des opérations que je fais pour une
durée. Elles sont fixées et ne sont plus appellées à changer.
Actuellement l'héritage marche (d'après ce que tu dis),
;-)
mais
comment ferais-tu si tu devais conserver deux durées dans une
séquence ? Comme tu parlais de séquence de basket, je donnais
l'exemple de la durée de possession du ballon. On pourrait
aussi dire la durée pendant laquelle une équipe est dans une
zone du jeu, etc., et avoir plus que deux durées. Comme
l'héritage t'en donne une, tu devrais mettre les autres comme
membre. Laquelle serait donnée par l'héritage ? Clairement un
séquence n'« est » pas une de ces durées plus qu'une autre.
Elle doit simplement contenir des durées...
Là aussi, dans ma conception, une séquence n'est pas non plus amenée à
être modifiée... Une possession = Une Séquence = Une durée
Loin de moi l'idée de vouloir avoir obstinément raison, mais il me semble
ne pas être dans le faux sur ce point, même si tous les arguments que tu
avances sont incontestables.
On peut certainement dire les deux, mais c'est par simplification de la langue. Par exemple, avec une durée je m'attends à pouvoir ajouter des secondes, la diviser en deux, etc. Est-ce que je peux faire ça avec un séquence ? Si ces opérations existent pour la durée, alors elles doivent pouvoir s'appliquer correctement sur une séquence (car l'héritage public permet de le faire). Je ne crois pas que ce soit des opérations que tu veuilles faire sur tes séquences, je me trompe ?
Non, mais ce ne sont pas non plus des opérations que je fais pour une durée. Elles sont fixées et ne sont plus appellées à changer.
Actuellement l'héritage marche (d'après ce que tu dis),
;-)
mais comment ferais-tu si tu devais conserver deux durées dans une séquence ? Comme tu parlais de séquence de basket, je donnais l'exemple de la durée de possession du ballon. On pourrait aussi dire la durée pendant laquelle une équipe est dans une zone du jeu, etc., et avoir plus que deux durées. Comme l'héritage t'en donne une, tu devrais mettre les autres comme membre. Laquelle serait donnée par l'héritage ? Clairement un séquence n'« est » pas une de ces durées plus qu'une autre. Elle doit simplement contenir des durées...
Là aussi, dans ma conception, une séquence n'est pas non plus amenée à être modifiée... Une possession = Une Séquence = Une durée
Loin de moi l'idée de vouloir avoir obstinément raison, mais il me semble ne pas être dans le faux sur ce point, même si tous les arguments que tu avances sont incontestables.
Fabien LE LEZ
On 04 Mar 2004 16:48:46 GMT, "Michaël Delva" wrote:
Si ces opérations existent pour
la durée, alors elles doivent pouvoir s'appliquer correctement sur une séquence (car l'héritage public permet de le faire). Je ne crois pas que ce soit des opérations que tu veuilles faire sur tes séquences, je me trompe ?
Non, mais ce ne sont pas non plus des opérations que je fais pour une durée.
Dans ce cas, c'est le mot "durée" qui est mal choisi.
-- ;-)
On 04 Mar 2004 16:48:46 GMT, "Michaël Delva" <zoubidaman@hotmail.com>
wrote:
Si ces opérations existent pour
la durée, alors elles doivent pouvoir s'appliquer correctement
sur une séquence (car l'héritage public permet de le faire). Je
ne crois pas que ce soit des opérations que tu veuilles faire
sur tes séquences, je me trompe ?
Non, mais ce ne sont pas non plus des opérations que je fais pour une
durée.
Dans ce cas, c'est le mot "durée" qui est mal choisi.
On 04 Mar 2004 16:48:46 GMT, "Michaël Delva" wrote:
Si ces opérations existent pour
la durée, alors elles doivent pouvoir s'appliquer correctement sur une séquence (car l'héritage public permet de le faire). Je ne crois pas que ce soit des opérations que tu veuilles faire sur tes séquences, je me trompe ?
Non, mais ce ne sont pas non plus des opérations que je fais pour une durée.
Dans ce cas, c'est le mot "durée" qui est mal choisi.
-- ;-)
Valdo Tschantre
En règle général, en objet, si c'est possible, il est préférable de *choisir la composition plutôt que l'héritage*. L'héritage à le gros défaut de casser l'encapsulation, puisque les sous classe ont accès au membre de leur super classe ; et la composition apporte une souplesse dynamique. De plus, il est souvent (toujours ?) possible de remplacer un héritage par une *composition par délégation*...
Même si cela te semble moins facile, programmer avec ce paterne apporte une plus grande stabilité et souplesse à ton système.
Valdo.
En règle général, en objet, si c'est possible, il est préférable de
*choisir la composition plutôt que l'héritage*. L'héritage à le gros
défaut de casser l'encapsulation, puisque les sous classe ont accès au
membre de leur super classe ; et la composition apporte une souplesse
dynamique. De plus, il est souvent (toujours ?) possible de remplacer
un héritage par une *composition par délégation*...
Même si cela te semble moins facile, programmer avec ce paterne apporte
une plus grande stabilité et souplesse à ton système.
En règle général, en objet, si c'est possible, il est préférable de *choisir la composition plutôt que l'héritage*. L'héritage à le gros défaut de casser l'encapsulation, puisque les sous classe ont accès au membre de leur super classe ; et la composition apporte une souplesse dynamique. De plus, il est souvent (toujours ?) possible de remplacer un héritage par une *composition par délégation*...
Même si cela te semble moins facile, programmer avec ce paterne apporte une plus grande stabilité et souplesse à ton système.
Valdo.
Michel Michaud
Dans news:, Michaël [...]
Non, mais ce ne sont pas non plus des opérations que je fais pour une durée. Elles sont fixées et ne sont plus appellées à changer. [...]
Là aussi, dans ma conception, une séquence n'est pas non plus amenée à être modifiée... Une possession = Une Séquence = Une durée
Loin de moi l'idée de vouloir avoir obstinément raison, mais il me semble ne pas être dans le faux sur ce point, même si tous les arguments que tu avances sont incontestables.
Comme je ne connais pas ton programme précisément, je ne peux te dire si ton raisonnement précis est correct. Cependant si tu programmes toujours en tenant ce genre de raisonnement, tu auras certainement un problème un jour (ne serait-ce que face à un employeur éventuel).
Utilises-tu des constantes nommées dans tes programmes ? Fais-tu quelques fonctions plus génériques que nécessaires, en passant quelques paramètres, en te disant qu'elles pourront peut-être servir plus loin dans le programme ? Donnes-tu des noms plus génériques à tes classes pour ne pas limiter leur emploi ? Tout ça devrait être le cas dans un programme bien fait...
Pour la dernière question, je pense que la réponse est oui, et c'est justement de quoi l'on parle... Tu n'as pas nommé ta classe SJ_Intervalle_Temps_Sequence, mais bien seulement SJ_Intervalle_Temps. Alors il possible qu'en développant ton programme (ou un autre), tu te rendes compte que cette classe serait utile ailleurs, en autant qu'on lui ajoute certaines fonctionnalités. La solution n'est pas de faire du copier-coller et de maintenir plusieurs classes similaires, mais bien de faire une meilleure classe pour les intervalles de temps et de s'en servir partout. Et alors ta dérivation ne serait plus aussi « sûre » que maintenant.
Il ne faut pas programmer dans le « here and now ». Il ne suffit pas que les programmes fonctionnent pour conclure qu'on a fait du bon travail.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:Xns94A2B53D9A3D2zoubidamanhotmailcom@212.27.42.67, Michaël
[...]
Non, mais ce ne sont pas non plus des opérations que je fais pour
une durée. Elles sont fixées et ne sont plus appellées à changer.
[...]
Là aussi, dans ma conception, une séquence n'est pas non plus
amenée à être modifiée... Une possession = Une Séquence = Une durée
Loin de moi l'idée de vouloir avoir obstinément raison, mais il me
semble ne pas être dans le faux sur ce point, même si tous les
arguments que tu avances sont incontestables.
Comme je ne connais pas ton programme précisément, je ne peux te
dire si ton raisonnement précis est correct. Cependant si tu
programmes toujours en tenant ce genre de raisonnement, tu auras
certainement un problème un jour (ne serait-ce que face à un
employeur éventuel).
Utilises-tu des constantes nommées dans tes programmes ? Fais-tu
quelques fonctions plus génériques que nécessaires, en passant
quelques paramètres, en te disant qu'elles pourront peut-être
servir plus loin dans le programme ? Donnes-tu des noms plus
génériques à tes classes pour ne pas limiter leur emploi ? Tout
ça devrait être le cas dans un programme bien fait...
Pour la dernière question, je pense que la réponse est oui, et
c'est justement de quoi l'on parle... Tu n'as pas nommé ta
classe SJ_Intervalle_Temps_Sequence, mais bien seulement
SJ_Intervalle_Temps. Alors il possible qu'en développant ton
programme (ou un autre), tu te rendes compte que cette classe
serait utile ailleurs, en autant qu'on lui ajoute certaines
fonctionnalités. La solution n'est pas de faire du copier-coller
et de maintenir plusieurs classes similaires, mais bien de faire
une meilleure classe pour les intervalles de temps et de s'en
servir partout. Et alors ta dérivation ne serait plus aussi
« sûre » que maintenant.
Il ne faut pas programmer dans le « here and now ». Il ne
suffit pas que les programmes fonctionnent pour conclure qu'on
a fait du bon travail.
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Non, mais ce ne sont pas non plus des opérations que je fais pour une durée. Elles sont fixées et ne sont plus appellées à changer. [...]
Là aussi, dans ma conception, une séquence n'est pas non plus amenée à être modifiée... Une possession = Une Séquence = Une durée
Loin de moi l'idée de vouloir avoir obstinément raison, mais il me semble ne pas être dans le faux sur ce point, même si tous les arguments que tu avances sont incontestables.
Comme je ne connais pas ton programme précisément, je ne peux te dire si ton raisonnement précis est correct. Cependant si tu programmes toujours en tenant ce genre de raisonnement, tu auras certainement un problème un jour (ne serait-ce que face à un employeur éventuel).
Utilises-tu des constantes nommées dans tes programmes ? Fais-tu quelques fonctions plus génériques que nécessaires, en passant quelques paramètres, en te disant qu'elles pourront peut-être servir plus loin dans le programme ? Donnes-tu des noms plus génériques à tes classes pour ne pas limiter leur emploi ? Tout ça devrait être le cas dans un programme bien fait...
Pour la dernière question, je pense que la réponse est oui, et c'est justement de quoi l'on parle... Tu n'as pas nommé ta classe SJ_Intervalle_Temps_Sequence, mais bien seulement SJ_Intervalle_Temps. Alors il possible qu'en développant ton programme (ou un autre), tu te rendes compte que cette classe serait utile ailleurs, en autant qu'on lui ajoute certaines fonctionnalités. La solution n'est pas de faire du copier-coller et de maintenir plusieurs classes similaires, mais bien de faire une meilleure classe pour les intervalles de temps et de s'en servir partout. Et alors ta dérivation ne serait plus aussi « sûre » que maintenant.
Il ne faut pas programmer dans le « here and now ». Il ne suffit pas que les programmes fonctionnent pour conclure qu'on a fait du bon travail.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Michel Michaud
Dans news:, Fabien LE
On Wed, 3 Mar 2004 20:16:02 -0500, "Michel Michaud" wrote:
(en fait, elle a dit quelque chose comme « If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behaviour of P is unchanged when o1 is substituted for o2 then S is a subtype of T. »)
Houlà, ça devient compliqué, ça. J'ai peut-être mal compris le terme "subtype". Est-ce un équivalent de "dérivée", ou totalement autre chose.
Tu peux considérer que c'est un synonyme, mais ça ne changera pas la confusion : le point de vue est très différent et ce qu'il faut en retenir (en tant que programmeur C++) n'est pas directement visible dans l'énoncé ! D'une certaine façon, c'est totalement autre chose, sauf qu'un subtype est aussi un type dérivé, au moins aux yeux d'un programmeur C++.
Prenons un exemple :
class T { public: virtual string nom_du_type() { return "T"; } ... }; class S : public T { public: virtual string nom_du_type() { return "S"; } ... };
Soit un objet o1 de classe S. P(o1) affichera "S". Quel que soit o2 de classe T, P(o2) affichera "T".
Donc, quel que soit le contenu de S et T par ailleurs, dériver S de T n'est pas correct ?
Ce n'est pas la conclusion qu'il faut en tirer : Liskov ne dit pas ce qui est correct ou non, elle définit sa notion de subtype !
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:bg2d40525k15hqic05smp2beakm1k2lblq@4ax.com, Fabien LE
On Wed, 3 Mar 2004 20:16:02 -0500, "Michel Michaud" <mm@gdzid.com>
wrote:
(en fait, elle a dit quelque chose
comme « If for each object o1 of type S there is an object o2 of
type T such that for all programs P defined in terms of T, the
behaviour of P is unchanged when o1 is substituted for o2 then S
is a subtype of T. »)
Houlà, ça devient compliqué, ça. J'ai peut-être mal compris le terme
"subtype". Est-ce un équivalent de "dérivée", ou totalement autre
chose.
Tu peux considérer que c'est un synonyme, mais ça ne changera pas
la confusion : le point de vue est très différent et ce qu'il faut
en retenir (en tant que programmeur C++) n'est pas directement
visible dans l'énoncé ! D'une certaine façon, c'est totalement
autre chose, sauf qu'un subtype est aussi un type dérivé, au moins
aux yeux d'un programmeur C++.
Prenons un exemple :
class T
{
public: virtual string nom_du_type() { return "T"; }
...
};
class S : public T
{
public: virtual string nom_du_type() { return "S"; }
...
};
On Wed, 3 Mar 2004 20:16:02 -0500, "Michel Michaud" wrote:
(en fait, elle a dit quelque chose comme « If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behaviour of P is unchanged when o1 is substituted for o2 then S is a subtype of T. »)
Houlà, ça devient compliqué, ça. J'ai peut-être mal compris le terme "subtype". Est-ce un équivalent de "dérivée", ou totalement autre chose.
Tu peux considérer que c'est un synonyme, mais ça ne changera pas la confusion : le point de vue est très différent et ce qu'il faut en retenir (en tant que programmeur C++) n'est pas directement visible dans l'énoncé ! D'une certaine façon, c'est totalement autre chose, sauf qu'un subtype est aussi un type dérivé, au moins aux yeux d'un programmeur C++.
Prenons un exemple :
class T { public: virtual string nom_du_type() { return "T"; } ... }; class S : public T { public: virtual string nom_du_type() { return "S"; } ... };
