On Wed, 6 Apr 2011 15:51:26 +0200 Tony Chemit <chemit@codelutin.com> wrote:
L'autre chose qui me fait peur, est qu'un jour on souhaite reutiliser un bout d'un programme final a la facon d'une librairie et qu'on y arrive pas parce qu'il a surchargé AppConfig. (on est d'accord que pour les libs la surcharge est a proscrire).
Peux-tu redonner un exemple qui fait que ça ne marcherait pas car là je me souviens plus du problème ?
On a une librairie A qui a un AConfig qui herite de ApplicationConfig On a une librairie B qui a un BConfig qui herite de ApplicationConfig On a une application C qui a un CConfig qui herite de ApplicationConfig C utilise A et B Si pour l'init de A on a la methodes: - init(AConfig config) Si pour l'init de B on a la methodes: - init(BConfig config) Lorqsu'on va venir avec notre CConfig qui vient de l'application, il ne rentrera pas dans le AConfig ni le BConfig. AConfig n'est pas assignable a BConfig qui n'est pas assignable a CConfig. Bien sur ils sont tous assignable a ApplicationConfig, mais il n'y en a nul part. D'ou ma volonté de n'utiliser que des ApplicationConfig pour que tous ce qui est ecrit en l'utilisant soit compatible entre eux. donc pour les libs c'est obligatoire de n'utiliser que ApplicationConfig (sinon elles sont difficilement reutilisable, a moins de passer a chaque fois par la creation d'un nouvel objet de config specifique a la lib avec tous les risques que la duplication entraine) et la perte de temps de creation d'objet. Pour les applications c'est moins vrai, mais si on peut faire uniforme, je prefere autant. Et comme ca on est aussi a l'abri de probleme d'incompatibilite entre application que l'on voudrait utiliser entre elle. Est-ce que je suis plus clair ? -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com