Factory Method

Introdução aos Padrões de Criação: Construindo Labirintos

• GoF classifica os padrões em Padrões de Criação, Estruturais e de Comportamento
• Padrões de criação abstraem o processo de instanciação de objetos
• Usaremos a construção de labirintos para um jogo via computador para mostrar alguns padrões de criação
  • Ignoraremos muitos detalhes do labirinto (o que pode estar no labirinto, os jogadores, etc.)
  • Foco na criação dos labirintos
• Um labirinto é um conjunto de salas
  • Uma sala conhece seus quatro vizinhos
  • Vizinhos podem ser outra sala, uma parede ou uma porta para outra sala
• As classes importantes são Sala, Porta e Parede
  • Só trataremos as partes das classes que interessam para a criação do labirinto
• O diagrama de classes segue abaixo (em UML)
  • Se precisar de um resumo de UML, ver aqui

• Um diagrama de objetos segue para um pequeno labirinto

• Cada sala tem quatro vizinhos
  • Usamos norte, sul, leste, oeste para referenciá-los
• A interface ElementoDeLabirinto é implementada por todos os componentes de um labirinto
  • Tem um método entra() cujo significado depende onde se está entrando
    • Se for uma sala, a localização do jogador muda
    • Se for uma porta aberta, você vai para outra sala, caso contrário se machuca
    • Se for uma parede, você se machuca

public interface ElementoDeLabirinto {
    public void entra();
}

• Exemplo: se você estiver numa sala e quiser implementar a operação "vá para o leste", o jogo determina qual ElementoDeLabirinto está do lado leste e chama entra() deste objeto
  • O método entra() da subclasse específica determina o que ocorre
  • Num jogo real, entra() poderia aceitar o objeto jogador como parâmetro
• Sala é a classe que implementa ElementoDeLabirinto e define as relações-chave entre objetos
  • Mantém referências para 4 outros ElementoDeLabirinto
  • Armazena um número de sala para indentificar as salas do labirinto

class Sala implements ElementoDeLabirinto {
    private ElementoDeLabirinto[] vizinhos =
            new ElementoDeLabirinto[4];
    private int númeroDaSala;

    public Sala(int númeroDaSala) {
        ...
    }
    public void entra() {
        ...
    }
    public ElementoDeLabirinto getVizinho(int direção) {
        ...
    }
    public void setVizinho(int direção,
                           ElementoDeLabirinto vizinho) {
        ...
    }
}

class Parede implements ElementoDeLabirinto {
    public Parede() {
        ...
    }
    public void entra() {
        ...
    }
}

class Porta implements ElementoDeLabirinto {
    private Sala sala1, sala2;
    private boolean estáAberta;

    public Porta(ElementoDeLabirinto sala1,
                 ElementoDeLabirinto sala2) {
        ...
    }
    public void entra() {
        ...
    }
    public Sala salaDoOutroLado(Sala sala) {
        ...
    }
}

• Também precisamos de uma classe Labirinto para representar uma coleção de salas
  • A classe Labirinto pode localizar uma sala dado seu número com o método getSala()

class Labirinto {
    private Vector salas = new Vector();

    public Labirinto() {
        ...
    }
    public void adicionaSala(Sala sala) {
        ...
    }
    public sala getSala(int númeroDaSala) {
        ...
    }
}

• Também definimos uma classe Jogo que cria o labirinto
  • Uma forma simples de criar um labirinto é de criar os componentes, adicioná-los ao labirinto e interconectá-los
  • Exemplo da criação de um labirinto com 2 salas e uma porta entre elas

class Jogo {
    ...
    public Labirinto criaLabirinto() {
        Labirinto umLabirinto = new Labirinto();
        Sala sala1 = new Sala(1);
        Sala sala2 = new Sala(2);
        Porta aporta = new Porta(sala1,sala2);

        umLabirinto.adicionaSala(sala1);
        umLabirinto.adicionaSala(sala2);

        sala1.setVizinho(norte, new Parede());
        sala1.setVizinho(leste, aporta);
        sala1.setVizinho(sul, new Parede());
        sala1.setVizinho(oeste, new Parede());

        sala2.setVizinho(norte, new Parede());
        sala2.setVizinho(leste, new Parede());
        sala2.setVizinho(sul, new Parede());
        sala2.setVizinho(oeste, aporta);

        return umLabirinto;
    }
    ...
}

