2 – Revisão de Programação Orientada a Objetos Padrões de Projeto 2 – Revisão de Programação Orientada a Objetos

Programação orientada a objetos Revisão rápida com análise acerca de algumas de suas implicações em Padrões de Projeto Padrões de Projeto - Revisão de POO Programação orientada a objetos

Parte 3 Polimorfismo (Quick Review) Coesão e Acoplamento Interfaces "Uma imagem vale mil palavras. Uma interface vale mil imagens.“ - Bem Schneiderman Polimorfismo (Quick Review) Coesão e Acoplamento Interfaces Padrões de Projeto - Revisão de POO Parte 3

numFuncionariosGerenciados Polimorfismo Polivárias morfoformas O que guarda uma variável do tipo Funcionário? Uma referência para um funcionário...  Gerente g = new Gerente(); Funcionario f = g; f.setSalario(1000); Padrões de Projeto - Revisão de POO O que guarda uma variável do tipo Funcionario? Uma referência para um Funcionario, nunca o objeto em si. Na herança, vimos que todo Gerente é um Funcionario, pois é uma extensão deste. Podemos nos referir a um Gerente como sendo um Funcionario. Se alguém precisa falar com um Funcionario do banco, pode falar com um Gerente! Porque? Pois Gerente é um Funcionario. Essa é a semântica da herança. Semântica da palavra poli(várias) morfo(formas) Polimorfismo é a capacidade de um objeto poder ser referenciado de várias formas. (cuidado, polimorfismo não quer dizer que o objeto fica se transformando, muito pelo contrário, um objeto nasce de um tipo e morre daquele tipo, o que pode mudar é a maneira como nos referimos a ele). Gerente get/setNome() get/setIdade() get/setSalario() Senha numFuncionariosGerenciados getBonificacao() Autentica() Gerente g Funcionario f

numFuncionariosGerenciados Polimorfismo O que guarda uma variável do tipo Funcionário? Uma referência para um funcionário. Gerente g = new Gerente(); Funcionario f = g; f.setSalario(1000); System.out.println(f.getBonificacao()); Padrões de Projeto - Revisão de POO Até aqui tudo bem, mas e se eu tentar: f.getBonificacao(); Qual é o retorno desse método? 100 ou 200? No Java, a invocação de método sempre vai ser decidida em tempo de execução. O Java vai procurar o objeto na memória e, aí sim, decidir qual método deve ser chamado, sempre relacionando com sua classe de verdade, e não com a que estamos usando para referenciá-lo. Apesar de estarmos nos referenciando a esse Gerente como sendo um Funcionário, o método executado é o do Gerente. O retorno é 200. Decidido em tempo de execução Gerente get/setNome() get/setIdade() get/setSalario() Senha numFuncionariosGerenciados getBonificacao() Autentica() Gerente g Funcionario f

