O documento discute boas práticas de programação orientada a objetos em Java, incluindo encapsulamento, herança, interfaces, injeção de dependência e padrões de projeto como Strategy e Template Method. Ele também aborda princípios como responsabilidade única, substituição de Liskov e inversão de dependência.

1. JAVA: BOAS PRÁTICAS
Felippe Rodrigo Puhle
http://www.felippepuhle.com.br

2. PARTE 1
- Orientação a objetos
- Encapsulamento
- Polimorfismo
- Herança
- Classes abstratas
- Exceções

3. Interfaces
- É uma maneira de conversarmos com um objeto
- Pode definir uma série de métodos, mas nunca conter
a implementação deles
- Expõe o que o objeto deve fazer, e não como ele faz
ou o que ele tem
- “Contrato”

4. Interfaces
- O objetivo de uso é deixar o código mais flexível,
possibilitando uma mudança de implementação sem
maiores problemas
- Design patterns:
- evite herança, prefira composição
- programe voltado a interfaces
- Herança pode quebrar o encapsulamento: a partir do
momento que você precisa conhecer o código fonte da
sua mãe, você quebrou o encapsulamento)

5. Exemplo

6. Exemplo

7. DAO Genérico
- Ser um DAO ou ter um DAO?
- Todas as operações fazem sentido? E se quisermos
impossibilitar a exclusão no PagamentoDAO, por
exemplo?
- Liskov substitution principle(SOLID): em herança, a
classe filho nunca deve apertar as pré-condições ou
afrouxar as pós-condições.

8. DAO Genérico

9. Classes coesas
- Quando uma classe tem muitas responsabilidades com
pouca ou nenhuma relação entre si, dizemos que ela
não é coesa.
- Classes devem ter únicas responsabilidades, serem
pequenas e reutilizáveis.
- Single Responsibility Principle(SOLID): Princípio da
Responsabilidade Única. Tenha classes coesas.

10. Classes coesas

11. Classes coesas

12. Classes coesas
Ou, reduzindo o acoplamento:

13. Acoplamento
- A partir do momento em que eu tenho muitas
dependências, a minha classe depende de várias, que
podem propagar problema para a minha.
- “Tenha classes que são muito coesas e pouco
acopladas.”
kkkkkkkk

14. Acoplamento
- Evitar acoplamentos que são realmente perigosos e me
acoplar com coisas que são menos perigosas.
- Quando que é bom, e quando que é ruim?
- Exemplo: “Puxa, acoplar com List não é problema
porque List é uma interface que o Java fez. Vem na
linguagem Java”
- A resposta correta é: ela é estável, não muda.

15. Acoplamento
- Acoplamento eferente: eu, classe, dependo de outras.
- Acoplamento aferente: eu sou uma classe, e os outro
é quem dependem de mim.

16. Acoplamento
- O acoplamento aferente mostra que muitas outras
classes dependem de mim, e isso faz com que
eu(classe) seja estável.
- A chance de eu(classe) mudar é menor. Pois o
programador vai ter medo de alterar.
- “Programe voltado pra interface”
- Exemplo: utilização dos patterns Builder e Command.

17. Acoplamento
- Reduzir acoplamento usando polimorfismo.
Tell, Don't Ask
- você deve dizer ao objeto o que quer que ele faça ou retorne, e
não pedir sobre o seu estado para tomar decisões.
- exemplo: todos getters and setters em um Pedido
Lei de Demeter
- você deve ter conhecimento limitado sobre outras classes
- só deve saber coisas “próximas”
- fale apenas com “amigos”, e não “estranhos”
- exemplo: a().b().c() -> a().b()

18. Boas práticas de POO
- Seja objetivo, não tente prever o futuro
- Crie seus métodos com carinho
- Conheça e use coleções
- Sobrescreva equals, hashCode e toString
- Às vezes é melhor associar em vez de herdar
- Se preocupe com o encapsulamento
- Saiba usar interface e classe abstrata no momento certo
- Use e abuse das facilidades fornecidas por linguagens
orientadas a objetos
- Conheça e utilize as convenções de codificação da linguagem

19. Injeção de dependências
- É uma maneira de uma classe “pedir” uma determinada
dependência(outra classe)
- Geralmente esta classe que necessita de uma
determinada dependência não conhece(e nem deve
conhecer) muitas das coisas sobre a classe:
- Ciclo de vida, construção, implementações de métodos
e até mesmo sua destrução.
- Exemplo: banco de dados.

20. Injeção de dependências

21. CDI
- CDI é uma especificação do Java EE voltada a injeção
de dependências, mas que pode ser utilizada
naturalmente no Java SE.
- Com o CDI habilitado, praticamente todas as classes
do projeto são consideradas managed beans e,
portanto, passíveis de injeção e de serem injetadas.
- Podemos usar com CDI toda classe pública com um
construtor público padrão ou algum que receba
parâmetros e esteja anotado com @Inject.

22. CDI – Primeira injeção
- Basta usar a anotação @Inject

23. CDI – Producers
- Objetos complexos de serem criados
- Utilização do pattern Factory

24. CDI – Scopes
- Gerenciamento do ciclo de vida dos beans
- Uma instância por chamada, uma instância pra
aplicação, uma instância por requisição, etc.

25. Por que CDI?
- Separação de responsabilidades
- Inversão de controle
- Melhora o encapsulamento
- Gerenciamento do ciclo de vida
- Desacoplamento de processos

26. Próximos passos - Patterns
- Strategy
- Chain of Responsibility
- Template Method
- Decorator
- State
- Builder
- Observer

27. Próximos passos - Patterns
- Factory
- Flyweight
- Memento
- DSLs
- Interpreter
- Visitor
- Bridges
- Adapters
- Command
- Facade
- Singleton

28. Próximos passos - SOLID
- Single responsibility principle
- Open/closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle

29. OBRIGADO!