Je suis novice en matière de Programmation Objet, et je souhaite avoir des
précisions sur un point.
Je souhaite créer une petite application qui gère des bordereaux de
marchandises.
J'ai pensé à créer, entres autres, deux classes :
- classe Bordereau : avec toutes les propriétés et méthodes qui s'y
rattachent (num bordereau, date, fournisseur... , un constructeur, etc.)
- classe DétailBordereau : qui contient toutes les infos du détail du
bordereau. Un bordereau a plusieurs lignes avec sur chacune le code article,
le libellé, la quantité, le prix.
Je pense (et espère) jusque là suivre une logique plausible.
Mon problème est que je ne sais pas comment faire pour faire le lien entre
lien entre les deux.
Faut-il que la classe DétailBordereau hérite de la classe Bordereau ?
Je ne voudrais pas être coincé par la suite, quand je voudrais rajouter de
nouvelles lignes à mon nouveau bordereau (car je ne sais pas au départ
combien il y en aura).
J'espère avoir été clair dans mes explications. Je vous remercie d'avance
pour votre aide et vos solutions !
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
Patrick Philippot
Bonjour,
Faut-il que la classe DétailBordereau hérite de la classe Bordereau ?
Surtout pas. DétailBordereau est simplement un composant de Bordereau qui doit gérer une collection de DétailBordereau. Donc la classe Bordereau doit avoir comme propriété une collection (Array, Liste,...) qui contient l'ensemble des références aux objets DétailBordereau constituant l'ensemble des lignes. Cette collection sera en général alimentée par une requête sur une base de données.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Bonjour,
Faut-il que la classe DétailBordereau hérite de la classe Bordereau ?
Surtout pas. DétailBordereau est simplement un composant de Bordereau
qui doit gérer une collection de DétailBordereau. Donc la classe
Bordereau doit avoir comme propriété une collection (Array, Liste,...)
qui contient l'ensemble des références aux objets DétailBordereau
constituant l'ensemble des lignes. Cette collection sera en général
alimentée par une requête sur une base de données.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Faut-il que la classe DétailBordereau hérite de la classe Bordereau ?
Surtout pas. DétailBordereau est simplement un composant de Bordereau qui doit gérer une collection de DétailBordereau. Donc la classe Bordereau doit avoir comme propriété une collection (Array, Liste,...) qui contient l'ensemble des références aux objets DétailBordereau constituant l'ensemble des lignes. Cette collection sera en général alimentée par une requête sur une base de données.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Christophe Lauer [MS]
Bonjour,
Patrick Philippot wrote:
Faut-il que la classe DétailBordereau hérite de la classe Bordereau ?
Surtout pas. DétailBordereau est simplement un composant de Bordereau qui doit gérer une collection de DétailBordereau.
Je confirme ce que répond Patrick, bien entendu ;)
La relation que vous rencontrez ici entre Bordereau et DetailBordereau est une relation de Composition, pas une relation d'Héritage.
Pour reconnaitre une relation d'héritage dans laquelle B hériterait de A, posez vous la question de savoir si un B est une sorte de A ? Par exemple, avec les exemples classiques en la matière :
- Chien et Chat, Oiseau et Mouche héritent tous de Animal. On pourrait intercaler entre Mouche et Animal la classe Insecte.
On peut donc dire que :
Un chien est un animal, Un chat est un animal, Une mouche est un insecte qui est également un animal.
Tous ont des pattes et des yeux, pour autant les pattes et des yeux ne sont pas de Animaux. Mais les animaux sont composés - entre autres - de pattes (en nombre variable, ou constant = 6 chez les insectes et d'yeux (relation de composition et non pas d'héritage). Avoir un certain nombre de pattes et d'yeux est donc bien une propriété commune de la classe Animaux qui doit être spécialisée pour chaque espèce ou sous-classe.
HTH,
-- Christophe Lauer - Relations Techniques Editeurs de Logiciels Division Développeurs et Plateforme d'Entreprise - Microsoft France http://blogs.microsoft.fr/clauer/
This posting is provided "AS IS" with no warranties, and confers no rights.
Bonjour,
Patrick Philippot wrote:
Faut-il que la classe DétailBordereau hérite de la classe Bordereau ?
Surtout pas. DétailBordereau est simplement un composant de Bordereau
qui doit gérer une collection de DétailBordereau.
Je confirme ce que répond Patrick, bien entendu ;)
La relation que vous rencontrez ici entre Bordereau et DetailBordereau est
une relation de Composition, pas une relation d'Héritage.
Pour reconnaitre une relation d'héritage dans laquelle B hériterait de A,
posez vous la question de savoir si un B est une sorte de A ? Par exemple,
avec les exemples classiques en la matière :
- Chien et Chat, Oiseau et Mouche héritent tous de Animal. On pourrait
intercaler entre Mouche et Animal la classe Insecte.
On peut donc dire que :
Un chien est un animal,
Un chat est un animal,
Une mouche est un insecte qui est également un animal.
Tous ont des pattes et des yeux, pour autant les pattes et des yeux ne sont
pas de Animaux. Mais les animaux sont composés - entre autres - de pattes
(en nombre variable, ou constant = 6 chez les insectes et d'yeux (relation
de composition et non pas d'héritage). Avoir un certain nombre de pattes et
d'yeux est donc bien une propriété commune de la classe Animaux qui doit
être spécialisée pour chaque espèce ou sous-classe.
HTH,
--
Christophe Lauer - Relations Techniques Editeurs de Logiciels
Division Développeurs et Plateforme d'Entreprise - Microsoft France
http://blogs.microsoft.fr/clauer/
This posting is provided "AS IS" with no warranties, and confers no
rights.
Faut-il que la classe DétailBordereau hérite de la classe Bordereau ?
Surtout pas. DétailBordereau est simplement un composant de Bordereau qui doit gérer une collection de DétailBordereau.
Je confirme ce que répond Patrick, bien entendu ;)
La relation que vous rencontrez ici entre Bordereau et DetailBordereau est une relation de Composition, pas une relation d'Héritage.
Pour reconnaitre une relation d'héritage dans laquelle B hériterait de A, posez vous la question de savoir si un B est une sorte de A ? Par exemple, avec les exemples classiques en la matière :
- Chien et Chat, Oiseau et Mouche héritent tous de Animal. On pourrait intercaler entre Mouche et Animal la classe Insecte.
On peut donc dire que :
Un chien est un animal, Un chat est un animal, Une mouche est un insecte qui est également un animal.
Tous ont des pattes et des yeux, pour autant les pattes et des yeux ne sont pas de Animaux. Mais les animaux sont composés - entre autres - de pattes (en nombre variable, ou constant = 6 chez les insectes et d'yeux (relation de composition et non pas d'héritage). Avoir un certain nombre de pattes et d'yeux est donc bien une propriété commune de la classe Animaux qui doit être spécialisée pour chaque espèce ou sous-classe.
HTH,
-- Christophe Lauer - Relations Techniques Editeurs de Logiciels Division Développeurs et Plateforme d'Entreprise - Microsoft France http://blogs.microsoft.fr/clauer/
This posting is provided "AS IS" with no warranties, and confers no rights.
Paul Bacelar
"Nesta" wrote in message news:%23$
Bonjour à tous,
Je suis novice en matière de Programmation Objet, et je souhaite avoir des précisions sur un point. Je souhaite créer une petite application qui gère des bordereaux de marchandises. J'ai pensé à créer, entres autres, deux classes :
- classe Bordereau : avec toutes les propriétés et méthodes qui s'y rattachent (num bordereau, date, fournisseur... , un constructeur, etc.) - classe DétailBordereau : qui contient toutes les infos du détail du bordereau. Un bordereau a plusieurs lignes avec sur chacune le code article, le libellé, la quantité, le prix.
Je pense (et espère) jusque là suivre une logique plausible. Mon problème est que je ne sais pas comment faire pour faire le lien entre lien entre les deux. Faut-il que la classe DétailBordereau hérite de la classe Bordereau ? Je ne voudrais pas être coincé par la suite, quand je voudrais rajouter de nouvelles lignes à mon nouveau bordereau (car je ne sais pas au départ combien il y en aura).
J'espère avoir été clair dans mes explications. Je vous remercie d'avance pour votre aide et vos solutions !
Nesta
Une classe doit hériter d'une autre classe si et seulement si un objet de la classe dérivée EST un objet de la classe dérivée.
Exemple: Un carré est un rectangle, donc la classe carré devra dérivé de la class rectangle.
Un bordereau n'est pas un détail de bordereau, donc pas d'héritage entre ces classes.
Vous mentionnez un problème de tableau de taille dynamique, regardez du coté des génériques si vous utilisez .NET2.0 ou la class ArrayList pour .NET1.x.
Vous n'aurez qu'à définir un membre de la classe Bordereau ayant pour type un type générique ou ArrayList, pour avoir une liste d'objet de type DétailBordereau contenu dans un objet de type Bordereau. -- Paul Bacelar MVP VC++
"Nesta" <nestaman@hotmail.com> wrote in message
news:%23$eJcE4PGHA.648@TK2MSFTNGP14.phx.gbl...
Bonjour à tous,
Je suis novice en matière de Programmation Objet, et je souhaite avoir des
précisions sur un point.
Je souhaite créer une petite application qui gère des bordereaux de
marchandises.
J'ai pensé à créer, entres autres, deux classes :
- classe Bordereau : avec toutes les propriétés et méthodes qui s'y
rattachent (num bordereau, date, fournisseur... , un constructeur, etc.)
- classe DétailBordereau : qui contient toutes les infos du détail du
bordereau. Un bordereau a plusieurs lignes avec sur chacune le code
article, le libellé, la quantité, le prix.
Je pense (et espère) jusque là suivre une logique plausible.
Mon problème est que je ne sais pas comment faire pour faire le lien entre
lien entre les deux.
Faut-il que la classe DétailBordereau hérite de la classe Bordereau ?
Je ne voudrais pas être coincé par la suite, quand je voudrais rajouter de
nouvelles lignes à mon nouveau bordereau (car je ne sais pas au départ
combien il y en aura).
J'espère avoir été clair dans mes explications. Je vous remercie d'avance
pour votre aide et vos solutions !
Nesta
Une classe doit hériter d'une autre classe si et seulement si un objet de la
classe dérivée EST un objet de la classe dérivée.
Exemple: Un carré est un rectangle, donc la classe carré devra dérivé de la
class rectangle.
Un bordereau n'est pas un détail de bordereau, donc pas d'héritage entre ces
classes.
Vous mentionnez un problème de tableau de taille dynamique, regardez du coté
des génériques si vous utilisez .NET2.0 ou la class ArrayList pour .NET1.x.
Vous n'aurez qu'à définir un membre de la classe Bordereau ayant pour type
un type générique ou ArrayList, pour avoir une liste d'objet de type
DétailBordereau contenu dans un objet de type Bordereau.
--
Paul Bacelar
MVP VC++
Je suis novice en matière de Programmation Objet, et je souhaite avoir des précisions sur un point. Je souhaite créer une petite application qui gère des bordereaux de marchandises. J'ai pensé à créer, entres autres, deux classes :
- classe Bordereau : avec toutes les propriétés et méthodes qui s'y rattachent (num bordereau, date, fournisseur... , un constructeur, etc.) - classe DétailBordereau : qui contient toutes les infos du détail du bordereau. Un bordereau a plusieurs lignes avec sur chacune le code article, le libellé, la quantité, le prix.
Je pense (et espère) jusque là suivre une logique plausible. Mon problème est que je ne sais pas comment faire pour faire le lien entre lien entre les deux. Faut-il que la classe DétailBordereau hérite de la classe Bordereau ? Je ne voudrais pas être coincé par la suite, quand je voudrais rajouter de nouvelles lignes à mon nouveau bordereau (car je ne sais pas au départ combien il y en aura).
J'espère avoir été clair dans mes explications. Je vous remercie d'avance pour votre aide et vos solutions !
Nesta
Une classe doit hériter d'une autre classe si et seulement si un objet de la classe dérivée EST un objet de la classe dérivée.
Exemple: Un carré est un rectangle, donc la classe carré devra dérivé de la class rectangle.
Un bordereau n'est pas un détail de bordereau, donc pas d'héritage entre ces classes.
Vous mentionnez un problème de tableau de taille dynamique, regardez du coté des génériques si vous utilisez .NET2.0 ou la class ArrayList pour .NET1.x.
Vous n'aurez qu'à définir un membre de la classe Bordereau ayant pour type un type générique ou ArrayList, pour avoir une liste d'objet de type DétailBordereau contenu dans un objet de type Bordereau. -- Paul Bacelar MVP VC++
Mehdi
On Sat, 4 Mar 2006 21:15:42 +0100, Paul Bacelar wrote:
Une classe doit hériter d'une autre classe si et seulement si un objet de la classe dérivée EST un objet de la classe dérivée.
Exemple: Un carré est un rectangle, donc la classe carré devra dérivé de la class rectangle.
Je pense que certain vont ticker la-dessus. En mathématique oui, un carré est un rectangle. En POO, pas forcément, ca dépends de ce qu'est un rectangle. Si la classe Rectangle définit par exemple une méthode Resize(int newWidth, int newHeight) qui garatantie de réussir si newWidth et newHeight sont 2 entiers positifs, alors un carré n'est pas un rectangle et la classe Carre ne peut pas dériver de la classe Rectangle sous peine de casser le principe meme de l'héritage.
On Sat, 4 Mar 2006 21:15:42 +0100, Paul Bacelar wrote:
Une classe doit hériter d'une autre classe si et seulement si un objet de la
classe dérivée EST un objet de la classe dérivée.
Exemple: Un carré est un rectangle, donc la classe carré devra dérivé de la
class rectangle.
Je pense que certain vont ticker la-dessus. En mathématique oui, un carré
est un rectangle. En POO, pas forcément, ca dépends de ce qu'est un
rectangle. Si la classe Rectangle définit par exemple une méthode
Resize(int newWidth, int newHeight) qui garatantie de réussir si newWidth
et newHeight sont 2 entiers positifs, alors un carré n'est pas un rectangle
et la classe Carre ne peut pas dériver de la classe Rectangle sous peine de
casser le principe meme de l'héritage.
On Sat, 4 Mar 2006 21:15:42 +0100, Paul Bacelar wrote:
Une classe doit hériter d'une autre classe si et seulement si un objet de la classe dérivée EST un objet de la classe dérivée.
Exemple: Un carré est un rectangle, donc la classe carré devra dérivé de la class rectangle.
Je pense que certain vont ticker la-dessus. En mathématique oui, un carré est un rectangle. En POO, pas forcément, ca dépends de ce qu'est un rectangle. Si la classe Rectangle définit par exemple une méthode Resize(int newWidth, int newHeight) qui garatantie de réussir si newWidth et newHeight sont 2 entiers positifs, alors un carré n'est pas un rectangle et la classe Carre ne peut pas dériver de la classe Rectangle sous peine de casser le principe meme de l'héritage.
Patrick Philippot
Mehdi wrote:
Je pense que certain vont ticker la-dessus. En mathématique oui, un carré est un rectangle. En POO, pas forcément, ca dépends de ce qu'est un rectangle...
Exact. Tout de dépend de l'utilisation prévue et des méthodes que l'on veut implémenter sur ces objets graphiques. On peut imaginer, pour définir le même type d'objets, une hiérarchie de classes tout à fait différente, par exemple:
1. Je définis un objet Point caractérisé par ses coordonnées X et Y et disons une méthode Déplacer et une méthode Dessiner.
2. Je peux dire qu'un objet Cercle dérive d'un Point (un Cercle est un point auquel on a associé un Rayon):
Class Cercle : Point int R Dessiner
Inutile de rédéfinir Déplacer dans ce cas: déplacer un cercle, c'est déplacer son centre. Par contre, dessiner un Cercle, n'est pas Dessiner un Point, je remplace.
3. Je peux dire qu'un Rectangle est un Point (son coin haut gauche) associé à une Hauteur et une Largeur
Class Rectangle : Point int H int L Dessiner
Ici encore, je n'ai pas besoin de remplacer Déplacer.
etc.
Tout dépend de l'analyse que l'on fait en fonction des besoins de l'application et du contexte d'utilisation des objets.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Mehdi wrote:
Je pense que certain vont ticker la-dessus. En mathématique oui, un
carré est un rectangle. En POO, pas forcément, ca dépends de ce
qu'est un rectangle...
Exact. Tout de dépend de l'utilisation prévue et des méthodes que l'on
veut implémenter sur ces objets graphiques. On peut imaginer, pour
définir le même type d'objets, une hiérarchie de classes tout à fait
différente, par exemple:
1. Je définis un objet Point caractérisé par ses coordonnées X et Y et
disons une méthode Déplacer et une méthode Dessiner.
2. Je peux dire qu'un objet Cercle dérive d'un Point (un Cercle est un
point auquel on a associé un Rayon):
Class Cercle : Point
int R
Dessiner
Inutile de rédéfinir Déplacer dans ce cas: déplacer un cercle, c'est
déplacer son centre. Par contre, dessiner un Cercle, n'est pas Dessiner
un Point, je remplace.
3. Je peux dire qu'un Rectangle est un Point (son coin haut gauche)
associé à une Hauteur et une Largeur
Class Rectangle : Point
int H
int L
Dessiner
Ici encore, je n'ai pas besoin de remplacer Déplacer.
etc.
Tout dépend de l'analyse que l'on fait en fonction des besoins de
l'application et du contexte d'utilisation des objets.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Je pense que certain vont ticker la-dessus. En mathématique oui, un carré est un rectangle. En POO, pas forcément, ca dépends de ce qu'est un rectangle...
Exact. Tout de dépend de l'utilisation prévue et des méthodes que l'on veut implémenter sur ces objets graphiques. On peut imaginer, pour définir le même type d'objets, une hiérarchie de classes tout à fait différente, par exemple:
1. Je définis un objet Point caractérisé par ses coordonnées X et Y et disons une méthode Déplacer et une méthode Dessiner.
2. Je peux dire qu'un objet Cercle dérive d'un Point (un Cercle est un point auquel on a associé un Rayon):
Class Cercle : Point int R Dessiner
Inutile de rédéfinir Déplacer dans ce cas: déplacer un cercle, c'est déplacer son centre. Par contre, dessiner un Cercle, n'est pas Dessiner un Point, je remplace.
3. Je peux dire qu'un Rectangle est un Point (son coin haut gauche) associé à une Hauteur et une Largeur
Class Rectangle : Point int H int L Dessiner
Ici encore, je n'ai pas besoin de remplacer Déplacer.
etc.
Tout dépend de l'analyse que l'on fait en fonction des besoins de l'application et du contexte d'utilisation des objets.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Nesta
Salut à tous et merci pour votre aide,
Merci pour les explications sur l'héritage, effectivement, ce n'était pas la bon choix. Je vais essayer de comprendre les morceaux de codes et idées que vous m'avez envoyé pour créer ce composant de ma classe Bordereau. Mais j'avoue que je reste encore un peu dans le flou quant à la façon de créer cela. C'est certainement une propriété ou un champ (ou les deux) de ma classe Bordereau, donc je vais essayer de mettre en place tout ça. Si l'un d'entre vous avait quelques articles sur ce sujet, je suis volontiers preneur.
Encore merci à tous pour votre aide.
Nesta.
"Patrick Philippot" a écrit dans le message de news: %
Mehdi wrote:
Je pense que certain vont ticker la-dessus. En mathématique oui, un carré est un rectangle. En POO, pas forcément, ca dépends de ce qu'est un rectangle...
Exact. Tout de dépend de l'utilisation prévue et des méthodes que l'on veut implémenter sur ces objets graphiques. On peut imaginer, pour définir le même type d'objets, une hiérarchie de classes tout à fait différente, par exemple:
1. Je définis un objet Point caractérisé par ses coordonnées X et Y et disons une méthode Déplacer et une méthode Dessiner.
2. Je peux dire qu'un objet Cercle dérive d'un Point (un Cercle est un point auquel on a associé un Rayon):
Class Cercle : Point int R Dessiner
Inutile de rédéfinir Déplacer dans ce cas: déplacer un cercle, c'est déplacer son centre. Par contre, dessiner un Cercle, n'est pas Dessiner un Point, je remplace.
3. Je peux dire qu'un Rectangle est un Point (son coin haut gauche) associé à une Hauteur et une Largeur
Class Rectangle : Point int H int L Dessiner
Ici encore, je n'ai pas besoin de remplacer Déplacer.
etc.
Tout dépend de l'analyse que l'on fait en fonction des besoins de l'application et du contexte d'utilisation des objets.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Salut à tous et merci pour votre aide,
Merci pour les explications sur l'héritage, effectivement, ce n'était pas la
bon choix.
Je vais essayer de comprendre les morceaux de codes et idées que vous m'avez
envoyé pour créer ce composant de ma classe Bordereau. Mais j'avoue que je
reste encore un peu dans le flou quant à la façon de créer cela. C'est
certainement une propriété ou un champ (ou les deux) de ma classe Bordereau,
donc je vais essayer de mettre en place tout ça.
Si l'un d'entre vous avait quelques articles sur ce sujet, je suis
volontiers preneur.
Encore merci à tous pour votre aide.
Nesta.
"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> a écrit dans le
message de news: %23zLdeCPQGHA.1040@TK2MSFTNGP12.phx.gbl...
Mehdi wrote:
Je pense que certain vont ticker la-dessus. En mathématique oui, un
carré est un rectangle. En POO, pas forcément, ca dépends de ce
qu'est un rectangle...
Exact. Tout de dépend de l'utilisation prévue et des méthodes que l'on
veut implémenter sur ces objets graphiques. On peut imaginer, pour définir
le même type d'objets, une hiérarchie de classes tout à fait différente,
par exemple:
1. Je définis un objet Point caractérisé par ses coordonnées X et Y et
disons une méthode Déplacer et une méthode Dessiner.
2. Je peux dire qu'un objet Cercle dérive d'un Point (un Cercle est un
point auquel on a associé un Rayon):
Class Cercle : Point
int R
Dessiner
Inutile de rédéfinir Déplacer dans ce cas: déplacer un cercle, c'est
déplacer son centre. Par contre, dessiner un Cercle, n'est pas Dessiner un
Point, je remplace.
3. Je peux dire qu'un Rectangle est un Point (son coin haut gauche)
associé à une Hauteur et une Largeur
Class Rectangle : Point
int H
int L
Dessiner
Ici encore, je n'ai pas besoin de remplacer Déplacer.
etc.
Tout dépend de l'analyse que l'on fait en fonction des besoins de
l'application et du contexte d'utilisation des objets.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Merci pour les explications sur l'héritage, effectivement, ce n'était pas la bon choix. Je vais essayer de comprendre les morceaux de codes et idées que vous m'avez envoyé pour créer ce composant de ma classe Bordereau. Mais j'avoue que je reste encore un peu dans le flou quant à la façon de créer cela. C'est certainement une propriété ou un champ (ou les deux) de ma classe Bordereau, donc je vais essayer de mettre en place tout ça. Si l'un d'entre vous avait quelques articles sur ce sujet, je suis volontiers preneur.
Encore merci à tous pour votre aide.
Nesta.
"Patrick Philippot" a écrit dans le message de news: %
Mehdi wrote:
Je pense que certain vont ticker la-dessus. En mathématique oui, un carré est un rectangle. En POO, pas forcément, ca dépends de ce qu'est un rectangle...
Exact. Tout de dépend de l'utilisation prévue et des méthodes que l'on veut implémenter sur ces objets graphiques. On peut imaginer, pour définir le même type d'objets, une hiérarchie de classes tout à fait différente, par exemple:
1. Je définis un objet Point caractérisé par ses coordonnées X et Y et disons une méthode Déplacer et une méthode Dessiner.
2. Je peux dire qu'un objet Cercle dérive d'un Point (un Cercle est un point auquel on a associé un Rayon):
Class Cercle : Point int R Dessiner
Inutile de rédéfinir Déplacer dans ce cas: déplacer un cercle, c'est déplacer son centre. Par contre, dessiner un Cercle, n'est pas Dessiner un Point, je remplace.
3. Je peux dire qu'un Rectangle est un Point (son coin haut gauche) associé à une Hauteur et une Largeur
Class Rectangle : Point int H int L Dessiner
Ici encore, je n'ai pas besoin de remplacer Déplacer.
etc.
Tout dépend de l'analyse que l'on fait en fonction des besoins de l'application et du contexte d'utilisation des objets.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
