1 Introdução aos Padrões de Projetos (na prática) Créditos: Lúbia Vinhas Hazel Carvalho Crato Adaptações: Prof. Nécio de Lima Veras.

Apresentação em tema: "1 Introdução aos Padrões de Projetos (na prática) Créditos: Lúbia Vinhas Hazel Carvalho Crato Adaptações: Prof. Nécio de Lima Veras."— Transcrição da apresentação:

1 1 Introdução aos Padrões de Projetos (na prática) Créditos: Lúbia Vinhas Hazel Carvalho Crato Adaptações: Prof. Nécio de Lima Veras

2 Padrões de Projeto de Software OO Estudando uns padrões específicos Nesta semana De Criação:  Singleton;  Abstract Factory; Próxima Semana Estrutural:  Decorator; Comportamental:  Observer;  Strategy;

3 3 Padrões de Criação SINGLETON

4 Padrões de Projeto de Software OO Singleton Intenção  Garantir que uma classe tenha uma única instância e um único ponto de acesso a essa instância; Motivação  Sistemas podem precisar de classes com uma única instância: Ex. uma único valor de precisão, um único sistema de arquivos Use um Singleton quando:  É preciso que exista apenas uma instância de uma classe e essa instância deve ser acessada através de um único ponto bem conhecido;  Quando essa classe possa ser estendida através de derivação e que os seus clientes possam usar a instância estendida sem modificar seu código;

5 Padrões de Projeto de Software OO Exemplos Um spooler de impressão; Um sistema de arquivos; Um Window manager; Um objeto que contém a configuração do programa; Um ponto de acesso ao banco de dados;

6 Padrões de Projeto de Software OO Obstáculos A definição de uma variável global deixa a instância (objeto) acessível mas não inibe a instanciação múltipla. Então, como assegurar que somente uma instância de uma classe seja criada para toda a aplicação?

7 Padrões de Projeto de Software OO Solução Singleton Fazer com que a própria classe seja responsável pela manutenção da instância única, de tal forma que:  Quando a instância for requisitada pela primeira vez, essa instância deve ser criada;  Em requisições subseqüentes, a instância criada na primeira vez é retornada. Assim, a classe Singleton deve:  armazenar a única instância existente;  garantir que apenas uma instância será criada;  prover acesso a tal instância. Resolver o problema de variáveis globais e únicas:  Inicializar a variável apenas quando necessário  Evitar alterações desnecessárias

8 Padrões de Projeto de Software OO Singleton - Estrutura Acesso controlado à instância única; Evita poluição do espaço de nomes com variáveis globais; Permite refinamentos na representação e operações por meio de derivações;

9 Padrões de Projeto de Software OO Singleton em C++ // Only one object of this class can be created class Singleton { private: static Singleton* _instance; void otherOperations(); protected: Singleton(); public: static Singleton* instance(); static void destroy(); } Singleton* Singleton::_instance = 0; Singleton* Singleton::instance() { if (_instance == 0 ) _instance = new Singleton; return _instance; } // Use if ( Singleton::instance()->value ==...)

10 Padrões de Projeto de Software OO Uso do padrão Singleton Como evitar a necessidade de copiar a interface do padrão Singleton para todas as classes deste tipo no seu código? Ajustes no padrão são propagados para todos os seus usos? Alternativa: construir um “template” ??

11 Padrões de Projeto de Software OO Proposta Que tal pensar um pouquinho e criar uma classe em Java? Já com a classe criada, que tal agora pensar em uma estrutura única que gere Singletons?

12 12 Padrões de Criação ABSTRACT FACTORY

13 Padrões de Projeto de Software OO Abstract Factory Propósito:  Prover uma interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas; Motivação:  Montadoras de carros: Diferentes modelos (Diferentes acessórios)  Gerador de documentos: Diferentes documentos (textos, planilhas, apresentações)  Diferentes estilos de documentos (cartas de recomendação, curriculos, etc.);

14 Padrões de Projeto de Software OO Motivação Exemplo 1:

15 Padrões de Projeto de Software OO Motivação Exemplo 2:

16 Padrões de Projeto de Software OO Motivação Diferentes padrões look-and-feel definem diferentes aparências (look) e comportamentos (feel) para um widget de uma interface de usuário. Exemplos: barras de rolagem, janelas, botões etc. Para ser portável através dos padrões look-and-feel, uma aplicação não deve instanciar os widgets diretamente de suas classes concretas para uma aparência ou comportamento particular. Para facilitar a alteração da aparência e do comportamento futuramente, defina uma classe abstrata GUIFactory que declara uma interface para criar cada tipo de widget básico. Defina ainda uma interface para cada tipo de widget e subclasses concretas que implementam widgets para um específico padrão look-and- feel.

17 Padrões de Projeto de Software OO Motivação A interface de GUIFactory possui uma operação que retorna um novo widget concreto para cada widget abstrato. Há uma sub-classe concreta de GUIFactory para cada padrão look-and-feel. Cada sub-classe implementa as operações para criar o widget apropriado para o respectivo look-and-feel. Clientes criam os widgets apenas através da GUIFactory sem saber quem são widgets concretos para um específico look- and-feel. Uma GUIFactory reforça as dependências entre as classes concretas de widgets.

18 Padrões de Projeto de Software OO Aplicabilidade O padrão deve ser usado quando:  Um sistema deve ser implementado independente de como os produtos são criados, compostos e representados.  Um sistema deve ser configurado com uma das múltiplas famílias de produtos.  Uma familia de um produto relacionado é projetada para ser utilizada junta, e faz-se necessário o reforço dessa restriçao.  Deseja-se prover uma biblioteca de classes de produtos e deseja-se revelar apenas as suas interfaces, mas não suas implementações.

19 Padrões de Projeto de Software OO Estrutura

20 Padrões de Projeto de Software OO Participantes AbstractFactory  Declara uma interface para operações que criam produtos abstratos. ConcreteFactory  Implementa as operações para criar produtos concretos. AbstractProduct  Declara uma interface para um tipo de produto. ConcreteProduct  Define um produto a ser criado pela fábrica concreta correspondente.  Implementa a interface AbstractProduct. Client  Usa apenas interfaces declaradas pelas classes AbstractFactory e AbstractProduct.

21 Padrões de Projeto de Software OO Colaborações Normalmente uma única instância da classe ConcreteFactory é criada em tempo de execução. AbstractFactory delega a criação de produtos concretos para a respectiva subclasse ConcreteFactory. A classe ConcreteFactory cria produtos que possuem uma implementação particular, por exemplo: todos os widgets de uma WinFactory concreta.

22 Padrões de Projeto de Software OO Conseqüências Vantagens  Abstract Factory isola classes concretas.  Facilita o intercâmbio de famílias de produtos.  Promove consistência entre produtos. Desvantagem  Suporte a novos tipos de produtos é dicífil.

23 23 Exemplo de Código

24 Padrões de Projeto de Software OO Estrutura

25 Padrões de Projeto de Software OO

26 Concrete Factory

27 Padrões de Projeto de Software OO Abstract Product

28 Padrões de Projeto de Software OO Concrete Product

29 Padrões de Projeto de Software OO Transfer Object

30 Padrões de Projeto de Software OO Client