Besoin d'arguments pour utiliser des factories

Je suis actuellement en mission chez un client qui a une application très "legacy". L'architecture gravite autour de deux seuls objets (enormes) qui centralisent tout ce qui est client-spécifique (voire bien plus). Une classe AbstractClient qui est étendu pour chaque client. Bien évidemment ces classes sont énormes. De plus, souvent on ne fait même pas appel à ces classes pour "modifier" le comportement mais on se sert de if et de switch.

Alors j'ai proposé d'utiliser des patterns de type factories. Et mes collègues sont très intéressés. Par contre ils s'inquiètent de ne pas savoir où trouver toutes les choses à modifier lorsqu'ils auront besoin d'implémenter un nouveau client (ici un nouveau client veut forcément dire pas mal de code à produire, et la méthode est : copier un client existant qui ressemble le plus au nouveau client). En effet si on distribue des factories un peu partout dans le code, près de là où il y en aura besoin, ils ne sauront pas les retrouver pour se poser la question s'il faut les modifier. Ils disent :

"OK, à condition que ce soit l'objet Client qui joue le rôle du factory". Donc pour tous les besoins de l'application.

De mon point de vue, c'est néfaste car

• Ca rallonge encore plus ces classes
• Ca rend des objets visibles à toute l'application
• Ca crée de la duplication, car chaque client varie peu
• Et sûrement des choses que j'oublie

J'ai répondu que si on rassemble les factories dans leurs "domaines" respectives on pourrait se limiter à moins de 10 endroits et ce serait pas trop difficile. Mais cet argument n'a pas l'air de les satisfaire.

J'ai besoin d'aide pour les convaincre.

Merci d'avance!
Johan