Je suis en ce moment confronté à une interrogation qui revient de
temps en temps.
A partir de la class TEdit de OWL, qui représente une boîte d'édition
(= une endroit où l'utilisateur peut taper du texte), j'ai dérivé une
classe EditTime, qui n'accepte que des entrées sous la forme
hh:mm:ss.xxx. Il s'agit d'un code assez court (~70 lignes).
Je dois maintenant faire la même chose avec une date. Et là, j'ai deux
choix devant moi :
- soit faire le code de la nouvelle classe, en m'aidant de celui
la classe existante, mais totalement indépendant
- soit refondre la classe existante pour la rendre plus
générique, la transformer en classe abstraite, et faire dériver
EditTime et EditDate de cette classe abstraite
La deuxième solution est sans doute celle préconisée par les bons
usages, à cause des possibilités d'évolution, mais :
- la première solution est nettement plus rapide
- la classe EditTime existant est à la fois simple et stable,
d'où peu d'évolution possible, d'autant que si je veux faire quelque
chose de vaguement ressemblant, j'ai plus vite fait de pondre un
nouveau code -- il ne s'agit de d'une dizaine de lignes de code.
Voilà voilà, j'aimerais avoir vos avis, vos expériences, etc.
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
kanze
Fabien LE LEZ wrote in message news:...
Je suis en ce moment confronté à une interrogation qui revient de temps en temps.
A partir de la class TEdit de OWL, qui représente une boîte d'édition (= une endroit où l'utilisateur peut taper du texte), j'ai dérivé une classe EditTime, qui n'accepte que des entrées sous la forme hh:mm:ss.xxx. Il s'agit d'un code assez court (~70 lignes). Je dois maintenant faire la même chose avec une date. Et là, j'ai deux choix devant moi : - soit faire le code de la nouvelle classe, en m'aidant de celui la classe existante, mais totalement indépendant - soit refondre la classe existante pour la rendre plus générique, la transformer en classe abstraite, et faire dériver EditTime et EditDate de cette classe abstraite
La deuxième solution est sans doute celle préconisée par les bons usages, à cause des possibilités d'évolution, mais : - la première solution est nettement plus rapide - la classe EditTime existant est à la fois simple et stable, d'où peu d'évolution possible, d'autant que si je veux faire quelque chose de vaguement ressemblant, j'ai plus vite fait de pondre un nouveau code -- il ne s'agit de d'une dizaine de lignes de code.
D'où tiens-tu que la deuxième solution est celle préconisée ? La généricité, c'est comme l'optimisation -- il ne faut jamais la faire trop tôt. En fait, *si* tu trouves, et *après* que tu as trouvé qu'il y a beaucoup en commun entre plusieurs de ces classes, tu peux faire du refactoring.
Et je doute qu'une classe de base commune soit la bonne solution pour la refactoring. Une classe de base commune indique, en général, une interface commune et une substitutabilité. Je verrais plutôt un délégué pour la partie de l'implémentation commune. (En passant, dans ton cas précis, je crois que le délégué est tout fait : boost::regex.)
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<efcnvvg2ssl0cvb1ab5v7d0e5o3j57uuov@4ax.com>...
Je suis en ce moment confronté à une interrogation qui revient de
temps en temps.
A partir de la class TEdit de OWL, qui représente une boîte d'édition
(= une endroit où l'utilisateur peut taper du texte), j'ai dérivé une
classe EditTime, qui n'accepte que des entrées sous la forme
hh:mm:ss.xxx. Il s'agit d'un code assez court (~70 lignes). Je dois
maintenant faire la même chose avec une date. Et là, j'ai deux choix
devant moi :
- soit faire le code de la nouvelle classe, en m'aidant de celui
la classe existante, mais totalement indépendant
- soit refondre la classe existante pour la rendre plus
générique, la transformer en classe abstraite, et faire dériver
EditTime et EditDate de cette classe abstraite
La deuxième solution est sans doute celle préconisée par les bons
usages, à cause des possibilités d'évolution, mais :
- la première solution est nettement plus rapide
- la classe EditTime existant est à la fois simple et stable,
d'où peu d'évolution possible, d'autant que si je veux faire quelque
chose de vaguement ressemblant, j'ai plus vite fait de pondre un
nouveau code -- il ne s'agit de d'une dizaine de lignes de code.
D'où tiens-tu que la deuxième solution est celle préconisée ? La
généricité, c'est comme l'optimisation -- il ne faut jamais la faire
trop tôt. En fait, *si* tu trouves, et *après* que tu as trouvé qu'il y
a beaucoup en commun entre plusieurs de ces classes, tu peux faire du
refactoring.
Et je doute qu'une classe de base commune soit la bonne solution pour la
refactoring. Une classe de base commune indique, en général, une
interface commune et une substitutabilité. Je verrais plutôt un délégué
pour la partie de l'implémentation commune. (En passant, dans ton cas
précis, je crois que le délégué est tout fait : boost::regex.)
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Je suis en ce moment confronté à une interrogation qui revient de temps en temps.
A partir de la class TEdit de OWL, qui représente une boîte d'édition (= une endroit où l'utilisateur peut taper du texte), j'ai dérivé une classe EditTime, qui n'accepte que des entrées sous la forme hh:mm:ss.xxx. Il s'agit d'un code assez court (~70 lignes). Je dois maintenant faire la même chose avec une date. Et là, j'ai deux choix devant moi : - soit faire le code de la nouvelle classe, en m'aidant de celui la classe existante, mais totalement indépendant - soit refondre la classe existante pour la rendre plus générique, la transformer en classe abstraite, et faire dériver EditTime et EditDate de cette classe abstraite
La deuxième solution est sans doute celle préconisée par les bons usages, à cause des possibilités d'évolution, mais : - la première solution est nettement plus rapide - la classe EditTime existant est à la fois simple et stable, d'où peu d'évolution possible, d'autant que si je veux faire quelque chose de vaguement ressemblant, j'ai plus vite fait de pondre un nouveau code -- il ne s'agit de d'une dizaine de lignes de code.
D'où tiens-tu que la deuxième solution est celle préconisée ? La généricité, c'est comme l'optimisation -- il ne faut jamais la faire trop tôt. En fait, *si* tu trouves, et *après* que tu as trouvé qu'il y a beaucoup en commun entre plusieurs de ces classes, tu peux faire du refactoring.
Et je doute qu'une classe de base commune soit la bonne solution pour la refactoring. Une classe de base commune indique, en général, une interface commune et une substitutabilité. Je verrais plutôt un délégué pour la partie de l'implémentation commune. (En passant, dans ton cas précis, je crois que le délégué est tout fait : boost::regex.)
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Jean-Marc Bourguet
writes:
Fabien LE LEZ wrote in message news:...
Je suis en ce moment confronté à une interrogation qui revient de temps en temps.
A partir de la class TEdit de OWL, qui représente une boîte d'édition (= une endroit où l'utilisateur peut taper du texte), j'ai dérivé une classe EditTime, qui n'accepte que des entrées sous la forme hh:mm:ss.xxx. Il s'agit d'un code assez court (~70 lignes). Je dois maintenant faire la même chose avec une date. Et là, j'ai deux choix devant moi : - soit faire le code de la nouvelle classe, en m'aidant de celui la classe existante, mais totalement indépendant - soit refondre la classe existante pour la rendre plus générique, la transformer en classe abstraite, et faire dériver EditTime et EditDate de cette classe abstraite
La deuxième solution est sans doute celle préconisée par les bons usages, à cause des possibilités d'évolution, mais : - la première solution est nettement plus rapide - la classe EditTime existant est à la fois simple et stable, d'où peu d'évolution possible, d'autant que si je veux faire quelque chose de vaguement ressemblant, j'ai plus vite fait de pondre un nouveau code -- il ne s'agit de d'une dizaine de lignes de code.
D'où tiens-tu que la deuxième solution est celle préconisée ? La généricité, c'est comme l'optimisation -- il ne faut jamais la faire trop tôt. En fait, *si* tu trouves, et *après* que tu as trouvé qu'il y a beaucoup en commun entre plusieurs de ces classes, tu peux faire du refactoring.
Et je doute qu'une classe de base commune soit la bonne solution pour la refactoring. Une classe de base commune indique, en général, une interface commune et une substitutabilité. Je verrais plutôt un délégué pour la partie de l'implémentation commune. (En passant, dans ton cas précis, je crois que le délégué est tout fait : boost::regex.)
Si j'ai bonne memoire -- du temps ou je faisais du Pascal -- il y avait un delegue du genre TValidator prevu pour ca... n'a-t'il pas ete transpose en C++?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
kanze@gabi-soft.fr writes:
Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<efcnvvg2ssl0cvb1ab5v7d0e5o3j57uuov@4ax.com>...
Je suis en ce moment confronté à une interrogation qui revient de
temps en temps.
A partir de la class TEdit de OWL, qui représente une boîte d'édition
(= une endroit où l'utilisateur peut taper du texte), j'ai dérivé une
classe EditTime, qui n'accepte que des entrées sous la forme
hh:mm:ss.xxx. Il s'agit d'un code assez court (~70 lignes). Je dois
maintenant faire la même chose avec une date. Et là, j'ai deux choix
devant moi :
- soit faire le code de la nouvelle classe, en m'aidant de celui
la classe existante, mais totalement indépendant
- soit refondre la classe existante pour la rendre plus
générique, la transformer en classe abstraite, et faire dériver
EditTime et EditDate de cette classe abstraite
La deuxième solution est sans doute celle préconisée par les bons
usages, à cause des possibilités d'évolution, mais :
- la première solution est nettement plus rapide
- la classe EditTime existant est à la fois simple et stable,
d'où peu d'évolution possible, d'autant que si je veux faire quelque
chose de vaguement ressemblant, j'ai plus vite fait de pondre un
nouveau code -- il ne s'agit de d'une dizaine de lignes de code.
D'où tiens-tu que la deuxième solution est celle préconisée ? La
généricité, c'est comme l'optimisation -- il ne faut jamais la faire
trop tôt. En fait, *si* tu trouves, et *après* que tu as trouvé qu'il y
a beaucoup en commun entre plusieurs de ces classes, tu peux faire du
refactoring.
Et je doute qu'une classe de base commune soit la bonne solution pour la
refactoring. Une classe de base commune indique, en général, une
interface commune et une substitutabilité. Je verrais plutôt un délégué
pour la partie de l'implémentation commune. (En passant, dans ton cas
précis, je crois que le délégué est tout fait : boost::regex.)
Si j'ai bonne memoire -- du temps ou je faisais du Pascal -- il y
avait un delegue du genre TValidator prevu pour ca... n'a-t'il pas ete
transpose en C++?
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je suis en ce moment confronté à une interrogation qui revient de temps en temps.
A partir de la class TEdit de OWL, qui représente une boîte d'édition (= une endroit où l'utilisateur peut taper du texte), j'ai dérivé une classe EditTime, qui n'accepte que des entrées sous la forme hh:mm:ss.xxx. Il s'agit d'un code assez court (~70 lignes). Je dois maintenant faire la même chose avec une date. Et là, j'ai deux choix devant moi : - soit faire le code de la nouvelle classe, en m'aidant de celui la classe existante, mais totalement indépendant - soit refondre la classe existante pour la rendre plus générique, la transformer en classe abstraite, et faire dériver EditTime et EditDate de cette classe abstraite
La deuxième solution est sans doute celle préconisée par les bons usages, à cause des possibilités d'évolution, mais : - la première solution est nettement plus rapide - la classe EditTime existant est à la fois simple et stable, d'où peu d'évolution possible, d'autant que si je veux faire quelque chose de vaguement ressemblant, j'ai plus vite fait de pondre un nouveau code -- il ne s'agit de d'une dizaine de lignes de code.
D'où tiens-tu que la deuxième solution est celle préconisée ? La généricité, c'est comme l'optimisation -- il ne faut jamais la faire trop tôt. En fait, *si* tu trouves, et *après* que tu as trouvé qu'il y a beaucoup en commun entre plusieurs de ces classes, tu peux faire du refactoring.
Et je doute qu'une classe de base commune soit la bonne solution pour la refactoring. Une classe de base commune indique, en général, une interface commune et une substitutabilité. Je verrais plutôt un délégué pour la partie de l'implémentation commune. (En passant, dans ton cas précis, je crois que le délégué est tout fait : boost::regex.)
Si j'ai bonne memoire -- du temps ou je faisais du Pascal -- il y avait un delegue du genre TValidator prevu pour ca... n'a-t'il pas ete transpose en C++?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
