Engenharia de Software

Transcrição

1 Engenharia de Software Projeto e Implementação Padrões de Projeto Msc. Carlos Mar 04/2014

2 REVISÃO: ORIENTAÇÃO A OBJETOS Msc. Carlos Mar - Abr/2014

3 Conceitos Fundamentais Classe Objeto Atributos Métodos Encapsulamento Herança/Composição/Associação/Agregação Polimorfismo Interface

4 CLASSE Abstração de uma entidade do mundo real composta por propriedades (atributos) e métodos (operações) que atuam sobre essas propriedades. Representa um conjunto de objetos que possuem um conjunto de características e comportamentos comuns.

5 OBJETO Instância (ocorrência única) de uma classe. Capaz de armazenar estados através de seus atributos e reagir a mensagens enviadas a eles, assim como se relacionar e enviar mensagens a outros objetos.

6 ENCAPSULAMENTO (1/2) Esconder os detalhes da implementação de um objeto. O código cliente usa apenas a interface para a operação. A operação do objeto pode mudar mas o código cliente não muda. A manutenção é mais fácil e menos custosa.

7 ENCAPSULAMENTO (2/2) Não se deve permitir acesso direto aos atributos de uma classe (objeto). private, protected e public

8 HERANÇA (1/2) É o mecanismo pelo qual uma classe (sub-classe) pode estender outra classe (super-classe), aproveitando seus comportamentos (métodos) e variáveis possíveis (atributos). Também é conhecida como relacionamento É UM.

9 HERANÇA (2/2) Generalização Super-classe Especialização Sub-classe

10 ASSOCIAÇÃO Descreve um conjunto de vínculos (relacionamentos) entre dois ou mais objetos, sendo que ela pode ter atributos e métodos. Basicamente, uma dependência entre dois ou mais objetos descreve uma associação.

11 AGREGAÇÃO Mecanismo do Paradigma Orientado a Objetos que considera a possibilidade de objetos serem compostos por outros objetos. Ex.: O objeto Carro é composto por centenas de outros objetos, tais como, Radio, Ar condicionado e GPS, cada qual com suas propriedades, comportamentos e serviços.

12 COMPOSIÇÃO Tipo de associação mais forte entre objetos, permitindo construir objetos complexos a partir de objetos simples

13 POLIMORFISMO (1/3)

14 POLIMORFISMO (2/3) Vem do grego e significa que pode tomar várias formas. Um único nome representando um código diferente, selecionado por algum mecanismo automático. Um nome, vários comportamentos. Ontem sai para dançar com uns amigos, mas acabamos dançando porque não conseguimos encontrar um lugar que nos agradasse. José cantou a noite inteira no Karaoke e João cantou a noite inteira a namorada de José.

15 POLIMORFISMO (3/3) Tipos de Polimorfismo: Coerção: o (+) soma dois nros reais e um inteiro é passado como parâmetro. Inclusão: Uma sub-classe pode responder como se fosse sua Super-classe. Paramétrico: Generics do JAVA. ArrayList<Aluno> alunos = new ArrayList<Aluno> Sobrecarga: construtores

16 INTERFACE É um contrato entre a classe e o mundo externo. Quando uma classe implementa uma interface, ela está comprometida a fornecer o comportamento publicado pela interface Uma INTERFACE não inclui qualquer implementação. public interface ControleRemoto { } void mudarcanal(int canal); void aumentarvolume (int taxa); void diminuirvolume (int taxa); boolean ligar(); boolean desligar();

17 Qual é a única coisa constante no desenvolvimento de software? SAÇNADUM

18 Vamos a um exemplo!!!! SimUDuck

19 ONDE TUDO COMEÇOU A idéia de padrões foi apresentada por Christopher Alexander em 1977 no contexto de Arquitetura (prédios e cidades): Cada padrão descreve um problema que ocorre repetidamente de novo e de novo em nosso ambiente, e então descreve a parte central da solução para aquele problema de uma forma que você pode usar esta solução um milhão de vezes, sem nunca implementa-la duas vezes da mesma forma.

20 UM CATÁLOGO DE SOLUÇÕES (1/2) Um padrão encerra o conhecimento de uma pessoa experiente em um determinado assunto de forma que este conhecimento pode ser transmitido para outras pessoas menos experientes. Outras ciências (p.ex. química) e engenharias possuem catálogos de soluções. Desde 1995, o desenvolvimento de software passou a ter o seu primeiro catálogo de soluções para projeto de software: o livro GoF.

21 UM CATÁLOGO DE SOLUÇÕES (2/2) A principal idéia por trás dos design patterns é o reuso da solução e não necessariamente o reuso do código, como acontece no caso de bibliotecas. A cada nova situação, um novo código deverá ser escrito, apesar da estrutura ser basicamente a mesma.

22 Gang of Four (GoF) (Gangue dos 4) E. Gamma and R. Helm and R. Johnson and J. Vlissides. Design Patterns - Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.

