Pseudocódigo
Este ejemplo ilustra cómo se puede usar el método de fábrica para crear elementos de interfaz de usuario multiplataforma sin acoplar el código del cliente a clases de interfaz de usuario concretas.
El ejemplo de diálogo multiplataforma.
La clase de diálogo base usa diferentes elementos de la interfaz de usuario para representar su ventana. En varios sistemas operativos, estos elementos pueden verse un poco diferentes, pero aún así deberían comportarse de manera coherente. Un botón en Windows sigue siendo un botón en Linux.
Cuando el método de fábrica entra en juego, no es necesario reescribir la lógica del diálogo para cada sistema operativo. Si declaramos un método de fábrica que produce botones dentro de la clase de diálogo base, más tarde podemos crear una subclase de diálogo que devuelva botones con estilo de Windows del método de fábrica. La subclase hereda la mayor parte del código del cuadro de diálogo de la clase base, pero, gracias al método de fábrica, puede representar botones con aspecto de Windows en la pantalla.
Para que este patrón funcione, la clase de diálogo base debe trabajar con botones abstractos: una clase base o una interfaz que siguen todos los botones concretos. De esta forma, el código del cuadro de diálogo sigue siendo funcional, independientemente del tipo de botones con el que funcione.
Por supuesto, también puede aplicar este enfoque a otros elementos de la interfaz de usuario. Sin embargo, con cada nuevo método de fábrica que agrega al cuadro de diálogo, se acerca al patrón Abstract Factory. No temas, hablaremos de este patrón más adelante.
// 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()