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
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.
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.
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.
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.
Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Refactoring Desacoplamento
• O projeto será refatorado para eliminar os
acoplamentos;
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
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.
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.
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.
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.
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
Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Server
• Deverão ser copiadas as bibliotecas do
hibernate e JavaDB
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.
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.
Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Server
• A implementação também deverá ser
alterada.
Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Server
• Deverá ser criada uma classe Principal que
irá executar o servidor.
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.
Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Exportando o serviço para a
aplicação cliente
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;
Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Client
• Deverão ser corrigidas as classes
ClienteControl e ServiceLocator.
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
Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Client – classe
ClienteControl
• Em ClienteControl, as exceções
RemoteException devem ser propagadas
para ClienteView
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.
Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Client – classe
ClienteView
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.
Prof Carlos Eduardo Dantas – carloseduardodantas@iftm.edu.br
Sistema Client – executar
• Ao executar o client, observa-se que foi
gerado log do lado servidor
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.
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.
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.
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”.

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

  • 1.
    Programação Orientada aObjetos 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 EduardoDantas – 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 EduardoDantas – 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 EduardoDantas – 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 EduardoDantas – 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 EduardoDantas – carloseduardodantas@iftm.edu.br Refactoring Desacoplamento • O projeto será refatorado para eliminar os acoplamentos;
  • 7.
    Prof Carlos EduardoDantas – 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 EduardoDantas – 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 EduardoDantas – 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 EduardoDantas – 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 EduardoDantas – 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 EduardoDantas – carloseduardodantas@iftm.edu.br Sistema Server • Deverão ser copiados os fontes do model, e criado um novo folder chamado lib
  • 13.
    Prof Carlos EduardoDantas – carloseduardodantas@iftm.edu.br Sistema Server • Deverão ser copiadas as bibliotecas do hibernate e JavaDB
  • 14.
    Prof Carlos EduardoDantas – 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 EduardoDantas – 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 EduardoDantas – carloseduardodantas@iftm.edu.br Sistema Server • A implementação também deverá ser alterada.
  • 17.
    Prof Carlos EduardoDantas – carloseduardodantas@iftm.edu.br Sistema Server • Deverá ser criada uma classe Principal que irá executar o servidor.
  • 18.
    Prof Carlos EduardoDantas – 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 EduardoDantas – carloseduardodantas@iftm.edu.br Exportando o serviço para a aplicação cliente
  • 20.
    Prof Carlos EduardoDantas – 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 EduardoDantas – carloseduardodantas@iftm.edu.br Sistema Client • Deverão ser corrigidas as classes ClienteControl e ServiceLocator.
  • 22.
    Prof Carlos EduardoDantas – 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 EduardoDantas – carloseduardodantas@iftm.edu.br Sistema Client – classe ClienteControl • Em ClienteControl, as exceções RemoteException devem ser propagadas para ClienteView
  • 24.
    Prof Carlos EduardoDantas – 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 EduardoDantas – carloseduardodantas@iftm.edu.br Sistema Client – classe ClienteView
  • 26.
    Prof Carlos EduardoDantas – 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 EduardoDantas – carloseduardodantas@iftm.edu.br Sistema Client – executar • Ao executar o client, observa-se que foi gerado log do lado servidor
  • 28.
    Prof Carlos EduardoDantas – 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 EduardoDantas – 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 EduardoDantas – 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 EduardoDantas – 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”.