2 – Revisão de Programação Orientada a Objetos

Apresentação em tema: "2 – Revisão de Programação Orientada a Objetos"— Transcrição da apresentação:

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

2 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

3 Parte 2 Composição, agregação, associação Herança Reescrita Sobrecarga
"O homem absurdo é aquele que nunca muda.“ - Georges Clemenceau Composição, agregação, associação Herança Reescrita Sobrecarga Polimorfismo Padrões de Projeto - Revisão de POO Parte 2

4 Composição, Agregação e Associação
Um trem é formado por 1 locomotiva e n vagões; Relacionamento tem-um; Agregação Uma locomotiva (todo) tem um farol (parte), mas não deixa de existir se não o tiver; Associação Um trem usa uma estrada de ferro (a estrada não faz parte do trem, mas ele depende dela). Padrões de Projeto - Revisão de POO Composição: quando algum objeto é formado pela COMPOSIÇÃO, ou seja, pela existência conjunta de outros objetos. Logo, se um desses objetos deixar de existir, o todo deixa de existir. Agregação: como o próprio nome diz, é quando algum objeto (parte) agrega valor a um outro objeto (todo), de modo que o objeto “parte” esteja contido num “todo”. Se essa parte deixa de existir, o todo não deixa de existir (apesar de poder ser afetado), já que ela apenas AGREGA (que significa soma) valor ao todo. Associação: relação de dependência (o trem não deixa de existir sem a estrada de ferro, mas também não pode funcionar)

5 Herança Objetivo 1: reuso de código. Praticando! (10 minutos)
Imagine o sistema de um banco... Nesse sistema precisamos armazenar dados de funcionários (que podem exercer diferentes funções, ex.: secretário ou gerente) e clientes. Vamos modelar essa parte do sistema!  Padrões de Projeto - Revisão de POO Começa descrevendo um Secretário e um Gerente. Mostra a duplicação de código, e refaz herdando de uma superclasse Funcionário. ... Fala um pouco de alteração de código. E se ao invés de apenas uma variável nome, nós quiséssemos 2 variáveis: primeiroNome e últimoNome? Seria preciso reescrever esse trecho em ambas as classes. Logo, joga o código duplicado pra uma superclasse mais genérica. Com a duplicação de código em Cliente e Funcionário, cria uma outra classe chamada Pessoa com a interseção do código entre elas.

6 Herança Relacionamento É-UM  em java, instanceof
Padrões de Projeto - Revisão de POO A seta representa uma generalização, ou seja, extends (da herança). Como é que a gente testa o relacionamento É-UM? (instanceof)

7 Herança Objetivos: Palavras-chave: Reuso de código; Polimorfismo.
extends: para herdar as caraterísticas de uma classe; Instanceof: para testar relacionamentos É-UM entre objetos Padrões de Projeto - Revisão de POO

8 Quais seriam as implicações dessa nova abordagem?
Se não houvesse herança em Java, como você poderia reaproveitar o código de outra classe? Quais seriam as implicações dessa nova abordagem? Padrões de Projeto - Revisão de POO Resposta: composição.

9 Herança vs Composição Herança: quando uma classe herda a outra, ela está muito ligada à outra Composição: estende uma classe através da delegação de trabalho a ela Exemplo: Carro Imagine que você criou um carro com vários utilitários, ex.: GPS, direção hidráulica, injeção eletrônica. Então, no seu sistema você percebe que precisa lidar com carros Opala, mas Opala não tem GPS nem inj. eletrônica. Como poderíamos resolver isso? Próxima aula aprenderemos uma solução com o nosso 1º padrão de projeto.  Padrões de Projeto - Revisão de POO Nos aprofundaremos posteriormente.

10 Overriding Outros nomes: sobrescrever (overwriting), reescrever, sobrepor... Praticando! (10 minutos) No exemplo anterior, suponha que os funcionários, de modo geral, ganhem uma bonificação de 10%. Mas, devido o fato do gerente ter mais responsabilidade, seria justo que ele ganhasse uma bonificação de 20% de seu salário. Como nós alteraríamos o nosso modelo para satisfazer essa nova especificação? (modele/implemente apenas as classes Funcionário e Gerente) Padrões de Projeto - Revisão de POO

11 Overriding public double getBonificacao(){ return 0.1*this.salario; }
Padrões de Projeto - Revisão de POO public double getBonificacao(){ return 0.2*this.salario; }

12 Overriding Objetivo: especializar um método herdado.
Regras para sobrescrever um método: A assinatura deve ser igual ou bem similar: Lista de argumentos exatamente igual; Tipo de retorno deve ser “igual” (lembrar da relação É-UM, pois subtipos também são aceitos); Modificador de acesso pode ser menos restritivo; Para haver reescrita deve, primeiramente, haver herança. Mais regras em: Livro de Certificação Java SCJP Sun Certified Programmer for Java 6 OCP Java SE 6 Programmer Padrões de Projeto - Revisão de POO Métodos sobrepostos nunca podem ter menos acesso que os métodos originais. ƒSe método original for public, novas versões têm que ser public. ƒSe método original for protected, novas versões podem ser protected ou public . Se método original não tiver modificador de acesso (é "package-private"), novas versões podem ser declaradas sem modificador de acesso, com modificador protected ou public. ƒSe método original for private, ele não será visível da subclasse e portanto, jamais poderá ser estendido e reescrito.

13 Overloading Outro nome: sobrecarregar, ...
Padrões de Projeto - Revisão de POO

14 Overloading Objetivo: prover ao usuário a possibilidade de executar uma funcionalidade do sistema passando diferentes inputs (tipos de dados) É basicamente a uma outra implementação de um método já existente mas com argumentos diferentes. Regras para sobrecarregar um método... Os métodos sobrecarregados devem alterar a lista de argumentos; Os métodos sobrecarregados podem alterar o tipo de retorno; Os métodos sobrecarregados podem alterar o modificador de acesso; Um método pode ser sobrecarregado na mesma classe ou em uma subclasse. Também é possível sobrecarregar um construtor. Mais regras em: Livro de Certificação Java SCJP Sun Certified Programmer for Java 6 OCP Java SE 6 Programmer Padrões de Projeto - Revisão de POO

15 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

16 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

17 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

18 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.

19 Referências Essa aula utilizou alguns exemplos modificados das apostilas caelum além de alguns conceitos e exemplos abordados na apostilas para certificação java (SCJP e OCJP). Ahhh, alguns destes exemplos também saíram da minha cabeça.  Padrões de Projeto - Revisão de POO