Programação Orientada a Objetos - Pós Graduação - Aula 6 - Princípios OO

Programação Orientada a Objetos

Princípios OO

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 – [email protected]


Introdução

• Por que precisamos implementar baixo acoplamento, alta coesão, dentre tanto outros princípios e conceitos básicos em POO?


Curva de Defeitos do Hardware


Curva de Defeitos do Software


Análise - Curva de Defeitos

• Hardware se desgasta com o tempo;

• Software se deteriora com o tempo;

• Boa parte dos Software legados são migrados para novas tecnologias por deterioração, e não por necessidades tecnológicas.


Análise - Curva de Defeitos

• Um bom design de Software visa a uma arquitetura flexível que permita futuras alterações, facilitando a produção de código organizado e legível, maximizando seu reaproveitamento;

• Boas práticas OO procuram trazer os benefícios mencionados acima para o design.


Programe voltado à Interface, não à Implementação

• Contains() de ArrayList é uma busca muito custosa em termos computacionais;

• Alternativas de coleções, como HashSet, são mais eficientes, pois usam internamente uma tabela Hash.



• O problema ao efetuar esta manutenção, é que todo o código que usava o retorno do método ArrayList será quebrado, alterando todos os lugares que dependem de alguma forma desse método;

• Tarefas do tipo search/replace são um forte sinal de código ruim;

• Vincular os funcionários a uma implementação específica de Collection, caracteriza alto acoplamento.



• Quanto menos específica for a interface/classe referenciada, menor o acoplamento e mais possibilidades de diferentes implementações;

• Como consequência, o código cliente terá uma gama menor de métodos que podem ser invocados.



• Devemos procurar um balanço entre o desacoplamento e a necessidade do nosso código;

• Princípio de Segregação de Interfaces –clientes não devem ser forçados a depender de interfaces que não usam.



• Hibernate usa uma implementação específica de List, mas sempre retorna List para evitar quebra de compatibilidade com o código-fonte da aplicação cliente.



• E se quisermos receber objetos via socket (SocketInputStream), como faz?

• Utilize sempre o tipo menos específico possível.



• Geralmente, para a API JDBC, utiliza-se uma Connection, ao invés de OracleConnection, MysqlConnection, dentre outros.



• Interfaces irão ajudar muito para evitar instruções switch, ou mesmo um excessivo número de ifs encadeados, evitando acoplamentos no modelo, ocorrendo mudanças frequentes toda vez que uma nova entidade for adicionada no domínio.



• No projeto criado nas aulas anteriores, os casos abaixo estão respeitando esse princípio



• Contudo, ClienteView não está respeitando, gerando um alto acoplamento com ClienteControl.



• O certo seria criar interfaces e factoriespara o Control, visando desacoplar o máximo possível;

• Contudo, neste caso, como existe uma implementação de Beans Binding entre o view e o Control, o prejuízo deste acoplamento é bastante minimizado.


Componha Comportamentos

• Códigos são mais fáceis de entender e manter quando possuem poucas possibilidades de fluxos lógicos, ou seja, poucos caminhos de execução.



• Quantas possibilidades diferentes existem para a execução deste método?



• Existem diversas responsabilidades de execução para esta classe;

• Este comportamento pode ser composto por diversas partes menores, por isso refatorações podem ser executadas.



• Observa-se que, passando de estruturado para OO, o sistema ganhou

4 novas classes e uma

Interface.



• O comportamento foi quebrado em diversas partes, onde foram juntados novamente através de composição;

• O polimorfismo permite trabalhar de maneira uniforme com partes que executam tarefas distintas.



• Ao implementar os métodos da Interface Processo na classe Transferência, observa-se que o Princípio de Segregação de Interfaces foi violado.



• Neste caso, o ideal é quebrar as interfaces em uma hierarquia, assim como existe a hierarquia entre Collection e List/Set/Map;

• Caso o projeto não seja refatorado agora, existe uma grande chance de sofrer novo refactoring posteriormente, mesmo que a implementação deste método seja simples.


Evite Herança, favoreça composição

• O maior problema da Herança é que acoplamos a implementação da classe mãe muito precocemente, criando a necessidade da classe filha conhecer muito bem o código interno da classe mãe, o que é visto como quebra de encapsulamento.



• Exemplo: Herança entre Hashtable e Properties.



• A motivação dos desenvolvedores da JDK é válida: o reaproveitamento de código já escrito na classe Hashtable;

• Usar composição permite o reaproveitamento de código sem o efeito indesejado de quebra de encapsulamento;

• No exemplo da jdk, bastaria a classe Properties fazer associação para um Hashtable privado, e o método setProperty() delegar para a invocação de hashtable.put()



• Ao substituir herança por interface, as vantagens do polimorfismo permanecem, e o acoplamento é bem menor, já que nenhuma dessas classes precisam conhecer o funcionamento interno de outras, especialmente da classe mãe.



• No projeto das aulas anteriores, ficou claro que PedidoDaoImpl e ClienteDaoImplficaram livres com o comportamento de Composição


Cuidado com o modelo anêmico

• Um dos pilares de POO é que não se deve expor os detalhes de implementação;

• Encapsulando a implementação, pode-se trocar com facilidade, já que não existe outro código dependendo destes detalhes;

• O usuário poderá acessar o objeto através do contrato definido pela interface pública.



• No exemplo da classe Conta, o método setSaldo() feriu o encapsulamento, já que dificilmente o saldo de uma conta será simplesmente “substituído” por outro;

• Para alterar o saldo, faz mais sentido alguma operação como saque() e deposito();

• Nunca crie um getter/setter sem uma necessidade real;

• Códigos como conta.setSaldo(conta.getSaldo() + 100) estarão espalhados por toda a aplicação.



• Caso a aplicação precise modificar para que uma taxa seja debitada toda vez que for realizado um depósito, será necessário percorrer todo o código e modificar diversas invocações, usando search/replace.



• O código de exemplo é bem procedural, pois não possui atributos, e excesso do uso de métodos como funções;

• A classe Banco possui uma intimidade inapropriada com a classe Conta, pois conhece demais a sua implementação interna;

• Falta de uso do princípio Tell, Don´t Ask;

• Está rompendo o princípio básico de manter comportamento e estado relacionados em uma única classe.



• Enriqueça as classes com métodos de negócio, para que não se tornem apenas estruturas de dados;

• Algumas vezes getters/setters são necessários, mas cuidado no uso indiscriminado destes.



• No projeto da aula anterior, rapidamente foi percebido que para validar as entidades, nada melhor do que delegar este comportamento às mesmas.


Cuidado com objetos mutáveis

• Objetos mutáveis são passíveis de efeitos colaterais, gerando bugs indesejáveis.



• Objetos imutáveis são muito mais simples de manipular, e possuem comportamento previsível.



• Objetos mutáveis são imprevisíveis, pois no exemplo abaixo é impossível determinar que a saída será o ano atual;

• Como solução, muitos criam cópias defensivas dos objetos, como:


Referências

• SILVEIRA, Paulo, Guilherme. LOPES, Sérgio. MOREIRA, Guilherme, SEPPAT, Nico. KUNG, Fábio. Introdução à Arquitetura e Design de Software. Editora Campus, 2012;

• PRESSMAN, Roger. Engenharia de Software –Uma abordagem Profissional – 7ª edição, 2011;

• 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.

Programação Orientada a Objetos - Pós Graduação - Aula 6 - Princípios OO

Technology

Transcript of Programação Orientada a Objetos - Pós Graduação - Aula 6 - Princípios OO