Reuso de Software 12/03/2012

   # # # # # # # # # # # # #
  # Reuso de Software       #
  # Prof Eduardo Figueiredo #
  # notasdogarcia.blog.com  #
   # # # # # # # # # # # # #

  POO e Padrões de Projetos:

  Programação Orientada a Objetos:
    - Reuso de classes
    - Bibliotecas
    - Frameworks

  // O professor mostrou como uma mesma classe pessoa, pode ser reutilizada
  // em vários casos diferentes: aluno/professor, funcionário/cliente, etc.

  Bibliotecas possuem serviços frequentemente necessários, como estruturas de dados e etc.

  Qual a vantagem dessas coisas?
    - Produtividade, voce não precisa re-inventar a roda.
    - Confiabilidade, essas idéias já foram testadas por muitos usuários e por isso deve ser mais seguro.

  Desvantagens:
    - Dificil fazer adaptações para atender detalhes específicos do sistema, ex: uma otimização para um caso especifico.
    - Gasta-se tempo e esforço para aprender e/ou encontrar uma funcionalidade desejada.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Frameworks:
    Frameworks são um conjunto de classes e interfaces que formam uma estrutura genérica de um programa.

    Framworks normalmente não estão completos faltam os "acabamentos" por assim dizer.

    Assim partes mais especificas do sistema precisam ser implementadas à mão.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Características:
    - Frameworks são estensíveis, ou seja voce pode e deve criar classes para estender as do framework.
    - O fluxo de controle normalmente é pre-definido pelo framework e não pode ser alterado.
    - O código do framework não deve ser editado, deve apenas ser extendido.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Frozen Spot / Hot Spot:

    Os Frozen Spots são as partes do framework que não devem ser mechidas,
    ou seja as partes que já estão prontas.

    Os Hot Spots indicam os pontos que devem ser estendidos.

  // Um exemplo de analogia usada para frameworks é a de uma tomada conectada à uma classe maior.
  // Cada nova tomada traz consigo uma nova utilidade ao framework, ou uma nova função especifica.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Principais problemas:

    Frameworks são geralmente grandes e complexos levando um tempo grande para ser compreendido.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Padrões de Projeto:

    Um padrão é uma descrição do problema e a essência de sua solução.
    Ou seja é uma dica de uma solução comum e eficiente
    que é útil por ser uma linguagem comum com outros programadores.

    Existe um livro sobre o assunto com o nome "padrões de projeto"
    o livro fala sobre os padrões mais conhecidos que são chamados de padrões da gangue dos 4 (gang-of-four (GoF) (os 4 autores).

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  No livro GoF existem 23 padrões de projetos.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Classificações:
    - De criação
    - Estruturais
    - Comportamentais

  ou
    -  outras classificações.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Documentação de um Padrão:
    - Nome e clasificação
    - Qual o problema em questão
    - Como solucionar
    - Consequências dessa solução

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  No livro existem 5 tipos de padrões de criação falaremos de 2:
    - Factory Method
    - Singleton

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Nome:
    Factory Method:

  Descrição do Problema:
    É quando voce deseja criar uma classe mas não sabe qual o tipo dos dados que serão usados,
    assim voce cria a classe de forma abstrada, e deixa o tipo especifico para as subclasses.

  Descrição da solução:
    Existe um produto abstrato, e uma classe que cria esse produto que também é abstrata.
    Na implementação a classe concreta que estende a classe abstrata deve retornar um tipo concreto que estende o tipo abstrado.

  Consequencias:
    Permite que o programa fique mais genérico.
    Voce pode usar os objetos nas superclasses sem fixar qual o tipo especifico.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Nome:
    Padrão singleton

  Descrição do Problema:
    É quando precisa-se por qualquer motivo ter apenas uma instancia de uma classe.

  Descrição da solução:
    O método de criação é publico e estatico, e só cria um objeto se o antigo não existir.
    Ele garante que esse objeto só existe uma vez porque ele guarda um ponteiro para esse objeto.
    Não podem haver outros locais onde o objeto é criado, apenas atraves desse método estatico.
    O construtor da classe deve ser privado, e ele só pode ser chamado por essa função estatica.

  Consequencias:
    Fácil acesso e gerência de recursos compartilhados como variáveis globais.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Nome:
    Padrão Adapter

  Problema:
    As vezes voce quer re-usar uma biblioteca que utiliza uma aplicação.
    Porém a biblioteca não aceita o tipo da aplicação.
    E voce não quer refazer nem um dos dois do 0.

  Solução:
    Crie uma classe Adapter que é do tipo aceito pela biblioteca.
    Essa classe deve usar os métodos da aplicação para criar métodos no formato da biblioteca.
    Assim a biblioteca pode usar a classe Adapter que possuí as funcionalidades desejadas
    sem precisar re-implentar nada, só re-utilizando o que já existia.

  Consequencias:
    Tempo de implementação é poupado e voce pode re-usar coisas que a principio não seriam compativeis.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Nome:
    Padrão composite

  Problema:
    Voce tem várias estruturas simples e deseja criar estruturas complexas a partir disso.
    Exemplo voce tem celulas e deseja criar uma tabela de celulas.

  Solução:
    Crie uma classe Composite que extenda uma classe Component
    A classe composite deve aceitar vários objetos e guardar dados sobre eles, de forma que criem um novo objeto.
    Ex: seja um composite que forma objetos, e ele aceita elementos linha e elementos circulo.
        Para descrever uma casa ele precisa de saber que ele tem um certo numero de linhas em certas posições etc.

  Consequências:
    Objetos primitivos podem ser usados

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Nome:
    Decorator:

  Problema:
    Adicionar novas responsabilidades/funcionalidades à uma classe já instanciada.

  Solução:
    O decorator é mais complexo, voce tem vários objetos que tem como base uma interface com uma função "operação()".
    Cada classe que extende esse objeto tem uma função "operação()" e guarda um ponteiro para a próxima classe.
    Cada classe tem uma operação() diferente e faz uma coisinha a mais (coisas que não se atrapalhem)
    A cada chamada da operação da primeira classe ela chama a operação da segunda, e vai assim ate chegar em uma última.
    Na função operação() da última classe o ponteiro dela é nulo e assim ela não chama mais ninguém e retorna.

    Para quem não percebeu isso parece uma linha de montagem de uma fábrica, onde voce coloca o produto no inicio da linha,
    e ele vai caminhando de classe em classe onde cada classe adiciona um item ao produto final.

    // Cada decorador concreto extende o decorador abstrato que possui a função "operação()"

  Consequencia:
    Ganha maior flexibilidade.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Padrões comportamentais: Strategy, observer, existem vários outros.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Nome:
    Strategy

  Problema:
    Voce tem vários métodos de solução para um mesmo problema, mas em alguns programa pode ser melhor usar um metodo a outro.
    Então é interessante manter a flexibilidade, já que voce não quer re-implementar a classe a cada vez.

  Solução:
    Voce coloca uma interface base de mesmo nome, com vários filhos onde cada filho tem uma implementação diferente.
    A aplicação usa a interface sem saber bem qual a implementação especifica, mas o produto final é o mesmo.
    Isso permite voce usar a implementação mais eficiente em cada caso com pouca modificação.

  Consequencias:
    Permite utilizar diferentes algoritimos sem usar condicionais.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  // Fim da aula.