Factory Pattern. SISMO - Sistemas e Mobilidade Junho de Departamento de Informática / UFMA

Transcrição

1 Factory Pattern SISMO - Sistemas e Mobilidade Departamento de Informática / UFMA Junho de 2008

2 Do que vamos tratar? Criação de objetos não é simplesmente usar o operador new sobre uma classe Às vezes, a instanciação de objetos deve ser encapsulada A instanciação também pode gerar problemas de acoplamento Como lidar com esses problemas?

3 Programando para interface Quando escrevemos código do tipo: Combatente soldado = new Caveira(); estamos atribuindo uma instância (de uma classe concreta) a uma referência para interface Também poderíamos instanciar objetos em qualquer parte do nosso código, dependendo de algum contexto em tempo de execução. Por exemplo: Combatente soldado; if (flag) soldado = new Caveira(); else soldado = new SoldadoDaSelva();

4 Qual o problema com o código anterior? Novamente, os problemas estão relacionados à manutenção Quando houver necessidade de mudança, é necessário identificar onde os objetos são criados e fazer as alterações necessárias Podemos criar objetos em qualquer parte do código, o que dificulta a manutenção o problema não é com o operador new, mas com as inevitáveis mudanças

5 Identificando o que muda A Pizza Rute, uma pizzaria hightec, tem todo o processo de produção de pizzas automatizado a partir da emissão do pedido Figura: Código de Pedido

6 Identificando o que muda II Para enfrentar a concorrência, novas pizzas devem ser adicionadas Enquanto outras, que não têm muita saída, devem ser exlcuídas do menu A instanciação de classes concretas vai gerar problemas de manutenção A criação de instâncias é um aspecto sujeito a mudanças Além de acontecer em qualquer parte do código

7 Encapsulando a criação de objetos Simple Factory Figura: Construindo uma Fábrica simples de Pizzas Simple Factory não é considerado um padrão de design, mas já ajuda encapsulando a criação de objetos

8 Usando a Fábrica de Pizzas Figura: Código sem instanciação de classes concretas

9 O sucesso da Pizza Rute Surgiram franquias em diferentes regiões e foi necessário adaptar as pizzas para gostos diferentes (massa fina, grossa, crocante, etc.) Um meio de lidar com esse problema seria criar diferentes fábricas regionais para produzir pizzas ao gosto de cada região Figura: Regionalizando as fábricas

10 A evolução das franquias Contudo, as franquias se diferenciaram não só em relação aos tipos de pizza, mas também em relação às outras fases da produção Já que isso estava acontecendo, talvez fosse melhor diferenciar todo o processo de criação de uma forma flexível

11 Um Arcabouço para a PizzaRute Figura: Arcabouço

12 Características do arcabouço Pusemos o método createpizza() de volta à classe PizzaRute Esse é agora um método abstrato. Isso obriga a criarmos subclasses de lojas regionais da Pizza Rute, para implementarem esse método de acordo com o gosto de cada região, além de permitir reescrever outros métodos, se for necessário

13 Diagrama de classes do Arcabouço Figura: Arcabouço PizzaRute

14 Subclasse da classe PizzaRute Figura: Pizza Rute de São Paulo

15 Algumas Consequências Quando o método pedidopizza() é executado ele chama o método createpizza() para criar uma pizza. O método createpizza() sobrescrito nas subclasses da classe PizzaRute() é que decide como a pizza vai ser criada Ao definir qual a subclasse de PizzaRute() vai ser usada, o código cliente define, indiretamente, o estilo de todas as pizzas criadas porque cada subclasse implementa sua versão do método createpizza()

16 Mais Consequências A responsabilidade pela instanciação de pizzas foi movida para o método createpizza(), o qual funciona como uma fábrica Um método fábrica encapsula a criação de objetos em subclasses Isso desacopla o código cliente, na superclasse, da criação dos objetos, nas subclasses

17 Método Fábrica (FactoryMethod) Considere a seguinte instrução: abstract Produto factorymethod(string tipo); O factory method é abstrato, contando com as subclasses para implementá-lo O factory method retorna um produto normalmente usado pelos métodos definidos na superclasse O factory method isola o cliente (no exemplo, o método pedidopizza) de saber que tipo de produto concreto está sendo criado O factory method pode ser parametrizado para selecionar variações do produto

18 A classe Pizza I Figura: Definição da classe Pizza

19 A classe Pizza II Figura: Definição da classe Pizza

20 A classe Pizza Concreta I Figura: Pizza no estilo de São Paulo

21 A classe Pizza Concreta II Figura: Pizza no estilo de São Luis

22 Usando o arcabouço Figura: Testando o sistema

23 O Padrão Factory Method Classificação Propósito: Criacional Escopo: Objetos Intenção define uma interface para criar um objeto, mas deixa as subclasses decidirem que classes instanciar a.k.a. virtual constructor

24 Aplicabilidade Use o padrão Factory Method quando... Quando uma classe não pode antecipar a classe de objetos que deve criar Quando uma classe quer que suas subclasses especifiquem os objetos que criam Quando quiser localizar o conhecimento a respeito de subclasses às quais são delegadas responsabilidades específicas (em hierarquias de classes paralelas)

25 Aplicabilidade II Figura: Hierarquias Paralelas

26 Estrutura do Factory Method Figura: Diagrama de Classes

27 Participantes Product: define a interface dos objetos criados pelo método fábrica ConcreteProduct: implementa a interface definida em Product Creator: declara o método fábrica (que retorna um objeto do tipo Product); ConcreteCreator: redefine o método fábrica para retornar uma instância da classe ConcreteProduct.

28 Colaborações Creator depende de suas subclasses para definir o método fábrica que retorne uma instância do ConcretProduct apropriado

29 Mais um exemplo Frameworks: considere um arcabouço para aplicações que pode apresentar múltiplos documentos para o usuário O arcabouço define duas classes abstratas: Application e Document O tipo de documento que a aplicação deve abrir depende do tipo de aplicação O arcabouço deve instanciar classes, mas só conhece classes abstratas

30 Classes do exemplo Figura: Diagrama de Classes

31 Consequências O código lida somente com a interface de Product É mais vantajoso quando Creator precisa ter subclasses de qualquer maneira Conecta hierarquia de classes paralelas que ocorrem quando uma classe delega algumas de suas responsabilidades para uma classe separada

32 Dependência de objetos Quando um código instancia diretamente um objeto, fica dependente de sua classe concreta Se a implementação dessas classes muda, o código cliente deve mudar também Cada classe concreta instanciada em um código é uma dependência a mais

33 Dependência de objetos Princípio da Inversão de Dependência: Dependa de abstração. Não dependa de classe concreta Isso implica não só que componentes de alto nível devem depender, sempre que possível, apenas de abstrações, mas componentes de baixo nível também. Por exemplo: a classe PizzaRute não instancia diretamente classes concretas de pizzas, mas encapsula essa tarefa nos métodos fábrica createpizza de suas subclasses Por outro lado, as classes de pizzas concretas dependem da classe Pizza porque implementam esta interface (ou classe abstrata)

34 Porque Princípio de Inversão de Dependência? Intuitivamente, fazemos componentes de alto nível depender de componentes de baixo nível, como no caso de classes instanciando diretamente classes concretas dentro de seu código A inversão de dependência se dá quando tanto componentes de alto nível quanto componentes de baixo nível dependem ambos de abstrações