Trop de suffixes de motifs & # 8220; & # 8221; - odeur de design?

Question

Je viens juste de créer une classe appelée "InstructionBuilderFactoryMapFactory". C’est 4 "suffixes de modèle". sur une classe. Cela m'a immédiatement rappelé ceci:

http://www.jroller.com/landers/entry/the_design_pattern_fernade_facade_pattern

Est-ce une odeur de design? Devrais-je imposer une limite à ce nombre?

Je sais que certains programmeurs ont des règles similaires pour d’autres choses (par exemple, pas plus de N niveaux d’indirection de pointeur dans C.)

Tous les cours me paraissent nécessaires. J'ai une carte (fixe) des chaînes aux usines - quelque chose que je fais tout le temps. La liste est de plus en plus longue et je souhaite la sortir du constructeur de la classe qui utilise les constructeurs (créés par les usines obtenues à partir de la carte ...). Et comme d'habitude, j'évite les Singletons.

Answer 1

Je le vois comme une odeur de design. Cela me fera penser si tous ces niveaux d'abstraction tirent suffisamment de poids.

Je ne vois pas pourquoi vous vouliez nommer une classe 'InstructionBuilderFactoryMapFactory'? Y a-t-il d'autres types d'usines - quelque chose qui ne crée pas d'InstructionBuilderFactoryMap? Ou existe-t-il d’autres types d’InstructionBuildersFactories dont il a besoin d’être cartographié?

Telles sont les questions auxquelles vous devriez réfléchir lorsque vous commencez à créer des classes comme celles-ci. Il est possible de simplement regrouper toutes ces différentes usines en une seule, puis de fournir des méthodes distinctes pour créer des usines. Il est également possible de simplement placer ces usines dans un emballage différent et de leur donner un nom plus succinct. Pensez à d'autres moyens de le faire.

Answer 2

Voici un bon conseil: Votre API publique de classe (et son nom) doit révéler une intention et non une implémentation. En tant que client, je ne me soucie pas de savoir si vous avez implémenté le modèle de générateur ou le modèle d'usine.

Non seulement le nom de la classe a l'air mauvais, mais il ne dit rien non plus sur ce qu'il fait. Son nom est basé sur sa mise en œuvre et sa structure interne.

J'utilise rarement un nom de modèle dans une classe, à l'exception de (parfois) Factories.

Modifier:

Vous avez trouvé un article intéressant sur l'attribution de nom à Coder Horror, consultez-le. !

Answer 3

De nombreux motifs dans un nom de classe sont très certainement une odeur, mais une odeur n'est pas un indicateur précis. C'est un signal pour "s'arrêter une minute et repenser le design". Souvent, lorsque vous vous asseyez et pensez qu'une solution plus claire devient évidente. Parfois, en raison de contraintes (technique / temps / main-d'œuvre / etc.), l'odeur doit être ignorée pour l'instant.

En ce qui concerne l'exemple spécifique, je ne pense pas que les suggestions de la galerie des cacahuètes soient une bonne idée sans davantage de contexte.

Answer 4

J'ai pensé la même chose. Dans mon cas, l'abondance d'usines est causée par "construire pour la testabilité". Par exemple, j'ai un constructeur comme celui-ci:

ParserBuilderFactoryImpl(ParserFactory psF) {
...
}

Ici, j’ai un analyseur syntaxique - la classe ultime dont j’ai besoin. L'analyseur est construit en appelant des méthodes sur un générateur. Les constructeurs (un nouveau pour chaque analyseur à construire) sont obtenus à partir de la fabrique de constructeurs.

Maintenant, quel est le h..l est ParserFactory? Ah, je suis content que vous ayez demandé! Afin de tester l'implémentation du générateur d'analyseur, je dois appeler sa méthode, puis voir quel type d'analyseur a été créé. La seule façon de le faire sans interrompre l’incapsulation de la classe d’analyseur que le constructeur est en train de créer est de placer un point d’interception juste avant la création de l’analyseur, pour voir ce qui se passe dans son constructeur. D'où ParserFactory. C’est juste un moyen pour moi d’observer dans un test unitaire ce qui est passé au constructeur d’un analyseur.

Je ne sais pas trop comment résoudre ce problème, mais j’ai le sentiment que nous ferions mieux de faire circuler des classes plutôt que des usines, et Java ferait mieux de disposer de méthodes de classe appropriées plutôt que de membres statiques.