Programação Orientada a Objetos 2 Flávio de Oliveira Silva, M.Sc.

Transcrição

1 Padrões Um padrão de é uma maneira de documentar uma solução conhecida para um problema usualmente encontrado O objetivo do padrão é permitir que boas soluções sejam reutilizadas em diferentes projetos Um padrão de projeto possui 3 partes distintas: Contexto Problema recorrente neste contexto Solução para o problema Características dos Padrões de Projeto São observados através da experiência São descritos de uma forma estruturada Previnem contra a reinvenção da roda Existem em diferentes níveis de abstração Estão em desenvolvimento contínuo São artefatos reutilizáveis Transmitem melhores práticas Permitem o uso de um vocabulário comum Podem ser utilizados em conjunto para resolver um problema mais amplo 57 Classificação de Padrões Padrões Os padrões de projeto podem ser classificados de acordo com a fase de desenvolvimento em que são mais adequados: Padrões de Análise (Analysis patterns) Seu foco é na fase de análise ou modelamento de negócio Padrões ligados ao domínio do problema Padrões de Arquitetura (Architectural patterns) Seu foco é na arquitetura do software Padrões de Projeto (Design patterns) Foco no projeto de componentes do software Muitas das vezes os padrões podem estar muito ligados tanto ao domínio da solução, quanto do problema 58 1

2 Classificação de Padrões Padrões Padrões de Análise (Analysis patterns) Martin Fowler, 1996 Padrões de Arquitetura (Architectural patterns) Apresentado inicialmente por Frank Buschmann et al., 1996 Computação Distribuída - Frank Buschmann et al., 2007 Padrões de Projeto (Design patterns) GOF (Gang of Four) E. Gamma, R. Helm, R. Johnson, J. Vlissides 1995 Aplicações Concorrentes e em Rede - Frank Buschmann et al Enterprise Integration Patterns Gregor Hohpe, 2003 Real-time Design Patterns Bruce Douglass, 2003.Net Design Patterns - Christian Thilmany, 2003 J2EE Design Patterns - Deepak Alur, 2003 Web Services Patterns Paul Monday, 2003 Ajax Design Patterns - Michael Mahemoff, 2006 SOA Design Patterns Thomas Erl, Padrões de Análise (Analysis Patterns) Proposto por Martin Fowler, em livro publicado em 1996 Notação do Livro não é baseada em UML Baseada em áreas (domínios) específicas como: manufatura; financeira e saúde Mesmo assim, padrões podem apresentados podem ser úteis em outros domínios Alguns princípios apresentados Um modelo não está certo ou errado, eles podem ser mais ou menos úteis Modelos conceituais estão ligados a tipos (interfaces) e não implementações (classes) Padrões são o ponto de partida, não o destino Sempre que possível, quando existir um tipo e um supertipo, considere colocar os recursos no supertipo, desde que isto faça sentido Quando múltipos atributos possuam um comportamento relacionado e presente em muitos tipos, combine estes atributos em um novo tipo fundamental 60 2

3 Padrões de Análise (Analysis Patterns) Exemplos de alguns padrões de projeto Quantity (3.1) Conversion Ratio (3.2) Compound Units (3.3) 3) Measurement (3.4) Observation (3.5) Range (4.3) Name (5.1) Account (6.1) Transaction (6.2) Summary Account (6.3) Plan (8.4) Contract (9.1) Product (10.3) Associative Type (15.1) 61 Padrões de Projeto GoF Trabalho proposto inicialmente por Erich Gamma, Richard Helm, Ralph Jonhson, John Vlissides (Gang of Four) em 1995 Famílias de Padrões De Criação Responsáveis pela criação de objetos Permitem que o sistema fique independente da forma como os objetos são criados Estruturais Relacionados com a forma com que classes e objetos são compostos a fim de formar estruturas maiores Comportamentais Relacionados com a atribuição de responsabilidades entre objetos Descrevem a comunicação entre objetos 62 3

