Pseudocode
Cet exemple illustre comment la méthode Factory peut être utilisée pour créer des éléments dinterface utilisateur multiplateformes sans coupler le code client à des classes dinterface utilisateur concrètes.
Exemple de dialogue multiplateforme.
La classe de dialogue de base utilise différents éléments dinterface utilisateur pour rendre sa fenêtre. Sous divers systèmes dexploitation, ces éléments peuvent sembler un peu différents, mais ils doivent toujours se comporter de manière cohérente. Un bouton sous Windows est toujours un bouton sous Linux.
Lorsque la méthode dusine entre en jeu, vous navez pas besoin de réécrire la logique de la boîte de dialogue pour chaque système dexploitation. Si nous déclarons une méthode de fabrique qui produit des boutons à lintérieur de la classe de dialogue de base, nous pouvons plus tard créer une sous-classe de dialogue qui renvoie des boutons de style Windows à partir de la méthode de fabrique. La sous-classe hérite alors de la plupart du code de la boîte de dialogue de la classe de base, mais, grâce à la méthode de fabrique, peut rendre des boutons ressemblant à Windows à lécran.
Pour que ce modèle fonctionne, la classe de boîte de dialogue de base doit travailler avec des boutons abstraits: une classe de base ou une interface que suivent tous les boutons concrets. De cette façon, le code de la boîte de dialogue reste fonctionnel, quel que soit le type de bouton avec lequel il fonctionne.
Bien sûr, vous pouvez également appliquer cette approche à dautres éléments de linterface utilisateur. Cependant, à chaque nouvelle méthode de fabrique que vous ajoutez à la boîte de dialogue, vous vous rapprochez du modèle Abstract Factory. Nayez crainte, nous parlerons de ce modèle plus tard.
// The creator class declares the factory method that must// return an object of a product class. The creator"s subclasses// usually provide the implementation of this method.class Dialog is // The creator may also provide some default implementation // of the factory method. abstract method createButton():Button // Note that, despite its name, the creator"s primary // responsibility isn"t creating products. It usually // contains some core business logic that relies on product // objects returned by the factory method. Subclasses can // indirectly change that business logic by overriding the // factory method and returning a different type of product // from it. method render() is // Call the factory method to create a product object. Button okButton = createButton() // Now use the product. okButton.onClick(closeDialog) okButton.render()// Concrete creators override the factory method to change the// resulting product"s type.class WindowsDialog extends Dialog is method createButton():Button is return new WindowsButton()class WebDialog extends Dialog is method createButton():Button is return new HTMLButton()// The product interface declares the operations that all// concrete products must implement.interface Button is method render() method onClick(f)// Concrete products provide various implementations of the// product interface.class WindowsButton implements Button is method render(a, b) is // Render a button in Windows style. method onClick(f) is // Bind a native OS click event.class HTMLButton implements Button is method render(a, b) is // Return an HTML representation of a button. method onClick(f) is // Bind a web browser click event.class Application is field dialog: Dialog // The application picks a creator"s type depending on the // current configuration or environment settings. method initialize() is config = readApplicationConfigFile() if (config.OS == "Windows") then dialog = new WindowsDialog() else if (config.OS == "Web") then dialog = new WebDialog() else throw new Exception("Error! Unknown operating system.") // The client code works with an instance of a concrete // creator, albeit through its base interface. As long as // the client keeps working with the creator via the base // interface, you can pass it any creator"s subclass. method main() is this.initialize() dialog.render()