Pseudocódigo
Este exemplo ilustra como o Método de fábrica pode ser usado para criar elementos de interface do usuário de plataforma cruzada sem acoplar o código do cliente a classes de interface de usuário concretas.
O exemplo de diálogo de plataforma cruzada.
A classe de diálogo base usa diferentes elementos de IU para renderizar sua janela. Em vários sistemas operacionais, esses elementos podem parecer um pouco diferentes, mas ainda assim devem se comportar de maneira consistente. Um botão no Windows ainda é um botão no Linux.
Quando o método de fábrica entra em ação, você não precisa reescrever a lógica da caixa de diálogo para cada sistema operacional. Se declararmos um método de fábrica que produz botões dentro da classe de diálogo base, podemos criar posteriormente uma subclasse de diálogo que retorna botões no estilo do Windows do método de fábrica. A subclasse então herda a maior parte do código da caixa de diálogo da classe base, mas, graças ao método de fábrica, pode renderizar botões com aparência de Windows na tela.
Para que esse padrão funcione, a classe de diálogo base deve trabalhar com botões abstratos: uma classe base ou uma interface que todos os botões concretos seguem. Desta forma, o código da caixa de diálogo permanece funcional, qualquer que seja o tipo de botão com que trabalha.
Claro, você também pode aplicar essa abordagem a outros elementos da IU. No entanto, com cada novo método de fábrica adicionado à caixa de diálogo, você se aproxima do padrão Abstract Factory. Não tenha medo, falaremos sobre esse padrão mais tarde.
// 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()