O documento discute programação orientada a objetos, acoplamento e desacoplamento de classes. Ele apresenta como refatorar um código com alto acoplamento entre classes para diminuir essa dependência e torná-lo mais flexível e mantível através da introdução de uma classe ServiceLocator. O documento também explica como separar a lógica de negócio de um sistema desktop em um servidor, de forma que ambos possam evoluir de forma independente.
Programação Orientada a Objetos - Pós Graduação - Aula 3
1. Programação Orientada a Objetos
Acoplamento
Pós Graduação em Análise e Desenvolvimento de Sistemas
Aplicados à Gestão Empresarial
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA
TRIÂNGULO MINEIRO – Campus Uberlândia Centro
Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
2. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Introdução
• Acoplamento significa o quanto uma
classe depende de outra para funcionar;
• Quanto maior for esta dependência entre
ambas, mais fortemente acopladas estão
essas classes.
3. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Introdução
• Uma alteração em uma classe
provavelmente irá resultar em alterações
nas suas dependências;
• Complica a manutenção e o
gerenciamento das classes.
4. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Introdução
• Observa-se que a classe ClienteControl
está fortemente acoplada com
ClienteDaoImpl(), assim como
ClienteView está com ClienteControl, pois
conhece-se a instância específica que irá
executar as solicitações.
5. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Introdução
• Uma simples analogia, seria como a classe
ClienteControl fosse um funcionário que
apertasse parafuso, e este precisasse saber
onde está a chave certa para executar tal
procedimento. Se a chave mudar de lugar,
o funcionário precisa saber. Este é um
problema clássico de manutenções em
sistemas, onde a mudança em um lugar
reflete em outros lugares.
6. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Refactoring Desacoplamento
• O projeto será refatorado para eliminar os
acoplamentos;
7. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Refactoring Desacoplamento
• Será criada a classe ServiceLocator, que irá
funcionar como se fosse um funcionário
do almoxarifado, que fornece a chave certa
8. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Refactoring Desacoplamento
• E neste caso, a classe ClienteControl está
delegando para a classe ServiceLocator
para entregar a instância certa.
9. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Refactoring Desacoplamento
• A princípio não parece que surgiram
muitas vantagens, mas agora a classe
ClienteControl apenas conhece a interface
e a classe que entrega a implementação
pronta, sem ter a menor idéia de quem
implementa a solução.
10. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Refactoring Desacoplamento
• É muito comum existirem sistemas
legados em desktop, onde em um certo
momento, surge a demanda de criar uma
versão para a web;
• Seria razoável desacoplar o model deste
sistema desktop, para que não seja
necessário reescrever o mesmo em um
sistema web, reaproveitando código.
11. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Server
• Será criado um projeto no Eclipse que
contempla a parte model, e o sistema
desktop escrito no NetBeans será um mero
cliente.
12. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Server
• Deverão ser copiados os fontes do model,
e criado um novo folder chamado lib
13. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Server
• Deverão ser copiadas as bibliotecas do
hibernate e JavaDB
14. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Server
• Todos os arquivos .jar deverão ser
importados clicando com o botão direito,
de acordo com a imagem abaixo.
15. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Server
• Será implementado um servidor de RMI,
que é apenas um serviço RPC com objetos.
Deve ser alterada a interface ClienteDao;
• É uma boa prática colocar o nome e a URL
do serviço na interface.
16. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Server
• A implementação também deverá ser
alterada.
17. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Server
• Deverá ser criada uma classe Principal que
irá executar o servidor.
18. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Server
• Desta forma, existe um servidor RMI
atendendo requisições na porta 1099;
• Basta que a aplicação cliente tenha a
interface ClienteDao, a classe de domínio
Cliente e a URL, para conseguir conectar
com o servidor.
19. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Exportando o serviço para a
aplicação cliente
20. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Client
• Deverão ser excluídos todos os arquivos
que foram exportados para o projeto
Server do Eclipse, e importar a biblioteca
que foi gerada no sistema Server;
21. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Client
• Deverão ser corrigidas as classes
ClienteControl e ServiceLocator.
22. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Client – classe
ServiceLocator
• A correção da classe ServiceLocator,
observe que a implementação de
ClienteDao mudou, e essa alteração
continua transparente para ClienteControl
23. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Client – classe
ClienteControl
• Em ClienteControl, as exceções
RemoteException devem ser propagadas
para ClienteView
24. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Client – classe
ClienteView
• Em ClienteView, as exceções devem ser
tratadas, mostrando para o usuário um
erro de conexão.
25. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Client – classe
ClienteView
26. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Client – alterando o
persistence.xml
• Crie duas propriedades, show_sql e
format_sql para visualizar as consultas sql
que o client demanda para o servidor, e
suba novamente o servidor.
27. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Client – executar
• Ao executar o client, observa-se que foi
gerado log do lado servidor
28. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Exercício
• Implementar uma estrutura de Pedido,
onde este possui data/hora, Cliente e
número;
• Esta estrutura deve salvar, atualizar,
excluir e alterar, ou seja, implementar
todas as operações de CRUD, igual foi
feito com a estrutura de Cliente.
29. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Desacoplamento da
ClienteView
• A ClienteControl foi desacoplada da
ClienteDaoImpl para que o sistema
pudesse ser separado em duas camadas
físicas;
• Dificilmente a classe ClienteView iria
precisar ser desacoplada da
ClienteControl para separação em
camadas físicas, já que o framework Beans
Binding e os componentes Swing são
exclusivos para aplicações GUI.
30. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Desacoplamento da
ClienteView
• De qualquer forma, é preferível o
desacoplamento, mesmo que a classe
fornecedora da implementação apenas
retorne a instância.
31. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Referências
• ANICHE, Maurício. Orientação a objetos e
SOLID para Ninjas. Casa do Código, 2015;
• GUERRA, Eduardo. Design Patterns com Java.
Casa do Código, 2014;
• “LARMAN, Craig – Utilizando UML e Padrões
3ª Edição. Bookman, 2007”.