Comment dois-je comprendre la motivation de l'usine abstraite?

Question

De Design Pattern par GoF

RÉSUMÉ FACTORY

intention

fournir une interface pour la création de familles d'objets liés ou dépendants sans spécifier leurs classes concrètes.

Motivation

Tenir compte une boîte à outils d'interface utilisateur qui prend en charge plusieurs look and feel normes, telles que Motif et Presentation Manager. Différent look-and-feels définit différentes apparences et comportements pour l'utilisateur interface "widgets" comme les barres de défilement, les fenêtres et les boutons. Pour être portable par rapport aux normes de look-and-feel, une application ne devrait pas coder en dur ses widgets pour un aspect particulier. L'instanciation classes de widgets spécifiques à l'aspect et à la sensation dans l'application rend difficile la modification ultérieure de l'aspect et de la convivialité.

Nous pouvons résoudre ce problème en définissant une classe abstraite WidgetFactory qui déclare une interface pour créer chaque type de widget de base. Il existe également une classe abstraite pour chaque type de widget, et les sous-classes de béton implémente des widgets pour des normes spécifiques de style et de convivialité . L'interface de WidgetFactory a une opération qui renvoie un nouvel objet de widget pour chaque classe de widget abstrait. Les clients appellent ces opérations pour obtenir des instances de widget, mais les clients ne connaissent pas les classes concrètes qu'ils utilisent. Ainsi, les clients restent indépendants du .

Je me demandais ce que signifient les suivants signifient:

Pour être portable sur les normes look-and-feel, une application ne doit pas coder en dur ses widgets pour un look particulier et se sentir .

et

instanciation cours look-and-feel spécifiques des widgets dans l'application rend difficile de changer le look and feel plus tard.

En particulier, sans utiliser une classe de fabrique abstraite, à quoi ressemble le code et pourquoi est-il mauvais? Merci.

Answer 1

Quand quelque chose dans le code demande un widget (disons fenêtre), not to hardcode signifie que vous ne devriez pas faire ceci:

var window = new DesktopWindow() 

On peut supposer que vous créer des fenêtres dans beaucoup d'endroits, de sorte que vous » Disons, 100 de ces créations de fenêtres. Si vous avez fait ce qui précède, vous avez codé en dur votre application pour avoir des fenêtres de bureau partout. Ensuite, si vous voulez avoir une version mobile (ou un autre regard), vous devrez modifier les 100 endroits pour faire quelque chose comme ceci:

if(environment.IsMobile){ 
    window = new MobileWindow(); 
} else { 
    window = new DesktopWindow(); 
} 

La logique de la création de la fenêtre se complique, plus et plus grand le code ci-dessus pourrait devenir. Vous allez vous retrouver avec beaucoup de code dupliqué qui fait la même chose, ce qui le rend difficile à maintenir. C'est ce que signifie makes it hard to change look and feel later.

Avec l'usine abstraite votre code ne se soucient pas de ce que la fenêtre il obtient:

et l'usine sait réellement quelle fenêtre pour revenir en fonction du contexte. L'appelant utilise simplement l'interface commune IWindow pour atteindre ses objectifs. Factory simplifie le code en conservant la logique de création en un seul endroit et facilite l'ajout de nouveaux types (apparence et sensations) Window.