Programação Orientada a Objetos - Pós Graduação - Aula 3

441 visualizações

Publicada em

Slides da terceira aula de Programação Orientada a Objetos no curso de Pós Graduação em Análise e Desenvolvimento Aplicados à Gestão Empresarial

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
441
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
14
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Programação Orientada a Objetos - Pós Graduação - Aula 3

  1. 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. 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. 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. 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. 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. 6. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br Refactoring Desacoplamento • O projeto será refatorado para eliminar os acoplamentos;
  7. 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. 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. 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. 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. 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. 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. 13. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br Sistema Server • Deverão ser copiadas as bibliotecas do hibernate e JavaDB
  14. 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. 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. 16. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br Sistema Server • A implementação também deverá ser alterada.
  17. 17. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br Sistema Server • Deverá ser criada uma classe Principal que irá executar o servidor.
  18. 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. 19. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br Exportando o serviço para a aplicação cliente
  20. 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. 21. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br Sistema Client • Deverão ser corrigidas as classes ClienteControl e ServiceLocator.
  22. 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. 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. 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. 25. Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br Sistema Client – classe ClienteView
  26. 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. 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. 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. 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. 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. 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”.

×