Pseudocodice
Questo esempio illustra come utilizzare il Metodo Factory per creare elementi dellinterfaccia utente multipiattaforma senza accoppiare il codice client a classi dellinterfaccia utente concrete.
Lesempio di dialogo multipiattaforma.
La classe di dialogo di base utilizza diversi elementi dellinterfaccia utente per visualizzare la sua finestra. In vari sistemi operativi, questi elementi possono apparire leggermente diversi, ma dovrebbero comunque comportarsi in modo coerente. Un pulsante in Windows è ancora un pulsante in Linux.
Quando il metodo di fabbrica entra in gioco, non è necessario riscrivere la logica della finestra di dialogo per ogni sistema operativo. Se dichiariamo un metodo factory che produce pulsanti allinterno della classe dialog di base, possiamo successivamente creare una sottoclasse dialog che restituisce pulsanti in stile Windows dal metodo factory. La sottoclasse eredita quindi la maggior parte del codice della finestra di dialogo dalla classe di base, ma, grazie al metodo factory, può visualizzare sullo schermo pulsanti dallaspetto di Windows.
Affinché questo modello funzioni, la classe di dialogo di base deve lavorare con pulsanti astratti: una classe base o uninterfaccia seguita da tutti i pulsanti concreti. In questo modo il codice della finestra di dialogo rimane funzionale, qualunque sia il tipo di pulsanti con cui funziona.
Naturalmente, puoi applicare questo approccio anche ad altri elementi dellinterfaccia utente. Tuttavia, con ogni nuovo metodo factory che aggiungi alla finestra di dialogo, ti avvicini al pattern Abstract Factory. Non temere, parleremo di questo schema più tardi.
// 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()