Curso Java Básico: Orientação a Objetos

Transcript

1. Marco Paulo Ollivier Software Engineer @ OLX Desenvolvimento básico em Java Paradigma Orientado a Objetos com Java
2. Objetivos da Aula 1. Entender os principais conceitos de O.O. 2. Aplicar os conceitos apresentados 3. Ver características particulares ao Java
3. Requisitos Básicos ü Noções básicas de lógica de programação ü Noções básicas da sintaxe do Java
4. Agenda Ø Paradigma O.O. Ø Construtores Ø Encapsulamento Ø Herança Ø Polimorfismo Ø Abstrações Ø O This e o Super Ø Hash Code e Equals Ø Casting
5. Código do material https://github.com/marcopollivier/DigitalInnovationOne- CursoBasicoJava
6. [Nome do palestrante] [Posição] [Nome do curso] [Nome da aula] Parte 1: O Paradigma Orientação a Objetos
7. O Paradigma O.O. “A programação Orientada a Objetos impõe disciplina sobre a transferência indireta do controle” Robert “Uncle Bob” Martin livro Arquitetura Limpa
8. O Paradigma O.O. “… a pilha de chamadas funções na linguagem (estruturada) ALGOL poderia ser movida para HEAP (área de memória não necessariamente ordenada, diferente da stack)possibilitando que as variáveis locais declaradas por uma função existissem muito depois que a função retornasse…” Robert “Uncle Bob” Martin livro Arquitetura Limpa
9. O Paradigma O.O. “A diferença entre um Código Procedural e um O.O é bem simples. Em códigos procedurais (…) escolher o melhor algoritmo é o mais importante (…) Já em linguagens orientado a objetos (…) pensar no projeto de classes (…) como se encaixam (…) e como serão estendidas é o que mais importa.” Maurício Aniche livro Orientação a Objetos e SOLID para Ninjas
10. O Paradigma O.O. Classe Vamos entender uma classe como um modelo a ser seguido. Uma classe vai funcionar como uma espécie de molde que nos servirá como base para construir algo.
11. O Paradigma O.O. Classe Por exemplo. Quando pensamos em construir uma casa, nós fazemos uma planta baixa. Ela será o modelo que utilizaremos para construir algo concreto. As classes funcionam de forma parecida. Vamos a um exemplo prático.
12. O Paradigma O.O. Classe
13. O Paradigma O.O. Objeto Agora que entendemos que temos um modelo que podemos seguir. O que podemos fazer com esse modelo? Bom... Nós fizemos a analogia da casa, certo? Depois de termos a planta baixa, nós começamos a construir. E o resultado do que nós construímos, vamos chamar de objeto.
14. O Paradigma O.O. Objeto Quando nós utilizarmos a nossa classe Pessoa - mostrada no código anterior – para criar um objeto, nós diremos que estamos instanciando um objeto da classe Pessoa. E esse termo é bem simples de entender. O que acontece é que podemos criar vários objetos de uma mesma classe, ou seja, várias instâncias de objetos.
15. O Paradigma O.O. Objeto Quando nós utilizarmos a nossa classe Pessoa - mostrada no código anterior – para criar um objeto, nós diremos que estamos instanciando um objeto da classe Pessoa E esse termo é bem simples de entender. O que acontece é que podemos criar vários objetos de uma mesma classe, ou seja, várias instâncias de objetos.
16. O Paradigma O.O. Objeto
17. O Paradigma O.O. Atributos Agora vamos pensar no que nos definimos como nome. Foi tão intuitivo nós pensarmos que uma pessoa teria um nome que nem demos importância a ele. O nome é uma característica de uma Pessoa e pode ser diferente de pessoa para pessoa. O nome é um atributo da pessoa.
18. O Paradigma O.O. Atributos Agora vamos pensar no que nos definimos como nome. Foi tão intuitivo nós pensarmos que uma pessoa teria um nome que nem demos importância a ele. O nome é uma característica de uma Pessoa e pode ser diferente de pessoa para pessoa. O nome é um atributo da pessoa.
19. O Paradigma O.O. Métodos Agora vamos pensar que uma pessoa pode ter ações. Por exemplo, uma pessoa pode falar. Pensando em um cenário mais específico, uma pessoa pode falar o seu nome. As ações que nós definimos que uma classe pode ter, nós chamamos de métodos.
20. O Paradigma O.O. Métodos
21. Exercício final Crie uma classe Carro. Nessa classe você deverá ter a quantidade de pessoas que estão dentro do carro. E também é preciso que tenha uma forma de adicionar e remover pessoas de dentro do carro.
22. [Nome do palestrante] [Posição] [Nome do curso] [Nome da aula] Parte 2: Construtores Orientação a Objetos
23. Construtores Podemos entender o termo construtor no sentido literal, afinal vamos construir um objeto. Por meio de um construtor, criamos um objeto baseado em uma Classe e assim o alocamos em memória. Ao criarmos um objeto dizemos que estamos instanciando um objeto.
24. Construtores
25. Construtores
26. Construtores Esse exemplo que acabamos de ver é o exemplo mais comum quando começamos a estudar construtores em Java. E para instanciar essa classe (criar um objeto dela) fazemos o seguinte:
27. Construtores Notou a diferença entre as duas classes? Não? Então vamos ver novamente... Depois vamos ver o que elas têm em comum.
28. Construtores
29. Construtores O que elas tem em comum? A maneira como são instanciadas!
30. Construtores Quando não temos um construtor padrão (sem parâmetros) definidos em uma classe, é subentendido que temos um construtor desse tipo na classe. Mas cuidado! Isso só vale quando não tiver outro construtor definido.
31. Construtores Também podemos criar construtores parametrizados. Dessa forma, conseguimos definir um contrato onde sempre será obrigatório passar alguma informação na hora de instanciar a classe.
32. Construtores Nesse exemplo temos dois construtores. Um com passagem de parâmetro e outro sem. Isso garante que possamos instanciar das duas maneiras.
33. Construtores
34. Construtores Já quando definimos nossa classe dessa forma, se tentarmos instanciar a classe sem passar algum parâmetro no construtor, tomaremos erro em tempo de compilação.
35. Construtores
36. Construtores E existe um destrutor? Em Java não existe o conceito de destrutor explícito. Lembra que falamos que quando instanciamos, estamos, na verdade, alocando o objeto em memória? Pois bem... Desalocar esse objeto fica por conta do GC.
37. Exercício final Crie um classe Carro com os attributor: - Marca: String - Modelo: String - Ano: Integer - Variante: String - Essa classe deve garantir que Modelo, Marca e Ano sempre sejam passados na hora de instanciar um objeto.
38. [Nome do palestrante] [Posição] [Nome do curso] [Nome da aula] Parte 3: Encapsulamento, Herança e Polimorfismo Orientação a Objetos
39. Encapsulamento Mais uma vez vamos entender o termo que estamos trabalhando ao pé da letra. Quando falamos de encapsulamento, estamos falando efetivamente em proteger alguma informação de alguma forma, ou seja, com uma cápsula.
40. Encapsulamento Vamos ver como podemos trabalhar com o encapsulamento nos nossos exemplo anterior da Classe Pessoa. Na nossa classe, vamos manipular basicamente 2 atributos: - Nome; - Data de nascimento.
41. Encapsulamento
42. Encapsulamento
43. Encapsulamento Mas afinal o que queremos? Queremos garantir a nossa implementação e que o acesso a determinados dados estão realmente protegidos do acesso externo.
44. Encapsulamento Mas afinal o que queremos? Para esse exemplo específico: - Queremos que o nome possa ser alterado. Vamos pensar que uma pessoa pode casar e mudar seu nome; - Não queremos alterar a data de nascimento. A pessoa nasce com ela e não pode mudar; - Queremos de alguma forma retornar a idade da pessoa.
45. Encapsulamento
46. Encapsulamento
47. Encapsulamento - Defino meu nome e minha data de nascimento no contrato; - Consigo mudar meu nome posteriormente; - Consigo ler meu nome a qualquer momento; - Consigo apenas ler minha data de nascimento; - Consigo calcular quantos anos eu tenho sem precisar conhecer a implementação.
48. Herança Vamos agora falar de outro pilar importante da Orientação Objetos: a Herança Como o próprio nome já diz, essa é a capacidade de uma Classe herdar o comportamento de outra. Exemplo:
49. Herança Vamos pensar em um cenário onde queremos modelar um veículo.
50. Herança Vamos pensar em um cenário onde queremos informações de diversos tipos de veículos. Por exemplo: quero colocar a quantidade de portas para o caso de carros e as cilindradas em casos de motocicletas.
51. Herança
52. Herança
55. Herança Depois de definir os getters e setters...
56. Herança Também aproveitamos comportamentos... Nesse cenário, temos o método acelera() na classe veiculo.
57. Herança vs Composição Existe um vasto e antigo debate em relação a utilização de herança. Algumas bibliografias inclusive defendem que ela nunca deve ser utilizada. E o grande problema tem relação com o nosso tópico anterior: o encapsulamento.
58. Herança vs Composição A subclasse necessita conhecer, em muitos casos, a implementação da superclasse, o que cria um acoplamento e quebra a nossa premissa básica do isolamento que vimos no encapsulamento.
59. Polimorfismo Quando falamos em herança, o verbo ser é mandatório na nossa forma de falar sobre a classe. Entendemos, portanto, que um carro é um veículo e uma motocicleta também é um veículo.
60. Polimorfismo Quando falamos de Polimorfismo, estamos querendo entrar em um cenário onde um objeto pode ser referenciado de várias maneiras. Vamos continuar no nosso exemplo de veículos...
61. Polimorfismo Agora no nosso exemplo, nós queremos colocar mais uma característica e uma ação que podem ser comuns aos dois, mas com algumas peculiaridades. Agora vamos querer calcular o valor aproximado do IPVA dos nossos diferentes tipos de veículos.
62. Polimorfismo Tanto carros quanto motos pagam IPVA, certo? E o cálculo é baseado no valor venal do veículo. Portanto a primeira conclusão que chegamos é que temos uma característica nova na nossa Classe de Veículos, agora temos o valor venal, portanto:
63. Polimorfismo
64. Polimorfismo Mas precisamos calcular a nossa precisão de imposto. Vamos partir do princípio que (valores hipotéticos): - Um veículo teria que pagar, no mínimo, 0,01% do valor venal de IPVA; - Um carro teria que pagar, no mínimo, 0,07% do valor venal de IPVA; - Uma moto teria que pagar, no mínimo, 0,03% do valor venal de IPVA.
65. Polimorfismo Para isso precisaremos definir implementações diferentes de acordo com a classe que estamos trabalhando. E é onde entraria o Polimorfismo. Ele nos garantirá a capacidade de um objeto ser referenciado de múltiplas formas.
66. Polimorfismo O Java será capaz de identificar qual objeto foi instanciado e, assim, escolher qual método será utilizado. Vamos ver como ficaria...
67. Polimorfismo
68. Polimorfismo
69. Polimorfismo
70. Polimorfismo
71. Exercício final Vamos pensar em um cenário onde temos Funcionários. Esses funcionários podem ser: Gerente, Supervisor e Atendente. Cada tipo de funcionário desses tem políticas diferentes de impostos: - Gerente paga 0,1% do salário; - Supervisor paga 0,05% do salário; - Atendente paga 0,01% do salário. Monte um modelo que atenda esse cenário.
72. [Nome do palestrante] [Posição] [Nome do curso] [Nome da aula] Parte 4: This, Super, Equals e HashCode Orientação a Objetos
73. This Quando estamos trabalhando com o termo this, no Java, estamos, na verdade, fazendo uma auto referência. Esse conceito faz mais sentido quando estamos falando de construtores e métodos, exemplo:
74. This
75. Super Analogamente ao This, quando falamos no Super também estamos fazendo uma referência, mas dessa vez estamos fazendo referência a superclasse em um cenário de herança.
76. Super Atenção! Como em Java, todas as nossas classes herdam de Object, se usamos o super em uma classe que não tem um extends explícito, estamos fazendo referência ao Object.
77. Super Vamos mudar um pouco o nosso exemplo. Primeiro vamos transformar a nossa classe veículo. Ela vai passar a ser uma classe abstrata e, portanto, não poderá mais ser instanciada. E também vamos definir que o construtor dessa classe sempre irá esperar o modelo, a marca e o valor venal.
78. Super
79. Super Aqui vemos outra vez a aplicação do this. No nosso construtor recebemos os parâmetros e fazemos uma auto referência aos nossos atributos
80. Super Aqui vemos outra vez a aplicação do this. No nosso construtor recebemos os parâmetros e fazemos uma auto referência aos nossos atributos
81. Super
82. Super
83. Equals Como sabemos, todas as classes em Java herdam de Object. E, portanto, tem por padrão alguns métodos. Um deles é o equals que serve para fazer comparações entre objetos. Entretanto esse método possui algumas peculiaridades.
84. Equals Por padrão, quando estamos comparando dois objetos, estamos comparando a referência deles. Então se instanciarmos dois carros, por mais que eles tenham exatamente as mesmas informações, o Java não é capaz de identificar. Vejamos...
85. Equals
86. Equals Mas poderíamos sobrescrever o método equals() para que nossa lógica funcione do jeito que gostaríamos. Tenha em mente que é uma boa prática sobrescrever este método.
87. Equals
88. HashCode Quando falamos em hashCode, precisamos pensar em um código gerado que garanta um caráter único ao nosso objeto. Essa pode ser uma forma muito interessante para que possamos comparar se realmente um objeto é igual ao outro.
89. HashCode Temos que garantir que a implementação da lógica de hashCode sempre respeite as mesmas regras, pois quando compararmos os nossos objetos, o nosso fator de comparação será ele.
90. HashCode Exemplo: Anteriormente utilizamos o método equals() para fazer a comparação entre dois objetos. Entretanto, nós fizemos essa comparação utilizando explicitamente 3 atributos: modelo, marca e valor venal.
91. HashCode Exemplo: Sendo que poderíamos transferir essa responsabilidade para nosso hashCode.
92. HashCode
93. [Nome do palestrante] [Posição] [Nome do curso] [Nome da aula] Dúvidas? Orientação a Objetos