• O problema desta solução é sua inflexibilidade
  • O método criaLabirinto() não é reutilizável em outras situações
  • Motivo: criaLabirinto() mistura a questão da estrutura do labirinto com a questão dos tipos exatos de elementos que compõem o labirinto
    • New cria um forte acoplamento entre a classe Jogo e as classes dos objetos criados porque implica num compromisso (amarração) com uma determinada implementação

• Veremos agora como mudar o projeto para criar diferentes tipos de labirintos
  • Labirintos encantados
    • Com portas travadas que precisam de um encantamento para abrir
    • Salas contendo encantamentos que podem ser apanhados
  • Labirintos perigosos
    • Salas com bombas que podem ser explodidas para danificar as paredes (e talvez o jogador!)

• Como mudar criaLabirinto() para facilmente criar estes novos tipos de labirintos?
  • O maior problema é que a solução atual nos força a colocar em código as classes concretas que serão instanciadas
• Usaremos padrões de criação para tornar o projeto mais flexível (mais reusável)

O padrão Factory Method

Objetivo

• Definir uma interface para criar objetos de forma a deixar subclasses decidirem qual classe instanciar
• Factory Method deixa que subclasses façam a instanciação

Também conhecido como

• Construtor Virtual

Resumo

• A idéia é simples: em vez de um cliente que precisa de um objeto chamar new e assim especificar a classe concreta que ele instancia, o cliente chama um método abstrato (Factory Method) especificado em alguma classe abstrata (ou interface) e a subclasse concreta vai decidir que tipo exato de objeto criar e retornar
  • Mudar a subclasse concreta que cria o objeto permite mudar a classe do objeto criado sem que cliente saiba
  • Permite estender a funcionalidade através da construção de subclasses sem afetar os clientes
• Resumindo:
  • "Crie objetos numa operação separada de forma que subclasses possam fazer override da forma de criação"

Quando usar o padrão Factory Method?

• Quando uma classe (o criador) não pode antecipar a classe dos objetos que deve criar
• Quando uma classe quer que suas subclasses especifiquem os objetos criados
• Quando classes delegam responsabilidade para uma entre várias subclasses de apoio e queremos localizar num ponto único a conhecimento de qual subclasse está sendo usada

Estrutura genérica

Participantes

• Produto: define a interface dos objetos criados pelo Factory Method
• ProdutoConcreto: implementa a interface Produto
• Criador: declara o Factory Method que retorna um objeto do tipo Produto
  • Às vezes, o Criador não é apenas uma interface mas pode envolver uma classe concretaque tenha tem uma implementação default para o Factory Method para retornar um objeto com algum tipo ProdutoConcreto default
  • Pode chamar o Factory Method para criar um produto do tipo Produto
• CriadorConcreto: faz override do Factory Method para retornar uma instância de ProdutoConcreto

Colaborações

• Criador depende de suas subclasses para definir o Factory Method para que ele retorne uma instância do ProdutoConcreto apropriado

Consequências do uso do padrão Factory Method

• Factory Methods eliminam a necessidade de colocar classes específicas da aplicação no código
  • O código só lida com a interface Produto
  • O código pode portanto funcionar com qualquer classe ProdutoConcreto
• Provê ganchos para subclasses
  • Criar objetos dentro de uma classe com um Factory Method é sempre mais flexível do que criar objetos diretamente
  • O Factory Method provê um gancho para que subclasses forneçam uma versão estendida de um objeto
  • Exemplo num editor de documentos
    • Uma classe Documento poderia ter um Factory Method criaFileDialog para criar um objeto file dialog default para abrir um documento existente
    • Uma subclasse de Documento poderia criar um file dialog especial através do override do Factory Method default
    • Neste caso, o Factory Method não é abstrato mas fornece um default razoável
  • Exercício: como estruturar o código de uma aplicação bancária para que você não fique maluco quando seu gerente pedir que todas as novas contas de poupança criadas a partir de segunda-feira tenham algo novo implementado nelas mas sem afetar código antigo que trata das contas antigas?

Considerações de implementação

• É boa prática usar uma convenção de nomes para alertar para o fato de que está usando Factory Methods
  • Exemplo: makeAbc(), makeXyz()
  • Exemplo: criaAbc(), criaXyz()

Exemplo de código: criação de labirintos

