On Wed, 6 Apr 2011 17:34:17 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
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.
Ok ton exemple me parle. Merci.
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.
oui je vois bien ton point de vue et je le partage, tout en nuançant sur le besoin réelle dans une application finale qui peut-être très couplée avec sa configuration et être bien plus en interaction avec celle-ci. Dans ce cadre ApplicationConfig n'est pas auto-suffisant car non JavaBeans et donc non écoutable :( Et en plus se dire qu'une application finale va peut-être un jour devenir une librairie c'est tiré par les cheveux, si cela doit arriver, on fera alors le nécessaire pour dégager un module de l'application finale (ce qui devrait pas être bien dure si c'est en multi-module...). On en reparlera un jeudi soir si tu veux :)
Est-ce que je suis plus clair ?
Ah oui ;) merci -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com