Pseudocode
Dieses Beispiel zeigt, wie die Factory-Methode zum Erstellen plattformübergreifender UI-Elemente verwendet werden kann, ohne den Client-Code an konkrete UI-Klassen zu koppeln.
Das plattformübergreifende Dialogbeispiel.
Die Basisdialogklasse verwendet verschiedene UI-Elemente, um ihr Fenster zu rendern. Unter verschiedenen Betriebssystemen sehen diese Elemente möglicherweise etwas anders aus, sollten sich jedoch konsistent verhalten. Eine Schaltfläche in Windows ist unter Linux immer noch eine Schaltfläche.
Wenn die Factory-Methode zum Einsatz kommt, müssen Sie die Logik des Dialogfelds nicht für jedes Betriebssystem neu schreiben. Wenn wir eine Factory-Methode deklarieren, die Schaltflächen innerhalb der Basisdialogklasse erzeugt, können wir später eine Dialogunterklasse erstellen, die Schaltflächen im Windows-Stil von der Factory-Methode zurückgibt. Die Unterklasse erbt dann den größten Teil des Dialogcodes von der Basisklasse, kann jedoch dank der Factory-Methode Windows-aussehende Schaltflächen auf dem Bildschirm rendern.
Damit dieses Muster funktioniert, muss die Basisdialogklasse Arbeiten mit abstrakten Schaltflächen: Eine Basisklasse oder eine Schnittstelle, der alle konkreten Schaltflächen folgen. Auf diese Weise bleibt der Code des Dialogfelds funktionsfähig, unabhängig davon, mit welcher Art von Schaltflächen er arbeitet.
Natürlich können Sie diesen Ansatz auch auf andere Benutzeroberflächenelemente anwenden. Mit jeder neuen Factory-Methode, die Sie dem Dialogfeld hinzufügen, nähern Sie sich jedoch dem Abstract Factory-Muster. Fürchte dich nicht, wir werden später über dieses Muster sprechen.
// 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()