4 Padrões de Criação Factory Fornece uma interface para criar um objeto, porém a decisão de qual classe será instanciada é decidida pelas subclasses Fornecem uma interface para criação de objetos sem especificar sua classe concreta Singleton Garante que apenas uma classe possua uma única instância e oferece um acesso global à mesma Builder Permite separar a construção de um objeto complexo de sua representação a fim de que diferentes objetos sejam criados através do mesmo processo Prototype Permite que um objeto seja criado a partir de uma instância existente copiando suas propriedades 63 Factory Permite que um objeto seja criado sem que seja necessário informar a classe exata que será criada Separa a complexidade de criação do objeto Uma interface define um método padrão para criação Subclasses implentam este método e devolvem o objeto desejado A fábrica implementa o método criando o objeto conforme necessário class GOF - Factory «interface» ImageReader + getdecodedimage() : DecodedImage ImageReaderFactory + getimagereader(inputstream) : ImageReader GifReader + getdecodedimage() : DecodedImage JpegReader + getdecodedimage() : DecodedImage 64 4

5 Factory Exemplo public interface ImageReader { public DecodedImage getdecodedimage(); public class GifReader implements ImageReader { public DecodedImage getdecodedimage() { //... return decodedimage; public class JpegReader implements ImageReader { public DecodedImage getdecodedimage() { //... return decodedimage; 65 Factory Exemplo public class ImageReaderFactory { public static ImageReader getimagereader(inputstream is) { int imagetype = determineimagetype(is); switch(imagetype) { ( g yp ) { case ImageReaderFactory.GIF: return new GifReader(is); case ImageReaderFactory.JPEG: return new JpegReader(is); // etc. 66 5

6 Permite que objetos sejam criados de forma transparente caso exista um grupo de diferente fábricas class Design Pattern - ApplicationRunner + main(string[]) : void + createosspecificfactory() : GUIFactory Application + Application(GUIFactory) «interface» GUIFactory «interface» Button + createbutton() : Button + paint() : void WinFactory OSXFactory WinButton OSXButton + createbutton() : Button + createbutton() : Button + paint() : void + paint() : void 67 interface GUIFactory { public Button createbutton(); class WinFactory implements GUIFactory { y p y { public Button createbutton() { return new WinButton(); class OSXFactory implements GUIFactory { public Button createbutton() { return new OSXButton(); 68 6

7 interface Button { public void paint(); class WinButton implements Button { bli id i t() { public void paint() { System.out.println("I'm a WinButton"); class OSXButton implements Button { public void paint() { System.out.println("I'm an OSXButton"); 69 class Application { public Application(GUIFactory factory) { Button button = factory.createbutton(); button.paint(); public class ApplicationRunner { public static void main(string[] args) { new Application(createOsSpecificFactory()); public static GUIFactory createosspecificfactory() { int sys = readfromconfigfile("os_type"); Fil if (sys == 0) { return new WinFactory(); else { return new OSXFactory(); 70 7

8 Singleton Objetivo Garante que existirá uma única instância de um objeto de uma classe e permite um acesso global ao mesmo Motivação Em muitas situações é necessário um único objeto. Exemplos: O objeto que representa um sistema de arquivos do Sistema Operacional Um objeto que representa um arquivo de configuração de uma aplicação Um objeto que representa uma conexão com um banco de dados 71 Singleton Exemplo public class Singleton { //instância de um objeto da classe Singleton //inicializada com a chamada do construtor private static Singleton instance = new Singleton(); //Construtor privado impede criação de objetos desta classe private Singleton() { //lógica para criação do objeto //método estático que retorna a única instância i da classe public static Singleton getinstance() { return instance; 72 8

9 Singleton Exemplo - Outra abordagem public class Singleton { // Private constructor prevents instantiation from other classes private Singleton() { /** * SingletonHolder is loaded on the first execution of Singleton.getInstance() * or the first access to SingletonHolder.INSTANCE, not before. */ private static class SingletonHolder { public static ti final Singleton instance = new Singleton(); public static Singleton getinstance() { return SingletonHolder.instance; 73 9