23 GoF Passamos a ter um vocabulário comum para conversar sobre projetos de software. Soluções que não tinham nome passam a ter nome. Ao invés de discutirmos um sistema em termos de pilhas, filas, árvores e listas ligadas, passamos a falar de coisas de muito mais alto nível como Fábricas, Fachadas, Observador, Estratégia, etc. Basearam o livro em C++ para que o impacto junto à comunidade de CC fosse maior. E o impacto foi enorme, o livro vendeu centenas de milhares de cópias.

24 COMO É DESCRITO UM PADRÃO Todo padrão deve: Nome Problema Solução Consequências/Forças

25 PADRÃO GoF (1/2) Nome (inclui número da página) um bom nome é essencial para que o padrão caia na boca do povo Objetivo / Intenção Motivação um cenário mostrando o problema e a necessidade da solução Aplicabilidade como reconhecer as situações nas quais o padrão é aplicável Estrutura uma representação gráfica da estrutura de classes do padrão (usando OMT91) em, às vezes, diagramas de interação (Booch 94) Participantes as classes e objetos que participam e quais são suas responsabilidades Colaborações como os participantes colaboram para exercer as suas responsabilidades

26 PADRÃO GoF (2/2) Conseqüências vantagens e desvantagens, trade-offs Implementação com quais detalhes devemos nos preocupar quando implementamos o padrão aspectos específicos de cada linguagem Exemplo de Código no caso do GoF, em C++ (a maioria) Usos Conhecidos exemplos de sistemas reais de domínios diferentes onde o padrão é utilizado Padrões Relacionados quais outros padrões devem ser usados em conjunto com esse quais padrões são similares a este, quais são as dierenças

27 CATEGORIAS DE PADRÕES GoF CATEGORIA DESCRIÇÃO PADRÕES DE CRIAÇÃO Abstraem o processo de instanciação dos objetos, contribuindo para tornar o sistema independente de como seus objetos são criados, compostos e representados. PADRÕES ESTRUTURAIS PADRÕES COMPORTAMENTAIS Preocupam-se com a forma como classes e objetos são compostos para formar estruturas maiores. Preocupam-se com algoritmos e atribuição de responsabilidades entre objetos.

28 PADRÕES DE CRIAÇÃO Abstract Factory Builder Factory Method Prototype Singleton

29 PADRÕES ESTRUTURAIS Adapter Bridge Composite Decorator Façade Flyweight Proxy

30 PADRÕES COMPORTAMENTAIS Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor

31 Voltando ao SimUDuck

32 PRINCÍPIO DE PROJETO 1 Identifique os aspectos que variam e separeos dos que permanecem iguais. Encapsule o que varia para não afetar o resto do seu código. Mais flexibilidade e menos impacto com as alterações de código.

33 SimUDuck O que varia? Voar e Grasnar Os dois comportamentos saem da classe Pato. Um novo conjunto de classes deve ser criado para representar esses comportamentos.

34 Como criar os comportamentos? Manter as coisas flexíveis. Atribuir comportamentos às instâncias de Patos. Iniciar um objeto PatoReal com um tipo específico de comportamento de vôo. Alterar o comportamento em tempo de execução.

35 PRINCÍPIO DE PROJETO 2 Programar para uma interface, não para uma implementação. As classes de comportamento é quem devem implementar as interfaces.

36 IMPLEMENTAR OS COMPORTAMENTOS

37 PRINCÍPIO DE PROJETO 3 Dar prioridade à composição. Os patos não mais herdaram seus comportamentos de voar e granas, agora obtêm esses comportamentos.

38 JUNTANDO TUDO!!!

39 PADRÃO STRATEGY Define uma família de algoritmos, encapsula cada um deles e os torna intercambiáveis. A estratégia permite o algoritmo variar independente dos clientes que o utilizam. Isso é familiar para vocês?

40

41 Exercício Aplique o Padrão de Projeto Strategy:

42 PADRÃO DE PROJETO: OBSERVER Como manter objetos atualizados quando algo importante ocorre? Como fazer com que os objetos decidam se querem ser informados em tempo de execução sobre tais mudanças?

43 Editora + Assinantes Subject Observers

44 SOLUÇÃO: EDITORAS + ASSINANTES ALTO ACOPLAMENTO APLICAR OS PRINCÍPIOS DE PROJETO

45 PRINCÍPIO DE PROJETO Busque designs levemente ligados (baixo acoplamento) entre objetos que interagem. Projetos levemente ligados permitem construer sistemas OO que podem lidar com mudanças porque minimizam a interdependência entre objetos.

46 NOVA SOLUÇÃO PARA EDITORAS

47 PADRÃO OBSERVER Define a dependência um-para-muitos entre objetos para que quando um objeto mude de estado todos os seus dependents sejam avisados e atualizados automaticamente.

48

49 EXERCÍCIO Imagine um operário de obras que esta trabalhando em uma construção junto com seus 'companheiros'.. O fato de uma sirene tocar implica em uma mudança (mudança de estado), que pode ser um sinal para a hora do almoço, pode ser o final do expediente e etc. Dê uma solução para este problema usando o padrão de projeto Observer.

50