Bonjour,
J'ai créé un contrôle UserControl1 grace au code suivant :
public partial class UserControl1 : Button
{
public UserControl1()
{
InitializeComponent();
}
private void UserControl1_Click(object sender, EventArgs e)
{
MessageBox.Show("Merci d'avoir cliqué sur le controle
UserControl1");
}
}
Ce contrôle contient une méthode permettant d'afficher le message "Merci
d'avoir cliqué sur le controle UserControl1" lorsqu'on clique dessus.
Tout marche bien lorsque j'ajoute ce contrôle à mes formulaires et que je
clique sur le contrôle, le bon message s'affiche.
Je veux surcharger cette méthode dans un formulaire spécifique. Pour ce
faire je mets le code suivant attaché au clic sur ce contrôle dans mon
formulaire spécifique.
private void userControl11_Click(object sender, EventArgs e)
{
MessageBox.Show("Je veux surcharger le code du click sur ce
controle");
}
Malheureusement à l'exécution, il m'affiche d'abord le message de la
classe "Merci d'avoir cliqué sur le controle UserControl1" puis le message
de surcharge "Je veux surcharger le code du click sur ce controle".
Que dois-je faire pour afficher uniquement le message de surcharge "Je
veux surcharger le code du click sur ce controle" sans afficher le message
de la classe.
Merci d'avance pour vos contributions.
Bonjour,
J'ai créé un contrôle UserControl1 grace au code suivant :
public partial class UserControl1 : Button
{
public UserControl1()
{
InitializeComponent();
}
private void UserControl1_Click(object sender, EventArgs e)
{
MessageBox.Show("Merci d'avoir cliqué sur le controle
UserControl1");
}
}
Ce contrôle contient une méthode permettant d'afficher le message "Merci
d'avoir cliqué sur le controle UserControl1" lorsqu'on clique dessus.
Tout marche bien lorsque j'ajoute ce contrôle à mes formulaires et que je
clique sur le contrôle, le bon message s'affiche.
Je veux surcharger cette méthode dans un formulaire spécifique. Pour ce
faire je mets le code suivant attaché au clic sur ce contrôle dans mon
formulaire spécifique.
private void userControl11_Click(object sender, EventArgs e)
{
MessageBox.Show("Je veux surcharger le code du click sur ce
controle");
}
Malheureusement à l'exécution, il m'affiche d'abord le message de la
classe "Merci d'avoir cliqué sur le controle UserControl1" puis le message
de surcharge "Je veux surcharger le code du click sur ce controle".
Que dois-je faire pour afficher uniquement le message de surcharge "Je
veux surcharger le code du click sur ce controle" sans afficher le message
de la classe.
Merci d'avance pour vos contributions.
Bonjour,
J'ai créé un contrôle UserControl1 grace au code suivant :
public partial class UserControl1 : Button
{
public UserControl1()
{
InitializeComponent();
}
private void UserControl1_Click(object sender, EventArgs e)
{
MessageBox.Show("Merci d'avoir cliqué sur le controle
UserControl1");
}
}
Ce contrôle contient une méthode permettant d'afficher le message "Merci
d'avoir cliqué sur le controle UserControl1" lorsqu'on clique dessus.
Tout marche bien lorsque j'ajoute ce contrôle à mes formulaires et que je
clique sur le contrôle, le bon message s'affiche.
Je veux surcharger cette méthode dans un formulaire spécifique. Pour ce
faire je mets le code suivant attaché au clic sur ce contrôle dans mon
formulaire spécifique.
private void userControl11_Click(object sender, EventArgs e)
{
MessageBox.Show("Je veux surcharger le code du click sur ce
controle");
}
Malheureusement à l'exécution, il m'affiche d'abord le message de la
classe "Merci d'avoir cliqué sur le controle UserControl1" puis le message
de surcharge "Je veux surcharger le code du click sur ce controle".
Que dois-je faire pour afficher uniquement le message de surcharge "Je
veux surcharger le code du click sur ce controle" sans afficher le message
de la classe.
Merci d'avance pour vos contributions.
Bonjour,
J'ai créé un contrôle UserControl1 grace au code suivant :
public partial class UserControl1 : Button
{
public UserControl1()
{
InitializeComponent();
}
private void UserControl1_Click(object sender, EventArgs e)
{
MessageBox.Show("Merci d'avoir cliqué sur le controle
UserControl1");
}
}
Ce contrôle contient une méthode permettant d'afficher le message "Merci
d'avoir cliqué sur le controle UserControl1" lorsqu'on clique dessus.
Tout marche bien lorsque j'ajoute ce contrôle à mes formulaires et que je
clique sur le contrôle, le bon message s'affiche.
Je veux surcharger cette méthode dans un formulaire spécifique. Pour ce
faire je mets le code suivant attaché au clic sur ce contrôle dans mon
formulaire spécifique.
private void userControl11_Click(object sender, EventArgs e)
{
MessageBox.Show("Je veux surcharger le code du click sur ce
controle");
}
Malheureusement à l'exécution, il m'affiche d'abord le message de la
classe "Merci d'avoir cliqué sur le controle UserControl1" puis le message
de surcharge "Je veux surcharger le code du click sur ce controle".
Que dois-je faire pour afficher uniquement le message de surcharge "Je
veux surcharger le code du click sur ce controle" sans afficher le message
de la classe.
Merci d'avance pour vos contributions.
Bonjour,
J'ai créé un contrôle UserControl1 grace au code suivant :
public partial class UserControl1 : Button
{
public UserControl1()
{
InitializeComponent();
}
private void UserControl1_Click(object sender, EventArgs e)
{
MessageBox.Show("Merci d'avoir cliqué sur le controle
UserControl1");
}
}
Ce contrôle contient une méthode permettant d'afficher le message "Merci
d'avoir cliqué sur le controle UserControl1" lorsqu'on clique dessus.
Tout marche bien lorsque j'ajoute ce contrôle à mes formulaires et que je
clique sur le contrôle, le bon message s'affiche.
Je veux surcharger cette méthode dans un formulaire spécifique. Pour ce
faire je mets le code suivant attaché au clic sur ce contrôle dans mon
formulaire spécifique.
private void userControl11_Click(object sender, EventArgs e)
{
MessageBox.Show("Je veux surcharger le code du click sur ce
controle");
}
Malheureusement à l'exécution, il m'affiche d'abord le message de la
classe "Merci d'avoir cliqué sur le controle UserControl1" puis le message
de surcharge "Je veux surcharger le code du click sur ce controle".
Que dois-je faire pour afficher uniquement le message de surcharge "Je
veux surcharger le code du click sur ce controle" sans afficher le message
de la classe.
Merci d'avance pour vos contributions.
Bonjour,
J'ai créé un contrôle UserControl1 grace au code suivant :
public partial class UserControl1 : Button
{
public UserControl1()
{
InitializeComponent();
}
private void UserControl1_Click(object sender, EventArgs e)
{
MessageBox.Show("Merci d'avoir cliqué sur le controle
UserControl1");
}
}
Ce contrôle contient une méthode permettant d'afficher le message "Merci
d'avoir cliqué sur le controle UserControl1" lorsqu'on clique dessus.
Tout marche bien lorsque j'ajoute ce contrôle à mes formulaires et que je
clique sur le contrôle, le bon message s'affiche.
Je veux surcharger cette méthode dans un formulaire spécifique. Pour ce
faire je mets le code suivant attaché au clic sur ce contrôle dans mon
formulaire spécifique.
private void userControl11_Click(object sender, EventArgs e)
{
MessageBox.Show("Je veux surcharger le code du click sur ce
controle");
}
Malheureusement à l'exécution, il m'affiche d'abord le message de la
classe "Merci d'avoir cliqué sur le controle UserControl1" puis le message
de surcharge "Je veux surcharger le code du click sur ce controle".
Que dois-je faire pour afficher uniquement le message de surcharge "Je
veux surcharger le code du click sur ce controle" sans afficher le message
de la classe.
Merci d'avance pour vos contributions.
j'ai l'impression que vous partez dans une logique d'heritage pour faire ce
genre de choses... ça, c'etait bon il y'a 20 ans quand on avait rien d'autre.
j'ai l'impression que vous partez dans une logique d'heritage pour faire ce
genre de choses... ça, c'etait bon il y'a 20 ans quand on avait rien d'autre.
j'ai l'impression que vous partez dans une logique d'heritage pour faire ce
genre de choses... ça, c'etait bon il y'a 20 ans quand on avait rien d'autre.
/_Jean BONBEUR_ a exposé/ :j'ai l'impression que vous partez dans une logique d'heritage pour
faire ce genre de choses... ça, c'etait bon il y'a 20 ans quand on
avait rien d'autre.
je pense que votre formulation est maladroite.... l'héritage est plus
que jamais d'actualité dans ce qu'on appelle communément la
programmation orientée objet (POO) que propose C#
/_Jean BONBEUR_ a exposé/ :
j'ai l'impression que vous partez dans une logique d'heritage pour
faire ce genre de choses... ça, c'etait bon il y'a 20 ans quand on
avait rien d'autre.
je pense que votre formulation est maladroite.... l'héritage est plus
que jamais d'actualité dans ce qu'on appelle communément la
programmation orientée objet (POO) que propose C#
/_Jean BONBEUR_ a exposé/ :j'ai l'impression que vous partez dans une logique d'heritage pour
faire ce genre de choses... ça, c'etait bon il y'a 20 ans quand on
avait rien d'autre.
je pense que votre formulation est maladroite.... l'héritage est plus
que jamais d'actualité dans ce qu'on appelle communément la
programmation orientée objet (POO) que propose C#
Bonjour,
Faust wrote:/_Jean BONBEUR_ a exposé/ :j'ai l'impression que vous partez dans une logique d'heritage pour
faire ce genre de choses... ça, c'etait bon il y'a 20 ans quand on
avait rien d'autre.
je pense que votre formulation est maladroite.... l'héritage est plus
que jamais d'actualité dans ce qu'on appelle communément la
programmation orientée objet (POO) que propose C#
Non. L'héritage d'implémentation qui a longtemps été une des mamelles de
l'OOP a montré ses limites en générant des relations statiques entre les
classes au moment de la compilation. Ce qui génère du couplage, problème que
l'on essaie d'éviter comme la peste.
Le polymorphisme basé sur l'héritage d'interfaces est bien plus souple et
permet de gérer de manière dynamique les relations entre classes, produisant
ainsi des designs beaucoup plus efficaces et faciles à maintenir.
Ce qui ne veut pas dire que l'héritage d'implémentation n'est pas utile mais
il doit être remis à sa place et descendu du piédestal sur lequel il a trop
longtemps été placé.
Cordialement.
Bonjour,
Faust wrote:
/_Jean BONBEUR_ a exposé/ :
j'ai l'impression que vous partez dans une logique d'heritage pour
faire ce genre de choses... ça, c'etait bon il y'a 20 ans quand on
avait rien d'autre.
je pense que votre formulation est maladroite.... l'héritage est plus
que jamais d'actualité dans ce qu'on appelle communément la
programmation orientée objet (POO) que propose C#
Non. L'héritage d'implémentation qui a longtemps été une des mamelles de
l'OOP a montré ses limites en générant des relations statiques entre les
classes au moment de la compilation. Ce qui génère du couplage, problème que
l'on essaie d'éviter comme la peste.
Le polymorphisme basé sur l'héritage d'interfaces est bien plus souple et
permet de gérer de manière dynamique les relations entre classes, produisant
ainsi des designs beaucoup plus efficaces et faciles à maintenir.
Ce qui ne veut pas dire que l'héritage d'implémentation n'est pas utile mais
il doit être remis à sa place et descendu du piédestal sur lequel il a trop
longtemps été placé.
Cordialement.
Bonjour,
Faust wrote:/_Jean BONBEUR_ a exposé/ :j'ai l'impression que vous partez dans une logique d'heritage pour
faire ce genre de choses... ça, c'etait bon il y'a 20 ans quand on
avait rien d'autre.
je pense que votre formulation est maladroite.... l'héritage est plus
que jamais d'actualité dans ce qu'on appelle communément la
programmation orientée objet (POO) que propose C#
Non. L'héritage d'implémentation qui a longtemps été une des mamelles de
l'OOP a montré ses limites en générant des relations statiques entre les
classes au moment de la compilation. Ce qui génère du couplage, problème que
l'on essaie d'éviter comme la peste.
Le polymorphisme basé sur l'héritage d'interfaces est bien plus souple et
permet de gérer de manière dynamique les relations entre classes, produisant
ainsi des designs beaucoup plus efficaces et faciles à maintenir.
Ce qui ne veut pas dire que l'héritage d'implémentation n'est pas utile mais
il doit être remis à sa place et descendu du piédestal sur lequel il a trop
longtemps été placé.
Cordialement.
> loin de moi l'idée d'encenser l'héritage d'implémentation... de même, le
polymorphisme par l'usage d'interface est loin d'être la solution miracle:
le polymorphisme d'interface sans l'héritage d'implémentation n'a aucun
intérêt
> loin de moi l'idée d'encenser l'héritage d'implémentation... de même, le
polymorphisme par l'usage d'interface est loin d'être la solution miracle:
le polymorphisme d'interface sans l'héritage d'implémentation n'a aucun
intérêt
> loin de moi l'idée d'encenser l'héritage d'implémentation... de même, le
polymorphisme par l'usage d'interface est loin d'être la solution miracle:
le polymorphisme d'interface sans l'héritage d'implémentation n'a aucun
intérêt
loin de moi l'idée d'encenser l'héritage d'implémentation... de même, le
polymorphisme par l'usage d'interface est loin d'être la solution miracle:
le polymorphisme d'interface sans l'héritage d'implémentation n'a aucun
intérêt
je ne vais pas vous vanter comme une évidence ce que patrick vient de mettre
en lumiere, c'est quelque chose que j'ai découvert avec .Net... un article de
Patrick Smacchia qui traite du sujet, et qui en traite bien :
http://www.dotnetguru.org/articles/dossiers/heritageimpl/FragileBaseClass.htm
désolé d'avoir trollé, c'etait pas mon but. on etait dans un cas de figure
qui tombait pile dans la marmitte, d'ou mon intervention...
loin de moi l'idée d'encenser l'héritage d'implémentation... de même, le
polymorphisme par l'usage d'interface est loin d'être la solution miracle:
le polymorphisme d'interface sans l'héritage d'implémentation n'a aucun
intérêt
je ne vais pas vous vanter comme une évidence ce que patrick vient de mettre
en lumiere, c'est quelque chose que j'ai découvert avec .Net... un article de
Patrick Smacchia qui traite du sujet, et qui en traite bien :
http://www.dotnetguru.org/articles/dossiers/heritageimpl/FragileBaseClass.htm
désolé d'avoir trollé, c'etait pas mon but. on etait dans un cas de figure
qui tombait pile dans la marmitte, d'ou mon intervention...
loin de moi l'idée d'encenser l'héritage d'implémentation... de même, le
polymorphisme par l'usage d'interface est loin d'être la solution miracle:
le polymorphisme d'interface sans l'héritage d'implémentation n'a aucun
intérêt
je ne vais pas vous vanter comme une évidence ce que patrick vient de mettre
en lumiere, c'est quelque chose que j'ai découvert avec .Net... un article de
Patrick Smacchia qui traite du sujet, et qui en traite bien :
http://www.dotnetguru.org/articles/dossiers/heritageimpl/FragileBaseClass.htm
désolé d'avoir trollé, c'etait pas mon but. on etait dans un cas de figure
qui tombait pile dans la marmitte, d'ou mon intervention...
j'intervenais juste pour dire qu'il faut se méfier des raccourcis faciles.
En outre, de nombreuses implémentations des design pattern Gof ne peuvent
se passer de l'héritage d'implémentation (Abstract Factory, Factory,
Prototype, Adapter, Bridge, Chain of responsability, Composite, Observer,
Template Method, Visitor.).
Ces deux arguments montrent bien que OUI, lorsque l'on a constaté que c'est
la moins mauvaise des solutions, on doit utiliser l'héritage d'implémentation.
Ce n'est pas parce que je peux me couper le doigt avec un couteau que je
vais arrêter d'en utiliser ! J'apprend plutôt à m'en servir correctement."
de plus, je ferais juste remarquer que la problématique soulevée en début
de l'article n'existe pas avec certains languages. Je pense notamment à
Delphi qui autorise le mot clé "class of" qui permet de faire exactement
ce qui est suggéré en solution et ce sans utiliser d'interface. Et ça
depuis au moins maintenant 10 ans (ce mot clé existait déjà dans la
version 3 de Delphi sortie, si je ne me trompe pas en 1996)
Je ne dis pas que c'était THE solution, je dis juste que je faisais du
polymorphisme (d'interface ou non du coup puisque c'était avec Delphi)
bien avant l'arrivée de .Net, que les "limites de la POO" étaient imposées
par le language largement diffusé mais au combien loin d'être d'être
parfait (je pense ici au C++) et que mon expérience me permet de dire que
le polymorphisme d'interface (et les interfaces en général) est loin
d'être la réponse à tout.
en problématique de l'article). Elle est peut-être là la limité de la POO:
la compréhension des développeurs de ce vaste "concept".
j'intervenais juste pour dire qu'il faut se méfier des raccourcis faciles.
En outre, de nombreuses implémentations des design pattern Gof ne peuvent
se passer de l'héritage d'implémentation (Abstract Factory, Factory,
Prototype, Adapter, Bridge, Chain of responsability, Composite, Observer,
Template Method, Visitor.).
Ces deux arguments montrent bien que OUI, lorsque l'on a constaté que c'est
la moins mauvaise des solutions, on doit utiliser l'héritage d'implémentation.
Ce n'est pas parce que je peux me couper le doigt avec un couteau que je
vais arrêter d'en utiliser ! J'apprend plutôt à m'en servir correctement."
de plus, je ferais juste remarquer que la problématique soulevée en début
de l'article n'existe pas avec certains languages. Je pense notamment à
Delphi qui autorise le mot clé "class of" qui permet de faire exactement
ce qui est suggéré en solution et ce sans utiliser d'interface. Et ça
depuis au moins maintenant 10 ans (ce mot clé existait déjà dans la
version 3 de Delphi sortie, si je ne me trompe pas en 1996)
Je ne dis pas que c'était THE solution, je dis juste que je faisais du
polymorphisme (d'interface ou non du coup puisque c'était avec Delphi)
bien avant l'arrivée de .Net, que les "limites de la POO" étaient imposées
par le language largement diffusé mais au combien loin d'être d'être
parfait (je pense ici au C++) et que mon expérience me permet de dire que
le polymorphisme d'interface (et les interfaces en général) est loin
d'être la réponse à tout.
en problématique de l'article). Elle est peut-être là la limité de la POO:
la compréhension des développeurs de ce vaste "concept".
j'intervenais juste pour dire qu'il faut se méfier des raccourcis faciles.
En outre, de nombreuses implémentations des design pattern Gof ne peuvent
se passer de l'héritage d'implémentation (Abstract Factory, Factory,
Prototype, Adapter, Bridge, Chain of responsability, Composite, Observer,
Template Method, Visitor.).
Ces deux arguments montrent bien que OUI, lorsque l'on a constaté que c'est
la moins mauvaise des solutions, on doit utiliser l'héritage d'implémentation.
Ce n'est pas parce que je peux me couper le doigt avec un couteau que je
vais arrêter d'en utiliser ! J'apprend plutôt à m'en servir correctement."
de plus, je ferais juste remarquer que la problématique soulevée en début
de l'article n'existe pas avec certains languages. Je pense notamment à
Delphi qui autorise le mot clé "class of" qui permet de faire exactement
ce qui est suggéré en solution et ce sans utiliser d'interface. Et ça
depuis au moins maintenant 10 ans (ce mot clé existait déjà dans la
version 3 de Delphi sortie, si je ne me trompe pas en 1996)
Je ne dis pas que c'était THE solution, je dis juste que je faisais du
polymorphisme (d'interface ou non du coup puisque c'était avec Delphi)
bien avant l'arrivée de .Net, que les "limites de la POO" étaient imposées
par le language largement diffusé mais au combien loin d'être d'être
parfait (je pense ici au C++) et que mon expérience me permet de dire que
le polymorphisme d'interface (et les interfaces en général) est loin
d'être la réponse à tout.
en problématique de l'article). Elle est peut-être là la limité de la POO:
la compréhension des développeurs de ce vaste "concept".
je repete que ça concernais son truc à lui, j'ai beau relire mon post, je
ne vois pas de mise à mort de l'heritage.
Java comme .Net 1.0 et Delphi à l'heure ou il n'y avait pas de genericité
proposaient par exemple une CollectionBase. on pouvait trés bien creer sa
classe MyList , heritiere d'object, de IEnumerable, et de IList, et
l'implanter explicitement au choix avec un ArrayList ou ce qu'on veut...
CollectionBase est un raccourci facile vers la mise en oeuvre d'une
ArrayList, mais en quoi est il vraiment avantageux ? les framework sont
gavés de ce genre d'exemple. mais il y'a certainement des cas ou ça doit
valoir le coup, encore faut il mettre en lumiere la valeur du truc.
en C++, on trouve istream, ostream, iostream, ifstream, ofstream etc
etc... en .Net, on a des Reader, des Writer, des Stream, c'est vachement
plus propre.
le Stream se decline en MemoryStream, FileStream etc... et les Writer sont
typés en fonction de chaque besoin : Xml, Texte, binaire, Crypto... si on
ajoute un type de writer, il n'y aura pas besoin de le decliner à toutes
les sauces pour qu'il tienne compte de chaque type de stream... à ma
petite echelle, moi je vois ça comme une bonne chose...
arf, dans n'importe quel langage, on aurait pu faire ça. les Writer et les
Reader, on aurait pu les avoir en C++.
les abstract class auraient pu remplir à merveille le rôle d'interface.
ça vient des gens et de leur mentalité tout ça... je gratte deux cycles à
la con parceque le compilateur de chez machin genere un code legerement
plus rapide que les autres... tout une époque...
en problématique de l'article). Elle est peut-être là la limité de la
POO: la compréhension des développeurs de ce vaste "concept".
c'est clair ! parfaitement bien dit ! un bon joueur d'echec, sais deplacer
les pieces :)
je repete que ça concernais son truc à lui, j'ai beau relire mon post, je
ne vois pas de mise à mort de l'heritage.
Java comme .Net 1.0 et Delphi à l'heure ou il n'y avait pas de genericité
proposaient par exemple une CollectionBase. on pouvait trés bien creer sa
classe MyList , heritiere d'object, de IEnumerable, et de IList, et
l'implanter explicitement au choix avec un ArrayList ou ce qu'on veut...
CollectionBase est un raccourci facile vers la mise en oeuvre d'une
ArrayList, mais en quoi est il vraiment avantageux ? les framework sont
gavés de ce genre d'exemple. mais il y'a certainement des cas ou ça doit
valoir le coup, encore faut il mettre en lumiere la valeur du truc.
en C++, on trouve istream, ostream, iostream, ifstream, ofstream etc
etc... en .Net, on a des Reader, des Writer, des Stream, c'est vachement
plus propre.
le Stream se decline en MemoryStream, FileStream etc... et les Writer sont
typés en fonction de chaque besoin : Xml, Texte, binaire, Crypto... si on
ajoute un type de writer, il n'y aura pas besoin de le decliner à toutes
les sauces pour qu'il tienne compte de chaque type de stream... à ma
petite echelle, moi je vois ça comme une bonne chose...
arf, dans n'importe quel langage, on aurait pu faire ça. les Writer et les
Reader, on aurait pu les avoir en C++.
les abstract class auraient pu remplir à merveille le rôle d'interface.
ça vient des gens et de leur mentalité tout ça... je gratte deux cycles à
la con parceque le compilateur de chez machin genere un code legerement
plus rapide que les autres... tout une époque...
en problématique de l'article). Elle est peut-être là la limité de la
POO: la compréhension des développeurs de ce vaste "concept".
c'est clair ! parfaitement bien dit ! un bon joueur d'echec, sais deplacer
les pieces :)
je repete que ça concernais son truc à lui, j'ai beau relire mon post, je
ne vois pas de mise à mort de l'heritage.
Java comme .Net 1.0 et Delphi à l'heure ou il n'y avait pas de genericité
proposaient par exemple une CollectionBase. on pouvait trés bien creer sa
classe MyList , heritiere d'object, de IEnumerable, et de IList, et
l'implanter explicitement au choix avec un ArrayList ou ce qu'on veut...
CollectionBase est un raccourci facile vers la mise en oeuvre d'une
ArrayList, mais en quoi est il vraiment avantageux ? les framework sont
gavés de ce genre d'exemple. mais il y'a certainement des cas ou ça doit
valoir le coup, encore faut il mettre en lumiere la valeur du truc.
en C++, on trouve istream, ostream, iostream, ifstream, ofstream etc
etc... en .Net, on a des Reader, des Writer, des Stream, c'est vachement
plus propre.
le Stream se decline en MemoryStream, FileStream etc... et les Writer sont
typés en fonction de chaque besoin : Xml, Texte, binaire, Crypto... si on
ajoute un type de writer, il n'y aura pas besoin de le decliner à toutes
les sauces pour qu'il tienne compte de chaque type de stream... à ma
petite echelle, moi je vois ça comme une bonne chose...
arf, dans n'importe quel langage, on aurait pu faire ça. les Writer et les
Reader, on aurait pu les avoir en C++.
les abstract class auraient pu remplir à merveille le rôle d'interface.
ça vient des gens et de leur mentalité tout ça... je gratte deux cycles à
la con parceque le compilateur de chez machin genere un code legerement
plus rapide que les autres... tout une époque...
en problématique de l'article). Elle est peut-être là la limité de la
POO: la compréhension des développeurs de ce vaste "concept".
c'est clair ! parfaitement bien dit ! un bon joueur d'echec, sais deplacer
les pieces :)