• A criação de labirintos já vista não ficou flexível pois criamos (com new) os objetos especificando as classes concretas na função criaLabirinto()
• Usaremos Factory Methods para deixar que subclasses escolham que objetos criar
• Usaremos o seguinte projeto
  • Produto: Sala, Parede, Porta
  • ProdutoConcreto: Sala, SalaEncantada, SalaPerigosa, Parede, ParedeComBomba, Porta, PortaComChave
  • Ccriador: Jogo
    • Seu método criaLabirinto cria o labirinto chamando Factory Methods
    • Ele também é um CriadorConcreto pois oferece uma implementação default para os Factory Methods (para criar um labirinto simples)
  • CriadorConcreto: Jogo, JogoEncantado, JogoPerigoso que serão subclasses de jogo
• Iniciamos com o criador Jogo que contém os Factory Methods

class Jogo {
    // Factory Methods com default
    public Labirinto criaLabirinto() {
        return new Labirinto();
    }
    public Sala criaSala(int númeroDaSala) {
        return new Sala(númeroDaSala);
    }
    public Parede criaParede() {
        return new Parede();
    }
    public Porta criaPorta(Sala sala1, Sala sala2) {
        return new Porta(sala1, sala2);
    }

    // Observe que essa função não tem new:
    // ela usa Factory Methods
    // Esta é a *única* diferença com relação
    // à versão original
    // Observe como o método só trata da estrutura do labirinto
    // e não do tipo de elemento que o compõe
    public Labirinto criaLabirinto() {
        Labirinto umLabirinto = criaLabirinto();
        Sala sala1 = criaSala(1);
        Sala sala2 = criaSala(2);
        Porta aPorta = criaPorta(sala1, sala2);

        umLabirinto.adicionaSala(sala1);
        umLabirinto.adicionaSala(sala2);

        sala1.setVizinho(norte, criaParede());
        sala1.setVizinho(leste, aporta);
        sala1.setVizinho(sul, criaParede());
        sala1.setVizinho(oeste, criaParede());

        sala2.setVizinho(norte, criaParede());
        sala2.setVizinho(leste, criaParede());
        sala2.setVizinho(sul, criaParede());
        sala2.setVizinho(oeste, aporta);

        return umLabirinto;
    }
}

• Para criar um jogo perigoso, criamos uma subclasse de Jogo e redefinimos alguns Factory Methods

// um novo CriadorConcreto
class JogoPerigoso extends Jogo {
    public Parede criaParede() {
        return new ParedeDestrutível();
    }
    public Sala criaSala(int númeroDaSala) {
        return new SalaComBomba(númeroDaSala);
    }
}

• Comparando o diagrama de objetos com a versão inicial, não há objeto adicional
  • Só há uma mudança do objeto umJogo para um umJogoPerigoso

• Para criar um jogo encantado, procedemos de forma análoga

// um novo CriadorConcreto
class JogoEncantado extends Jogo {
    public sala criaSala(int númeroDaSala) {
        return new salaEncantada(númeroDaSala, jogaEncantamento());
    }
    public Porta criaPorta(Sala sala1, Sala sala2) {
        return new portaPrecisandoDeEncantamento(sala1, sala2);
    }
    protected Encantamento jogaEncantamento() {
        ...
    }
}

• O acoplamento depois do Factory Method

Discussão geral de padrões de criação

• Ajudam a deixar o sistema independente de como seus objetos são criados, compostos e representados
• São dois tipos:
  • Padrões de criação via classes
    • Usam herança para variar a classe que é instanciada
    • Exemplo: Factory Method
  • Padrões de criação via objetos
    • Delegam a instanciação para outro objeto
    • Exemplo: Abstract Factory
• Composição é usada mais que herança para estender funcionalidade e padrões de criação ajudam a lidar com a complexidade de criar comportamentos
  • Em vez de codificar um comportamento estaticamente, definimos pequenos comportamentos padrão e usamos composição para definir comportamentos mais complexos
  • Isso significa que instanciar um objeto com um comportamento particular requer mais do que simplesmente instanciar uma classe.
  • Eles escondem como instâncias das classes concretas são criadas e juntadas para gerar "comportamentos" (que podem envolver vários objetos compostos)
  • Os padrões mostrados aqui mostram como encapsular as coisas de forma a simplificar o problema de instanciação.

  Os padrões de criação discutem temas recorrentes:

  • Eles encapsulam o conhecimento das classes concretas que são instanciadas
    • Lembre que preferimos nos "amarrar" a interfaces (via interface ou classes abstratas) do que a classes concretas
    • Isso promove a flexibilidade de mudança (das classes concretas que são instanciadas)

Pergunta final para discussão

• De que forma a Factory Method ajuda a produzir código fracamente acoplado?

pat-3 programa anterior próxima