Design Pattern (Fachada e Singleton) + Aula Prática II
Propaganda
Design Pattern (Padrões de Projeto) Prof. Alexandre Monteiro Recife ‹#› Contatos Prof. Guilherme Alexandre Monteiro Reinaldo Apelido: Alexandre Cordel E-mail/gtalk: [email protected] [email protected] Site: http://www.alexandrecordel.com.br/fbv Celular: (81) 9801-1878 Origem Padrão de Projeto Christopher Alexander em seus livros (1977/1979) Notes on the Synthesis of Form, The Timeless Way of Building e A Pattern Language, estabelece que um padrão deve ter, idealmente, as seguintes características: • Encapsulamento: um padrão encapsula um problema ou solução bem definida. Ele deve ser independente, específico e formulado de maneira a ficar claro onde ele se aplica. • Generalidade: todo padrão deve permitir a construção de outras realizações a partir deste padrão. • Equilíbrio: quando um padrão é utilizado em uma aplicação, o equilíbrio dá a razão, relacionada com cada uma das restrições envolvidas, para cada passo do projeto. Uma análise racional que envolva uma abstração de dados empíricos, uma observação da aplicação de padrões em artefatos tradicionais, uma série convincente de exemplos e uma análise de soluções ruins ou fracassadas pode ser a forma de encontrar este equilíbrio. • Abstração: os padrões representam abstrações da experiência empírica ou do conhecimento cotidiano. • Abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe. • Combinatoriedade: os padrões são relacionados hierarquicamente. Padrões de alto nível podem ser compostos ou relacionados com padrões que endereçam problemas de nível mais baixo. Características de Padrão de Projeto Alexander definiu que um padrão deve ser descrito em cinco partes: • Nome: uma descrição da solução, mais do que do problema ou do contexto. • Exemplo: uma ou mais figuras, diagramas ou descrições que ilustrem um protótipo de aplicação. • Contexto: a descrição das situações sob as quais o padrão se aplica. • Problema: uma descrição das forças e restrições envolvidos e como elas interagem. • Solução: relacionamentos estáticos e regras dinâmicas descrevendo como construir artefatos de acordo com o padrão, freqüentemente citando variações e formas de ajustar a solução segundo as circunstâncias. Inclui referências a outras soluções e o relacionamento com outros padrões de nível mais baixo ou mais alto. Introdução à Padrão de Projeto É uma solução geral reutilizável para um problema que ocorre com frequência dentro de um determinado contexto no projeto de software. Um padrão de projeto não é um projeto finalizado que pode ser diretamente transformado em código fonte ou de máquina, ele é uma descrição ou modelo (template) de como resolver um problema que pode ser usado em muitas situações diferentes. Padrões são melhores práticas formalizadas que o programador pode usar para resolver problemas comuns quando projetar uma aplicação ou sistema. Introdução à Padrão de Projeto Padrões de projeto orientados a objeto normalmente mostram relacionamentos e interações entre classes ou objetos, sem especificar as classes ou objetos da aplicação final que estão envolvidas. Padrões que implicam orientação a objetos ou estado mutável mais geral, não são tão aplicáveis em linguagens de programação funcional. Padrão GoF Livro Design Patterns: Elements of Reusable Object-Oriented Software, publicado em 1995. Autores: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, são conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente "GoF". Os padrões "GoF" são organizados em 3 famílias : • Padrões de criação: relacionados à criação de objetos • Padrões estruturais: tratam das associações entre classes e objetos. • Padrões comportamentais: tratam das interações e divisões de responsabilidades entre as classes ou objetos. Padrão "GoF" é classificado em 2 outros grupos : • Padrões com escopo de classe : definido por relacionamentos de herança e em tempo de compilação. • Padrões com escopo de objeto : encontrados no relacionamento entre os objetos definidos em tempo de execução. Alguns Padrões de Projeto Padrões de criação • Abstract Factory | Builder | Factory Method | Prototype | Singleton Padrões estruturais • Adapter | Bridge | Composite | Decorator | Façade (ou Facade) | Flyweight | Proxy Padrões comportamentais • Chain of Responsibility | Command | Interpreter | Iterator | Mediator | Memento | Observer | State | Strategy | Template Method | Visitor Utilizaremos em nosso projeto 2 desses padrões: • Facade e Singleton Facade ou Fachada É um objeto que disponibiliza uma interface simplificada para uma das funcionalidades de uma aplicação. Singleton Este padrão garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto. Ex.: Conexão com banco de dados, Log de sistema, Sessão de Aplicação, etc. Fachada + Singleton Browser Evolução dos Dados (DADOS) MODEL (Objeto) MODEL (Objeto) Mapeamento Objeto-Relacional TABELA (Registro) Linguagens (VIEW) JSP Fachada (CONTROLLER) (MODEL) HIBERNATE JAVA JAVA HQL SQL Fachada + Singleton Fachada Singleton Continuação: Fachada + Singleton Controlador Deverá ser criado um pacote “controlador” ou “controller”, no qual deverá constar um conjunto de classes de controle referentes a cada uma da Entidades manipuladas para o projeto. Controlador Controlador: saveUsuario(u) Controlador: deleteUsuario(u) Controlador: updateUsuario(u) Controlador: listUsuarios() Controlador: searchUsuario_(...) Exception Deverá ser criado um pacote “exception”, no qual deverá constar um conjunto de classes de exceções referentes a cada uma da Entidades manipuladas para o projeto. DAO (Data Access Object) Objetivo • Prover isolamento da tecnologia de persistência. Propósito • O padrão Data Access Object (DAO) é um padrão introduzido no ambiente JEE [3] para simplificar e desacoplar a interação das aplicações Java com a API JDBC. DAO (Data Access Object) O problema que o padrão DAO tenta resolver tem, na realidade, três perspectivas: • Legado: Queremos encapsular lógicas de persistência legadas escritas com SQL ou outras tecnologias de forma simples. Queremos apenas utilizar as tecnologias java, mas manter as mesmas regras de negócio. • Isolamento: Queremos que a aplicação seja isolada da API com que está comunicando. Queremos poder alterar a API utilizada internamente sem alterar o contrato de acesso aos dados. • Mapeamento de Objetos: Queremos utilizar objetos no ambiente Java. Queremos poder utilizar os mesmos objetos independentemente da API de persistência. Normalmente isto passa por respeitar algum Mapeamento Objeto-Relacional - ORM (Object-Relational Mapping). DAO (Data Access Object) A principal vantagem do DAO é ter um local onde todo o acesso a dados será concentrado, ao invés de ter várias classes que manipulam dados espalhadas pela aplicação. A desvantagem é acrescentar mais uma camada (interface), aumentar o nível de complexidade, ficar um pouco mais pesado por ter que instanciar mais classes. DAO (Data Access Object) A interface do padrão original é simples. São fornecidos métodos para as operações CRUD, sendo que a operação de recuperação é distribuída em diferentes métodos de pesquisa especializados. São estes métodos especializados que encapsulam facilmente lógicas de pesquisa de sistemas legados. DAO (Data Access Object) DAO Genérico