Polimorfismo Por que polimorfismo? class ControleDeBonificacoes { private double totalDeBonificacoes = 0; public void registra(Funcionario funcionario) { this.totalDeBonificacoes += funcionario.getBonificacao(); } public double getTotalDeBonificacoes() { return this.totalDeBonificacoes; Padrões de Projeto - Revisão de POO

Polimorfismo Dicas sobre polimorfismo: Não importa como nos referenciamos a um objeto, o método que será invocado é sempre o do objeto em questão. Programe sempre pra uma superclasse! Por que polimorfismo? O que acontece se futuramente precisarmos criar outros tipos de funcionários? ControleDeBonificacoes controle = new ControleDeBonificacoes(); Gerente funcionario1 = new Gerente(); funcionario1.setSalario(1000); controle.registra(funcionario1); Funcionario funcionario2 = new Funcionario(); funcionario2.setSalario(1000); controle.registra(funcionario2); System.out.println(controle.getTotalDeBonificacoes()); Padrões de Projeto - Revisão de POO Repare que conseguimos passar um Gerente para um método que recebe umFuncionario como argumento. Pense como numa porta na agência bancária com o seguinte aviso: "Permitida a entrada apenas de Funcionários". Um gerente pode passar nessa porta? Sim, pois Gerente é um Funcionario. Qual será o valor resultante? Não importa que dentro do método registra do ControleDeBonificacoes receba Funcionario. Quando ele receber um objeto que realmente é um Gerente, o seu método reescrito será invocado. Reafirmando: não importa como nos referenciamos a um objeto, o método que será invocado é sempre o do objeto em questão. No dia em que criarmos uma classe Secretaria, por exemplo, que é filha de Funcionario, precisaremos mudar a classe de ControleDeBonificacoes? Não. Basta a classe Secretaria reescrever os métodos que lhe parecerem necessários. É exatamente esse o poder do polimorfismo, juntamente com a reescrita de método: diminuir o acoplamento entre as classes, para evitar que novos códigos resultem em modificações em inúmeros lugares. Repare que quem criou ControleDeBonificacoes pode nunca ter imaginado a criação da classe Secretaria ou Engenheiro. Contudo, não será necessário reimplementar esse controle em cada nova classe: reaproveitamos aquele código.

Polimorfismo Implemente o seguinte modelo: (8 minutos) Padrões de Projeto - Revisão de POO System.out.println("Cachorro correndo...");   System.out.println("AU AU AU!");   System.out.println("Cavalo correndo...");   System.out.println("IRRRIINN");   System.out.println("Preguica subindo em arvores...");   System.out.println("AAAAAAHHHHZZZZ"); 

Polimorfismo Crie uma classe Zoologico composta por 10 jaulas (array), onde cada uma terá um animal diferente. Depois percorra cada jaula e force o animal a emitir algum som e, se o tipo de animal (instanceof) possuir o comportamento, faça-o correr. (7 minutos)  Padrões de Projeto - Revisão de POO animal.emitirSom(); if(animal instanceof Cachorro){ Cachorro c = (Cachorro) animal; //faz o casting c.correr(); } else if(animal instanceof Cavalo) { Cavalo c = (Cavalo) animal; //faz o casting

Acoplamento e Coesão Coesão é o grau em que uma classe tem um único e bem focado propósito. Quanto maior a coesão, melhor é o projeto do sistema. { Padrões de Projeto - Revisão de POO

Acoplamento e Coesão Acoplamento é o grau com que uma classe conhece a outra. Quanto menor o acoplamento, melhor é o projeto do sistema. Benefícios: modularidade, flexibilidade, manutenibilidade. Lembrar: prezar pela alta coesão e fraco acoplamento. Uma das maneiras de se conseguir fraco acoplamento é com interfaces. Coesão e acoplamento são conceitos interligados: classes coesas tendem a gerar baixo acoplamento. Padrões de Projeto - Revisão de POO Como minimizar dependências e maximizar o reuso? O acoplamento é uma medida de quão fortemente uma classe está conectada, possui conhecimento ou depende de outra classe Com fraco acoplamento, uma classe não é dependente de muitas outras classes Com uma classe possuindo forte acoplamento, temos os seguintes problemas: Mudanças em uma classe relacionada força mudanças locais à classe A classe é mais difícil de ser reusada, já que depende da presença de outras classes A classe GerenciadorDeNotaFiscal depende de 3 outras classe: DAO (Data access object), email, serviço externo. Acoplar-se a uma classe significa depender dela. A classe GerenciadorDeNotaFiscal depende de DAO para acessar os dados e gerar a nota fiscal. Se DAO muda, existe uma grande possibilidade de GerenciadorDeNotaFiscal também mudar. E imagina só se tem outra classe que depende de GerenciadorDeNotaFiscal, as mudanças vão se propagando com muita facilidade, o que complica a manutenção do código. O mesmo aconteceria para as classes Email e Serviço Externo. Ou seja, quanto maior for a quantidade de classes dependentes maior a chance de uma delas mudar e impactar em mudança na classe principal. A ideia então é reduzir o acoplamento entre nossas classes o máximo possível. Mas sabemos que é impossível desenvolver sistemas com zero acoplamento. Mas será que todo e qualquer acoplamento é realmente problemático? Por exemplo, a grande maioria dos sistemas em Java no mundo são acoplados com a interface List(afinal a necessidade de guardar conjuntos de elementos é presente na maioria das aplicações). E fazer uso dessa interface geralmente não é problema para os desenvolvedores. Esse é um acoplamento “que não ligamos muito”. A grande charada é entender a diferença entre o acoplamento com List e com o DAO, por exemplo. A diferença é que a interface List não muda! Se ela não muda, isso significa que ela não forçará mudanças na classe que a usa! Ou seja, apesar de estarmos acoplados, o problema é menor, já que ela nunca provocará mudanças em nossos códigos! Isso sem contar a quantidade de classes que a referenciam hoje. Se algum engenheiro da Sun alterar essa interface, ele terá um trabalho imenso para propagar a mudança em muitos pontos. Portanto, provavelmente ele não fará isso! Isso torna essa interface estável! Classes ou interfaces estáveis são aquelas que não tendem a mudar. Acoplar com classes ou interfaces com essa característica é interessante, pois sabemos que a chance dela mudar é baixa. É por isso que interfaces são tão populares em códigos orientados a objeto. Interfaces tendem a ser estáveis, já que não possuem atributos ou implementação (coisas que tendem a mudar muito dentro de uma classe), e possuem muitas implementações embaixo dela (diminuindo a chance de algum programador mexer nela). Mais sobre em: http://blog.caelum.com.br/orientacao-a-objetos-uma-outra-perspectiva-sobre-o-acoplamento/ e Livro certificado java e google.

Interfaces Imagine agora que no Banco, além do Gerente existe um Diretor, que também tem privilégios de acesso à operações restritas... Padrões de Projeto - Revisão de POO Se lembram do nosso exemplo anterior? Suponha que agora tenhamos um Diretor que também tem acesso privilegiado, e deve autenticar-se para acessar o sistema. Como faremos para adicioná-lo ao nosso sistema?

Padrões de Projeto - Revisão de POO Observem que agora nós temos 2 classes com mesmos métodos: Diretor e Gerente autenticam. Quem poderia me dizer um motivo pelo qual isso não é legal? Resp.: não poderíamos usar o polimorfismo aqui 

Interfaces Padrões de Projeto - Revisão de POO Autentica não é um método de funcionário, e esse é o motivo pelo qual não poderíamos usar o polimorfismo. Uma alternativa seria utilizar 2 métodos login de maneira sobrecarregado, onde um receberia como argumento um Gerente e o outro um Direto. Isso é legal? Resp.: Não! Por que? Imagine se futuramente precisarmos adicionar mais funcionários com capacidade de autenticação... Sempre que adicionarmos uma nova classe teremos que implementar um novo método. Desse modo, a classe SistemaInterno ficaria completamente acoplada, e a ocorrência de mudanças no projeto poderia acarretar mais mudanças nessa classe.

Interfaces Nós já aprendemos duas situações em que o polimorfismo pode ser aplicado. Quais são elas? Herança + sobrescrita Interface + implementação Padrões de Projeto - Revisão de POO Polimorfismo só faz sentido quando há herança e sobrescrita de métodos, ou implementação de interfaces. O motivo é: para haver polimorfismo é preciso haver um método em uma superclasse e sua implementação ou sobrescrita em uma subclasse. Dito isto, sempre que possuirmos uma variável de referência da superclasse nós poderíamos “chamar” os métodos de instâncias das subclasses. Essa classe, inclusive poderia ser uma classe abstrata, cujo método autentica fosse abstrato, ou seja, deve ser implementado por quem herda. (Lembrar que classes abstratas não podem ser referenciadas!)

Interfaces Nós já aprendemos duas situações em que o polimorfismo pode ser aplicado. Quais são elas? Herança + sobrescrita Interface + implementação E se nós precisássemos dar capacidade de acesso ao sistema para os nossos clientes? Padrões de Projeto - Revisão de POO

{ Interfaces O que precisamos para resolver nosso problema? Relacionamento É-UM  também testamos com instanceof O que precisamos para resolver nosso problema? Interfaces! Por que? Nos permitirá referencia Diretor, Gerente e Cliente de um mesmo modo, mas sem quebrar a semântica do nosso projeto. Quem implementa interfaces assina um contrato. Isto nos garante que toda a classe não abstrata que implementou aquela interface possua uma implementação concreta para todos os métodos da interface. Não contém implementações; Expõe o que a classe que assinou o contrato deve fazer, mas não como fazer; Padrões de Projeto - Revisão de POO Quem assinar o contrato deve saber executar as seguintes operações com os seguintes argumentos e os seguintes retornos... Dizemos herdou por herança ou herdou por interface Lemos a interface da seguinte maneira: "quem desejar ser autenticável precisa saber autenticar dado um inteiro e retornando um booleano". Ela é um contrato onde quem assina se responsabiliza por implementar esses métodos (cumprir o contrato).or interface. contrato {

Interfaces Voltando ao nosso exemplo... Como resolver corretamente o caso de adicionar ao cliente a funcionalidade de autenticação? Padrões de Projeto - Revisão de POO

Padrões de Projeto - Revisão de POO ZOOM pra galera do fundão enxergar melhor 

Interfaces O implements pode ser lido assim: “A classe Gerente se compromete a ser tratada como Autenticavel, sendo obrigada a ter os métodos definidos neste contrato”. Padrões de Projeto - Revisão de POO

Interfaces O implements pode ser lido assim: “A classe Gerente se compromete a ser tratada como Autenticavel, sendo obrigada a ter os métodos definidos neste contrato”. Padrões de Projeto - Revisão de POO Como seria a implementação para cliente?

Padrões de Projeto - Revisão de POO The right way of doing it! Com isso, se nós programarmos para a interface Autenticavel nós ganhamos o poder do polimorfismo. Isso indica mais reuso e facilidade de manutenção.

Interfaces Polimorfismo com interfaces! Padrões de Projeto - Revisão de POO

Interfaces O que vocês acharam dessa nossa implementação? Na opinião de vocês, o sistema ficou com alto ou baixo acoplamento? Resp.: baixo acoplamento! Novas classes podem ser adicionadas com capacidade de autenticação, e sem necessidade de alterar a classe SistemaInterno, responsável pelo login. Padrões de Projeto - Revisão de POO

Interfaces Dicas sobre interfaces: Programe sempre pra uma superclasse!  Polimorfismo As interfaces são uma ótima maneira de manter baixo acoplamento no seu projeto. Identifique os comportamentos que são comuns e crie interfaces para eles, assim você poderá adicionar novas entidades sem precisar alterar muito código. Regras Uma classe qualquer pode implementar várias interfaces; Uma interface qualquer pode estender uma ou várias interfaces; Com isso, a interface “adiciona” novos métodos ao seu contrato; Interfaces não contêm implementações concretas; Classes não-abstratas que implementam interfaces devem fornecer implementação para os métodos da interface Classes abstratas podem deixar de implementar um ou mais métodos da interface; Interfaces não são instanciáveis, mas suas subclasses as são (e assim brincamos com o polimorfismo). Padrões de Projeto - Revisão de POO

Continua com dúvidas em algum desses conceitos Continua com dúvidas em algum desses conceitos? Estude bastante e procure o professor para tirar dúvidas. Se você não se sentir confortável com boa parte dos conceitos de OO, há uma grande probabilidade de você não obter bons resultados nessa disciplina! Padrões de Projeto - Revisão de POO

Padrões de Projeto - Revisão de POO

Referências Essa aula utilizou os exemplos das apostilas caelum. Padrões de Projeto - Revisão de POO