fundamentos e princípios do projeto orientado a objetos
TRANSCRIPT
![Page 2: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/2.jpg)
2
Abstração
Seleção de alguns aspectos relevantes a uma determinada análise, suprimindo outros
Serviços e atributos aplicáveis a objetos dentro de um determinado contexto
![Page 3: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/3.jpg)
3
Classes e Objetos
Classe
Descrição de um conjunto de objetos similares
Abstratas ou Concretas
Objeto
Reúnem na mesma estrutura:
Atributos (dados) que definem o estado
Operações que definem o comportamento e manipulam os dados
Identidade de objetos
Retenção de estado
![Page 4: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/4.jpg)
4
Encapsulamento
Esconder detalhes de implementação do estado e comportamento do objeto
Objetos são acessados apenas pela interface externa definida para eles
Detalhes de implementação das classes podem ser alterados sem que as aplicações necessitem de alterações
![Page 5: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/5.jpg)
5
Mensagem
Comunicação feita entre objetos
Chamadas a métodos
![Page 6: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/6.jpg)
6
Herança
Permite que novas classes sejam construídas usando código e características declaradas em outras classes
Relação do tipo “é um” entre classes
Super-classes e sub-classes
Sub-classe herda todos atributos e métodos da super-classe
![Page 7: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/7.jpg)
7
Polimorfismo
Propriedade na qual uma chamada genérica de um método pode ser executada de diferentes maneiras de acordo com o objeto que fez a chamada
Exemplo
Classe Reta: método desenhar()
Classe Círculo: método desenhar()
![Page 8: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/8.jpg)
8
Relacionamentos
Associação
Relação do tipo “tem um” entre objetos
Agregação
Relação do tipo “todo-parte”
Dependência fraca
Composição
Relação do tipo “todo-parte”
Dependência forte
![Page 9: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/9.jpg)
9
Interdependência
Elementos que compartilham alguma necessidade
Tipos de Interdependência
Nome
Tipo ou classe
Convenção
Algoritmo
Posição
Valor
Identidade
![Page 10: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/10.jpg)
10
Interdependência
Princípios
Minimizar a interdependência total através do encapsulamento
Minimizar qualquer interdependência que cruze as fronteiras do encapsulamento
Maximizar a interdependência dentro das fronteiras do encapsulamento
Abusos
Função amigável
Herança sem restrição
Detalhes internos do algoritmo de uma classe relevantes para outras classes
![Page 11: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/11.jpg)
11
Domínios
Domínio de Aplicação
Domínio de Negócio
Domínio de Arquitetura
Domínio de Base
Baixareutilização
Médiareutilização
Altareutilização
Domínio de Apresentação
![Page 12: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/12.jpg)
12
Grau de dependência ou acoplamento
Conjunto de classes que uma classe se baseia para operar
Grau de dependência pode ser
Direto
Indireto
Classes em domínios altos tem alto grau de dependência indireto e classes em domínios baixos tem baixo grau de dependência indireto
![Page 13: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/13.jpg)
13
Grau de dependência ou acoplamento
Acoplamento é o caminho para o Lado Negro da Força!
Conduz para complexidade
Conduz para confusão
Conduz ao sofrimento
Uma vez que você inicie o caminho para o Lado Negro, ele sempre irá dominar seu destino. “Consumir você ele irá!”
Desacoplar através de abstrações e interfaces!
![Page 14: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/14.jpg)
14
Lei de Demeter
Cada unidade deve conhecer apenas unidades intimamente relacionadas a ela
Segundo a Lei de Demeter as mensagens devem ser enviadas apenas para:
si mesmo - métodos do objeto
seus objetos - atributos da instância
parâmetros recebidos pelo método
objetos criados pelo método
![Page 15: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/15.jpg)
15
Coesão
Classes com alta coesão
Todas as características contribuem para a abstração de tipo implementada pela classe
Classes com baixa coesão
Apresenta um conjunto de características diferentes
![Page 16: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/16.jpg)
16
Problemas de coesão
Coesão de instância mista
Ter algumas características que são definidas apenas para alguns objetos da classe
Coesão de domínio misto
Uma classe contém um elemento que cria dependência com uma classe de domínio diferente que não tem qualquer tipo de negócio com a classe*
Coesão de papel misto
Uma classe contém um elemento que diretamente cria dependência de uma classe de mesmo domínio que não tem qualquer tipo de negócio com a classe*
* Uma classe B não tem qualquer tipo de negócio com A se A puder ser plenamente definida sem qualquer noção de B
![Page 17: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/17.jpg)
17
Problema: Coesão de instância mista
![Page 18: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/18.jpg)
18
Problema: Coesão de domínio misto
![Page 19: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/19.jpg)
19
Problema: Coesão de papel misto
![Page 20: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/20.jpg)
20
Espaço-estado e comportamento
Espaço-estado de uma classe é a totalidade de estados permitidos para qualquer objeto da classe
Cada componente do estado (atributos) de um objeto define uma dimensão
É o conjunto de valores de dimensões válidas para um objeto
O modo como o objeto muda de estado é o seu comportamento
O comportamento permitido de uma classe é o conjunto de transições que o objeto pode fazer entre os estados do espaço-estado
![Page 21: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/21.jpg)
21
Espaço-estado e comportamento
O espaço-estado de uma subclasse deve estar contido inteiramente dentro do espaço-estado da superclasse
O espaço-estado de uma subclasse pode ter mais dimensões que a superclasse
![Page 22: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/22.jpg)
22
Invariante de classe
Condição que todo objeto da classe deve satisfazer em todo o seu ciclo de vida
São restrições no espaço-estado do objeto
A invariante nunca deve ser quebrada
![Page 23: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/23.jpg)
23
Pré-condições e pós-condições
Devem garantir a invariante do objeto
Toda operação tem uma pré-condição e uma pós-condição
A pré-condição é uma condição que deve ser verdadeira quando a operação começar a executar
A pós-condição é uma condição que deve ser verdadeira quando a operação finalizar sua execução
![Page 24: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/24.jpg)
24
Conformidade de tipo
Um sub-tipo deve se conformar a seu super-tipo
O sub-tipo pode ser utilizado em qualquer contexto em que o super-tipo seja esperado
A invariante da subclasse deve ser pelo menos tão forte quanto a invariante da super-classe
A pré-condição de qualquer operação deve ser igual ou menos restritiva que a operação correspondente da super-classe
A pós-condição de qualquer operação deve ser igual ou mais restritiva que a operação correspondente na super-classe
![Page 25: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/25.jpg)
25
Comportamento fechado
O comportamento herdado deve respeitar a invariante da sub-classe
Nem sempre é possível, neste caso deve-se efetuar alguma ação corretiva
evitar herança dos métodos que não respeitem a invariante
suprimir os métodos de modo que ele não tenha efeito (possivelmente lançando uma exceção)
estar preparado para reclassificar o objeto
![Page 26: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/26.jpg)
26
Projeto de Qualidade
Fácil de entender
Fácil de alterar
Fácil de reusar
![Page 27: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/27.jpg)
27
Projeto Ruim
Rígido
Difícil de alterar
Uma alteração requer uma cascata de outras alterações
Impacto das alterações não consegue ser previsto
Frágil
A cada alteração novos erros aparecem em áreas aparentemente desconectadas
Imobilizado
Sem muita possibilidade de reuso
Partes desejadas de um componente possui muitas partes indesejadas para o reuso
![Page 28: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/28.jpg)
28
Projeto Ruim
Pegajoso
Alterações corretas são mais difíceis de fazer que as erradas (bacalhau!)
Obscuro
Difícil de entender
Complexidade desnecessária
Repetição desnecessária
![Page 29: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/29.jpg)
29
Princípios de Projeto
Princípio da Responsabilidade Única
The Single Responsibility Principle (SRP)
Princípio do Aberto-Fechado
The Open-Closed Principle (OCP)
Princípio de Substituição de Liskov
The Liskov Substitution Principle (LSP)
![Page 30: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/30.jpg)
30
Princípios de Projeto
Princípio da Inversão de Dependência
Dependency Inversion Principle (DIP)
Princípio de Reuso de Composição
The Composite Reuse Principle (CRP)
Princípio de Segregação de Interface
The Interface Segregation Principle (ISP)
![Page 31: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/31.jpg)
31
The Single Responsibility Principle
Uma classe deveria ter apenas uma razão para mudar
Responsabilidade = razão para mudança
Múltiplas responsabilidades = acoplamento alto, baixa coesão
Responsabilidades são eixos de alteração
Se uma classe faz mais de uma coisa, separe em classes diferentes
![Page 32: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/32.jpg)
32
The Single Responsibility Principle
Podemos melhorar este projeto!!!
![Page 33: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/33.jpg)
33
The Single Responsibility Principle
![Page 34: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/34.jpg)
34
The Single Responsibility Principle
public class Grupo {private List servidores;
public List getServidores() {return servidores;
}
public void setServidores(List servidores) {this.servidores = servidores;
}}
public class Servidor {
private String login;private Grupo meuGrupo;
public Servidor (String login, Grupo grupo) {this.login = login;this.meuGrupo = grupo;meuGrupo.getServidores().add(this.login);
}}
Exemplo de código...
![Page 35: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/35.jpg)
35
The Single Responsibility Principle
public class Grupo {private HashMap servidores;
public HashMap getServidores() {return servidores;
}
public void setServidores(HashMap servidores) {this.servidores = servidores;
}}
public class Servidor {
private String login;private Grupo meuGrupo;
public Servidor (String login, Grupo grupo) {this.login = login;this.meuGrupo = grupo;meuGrupo.getServidores().put("login", this.login);
}}
E se alterarmos a lista de servidores para um HashMap?
A classe Servidor precisa ser alterada também...
![Page 36: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/36.jpg)
36
The Single Responsibility Principle
public class Grupo {private HashMap servidores;
public void incluirServidor(Servidor servidor){// Regra para inserir Servidor...
}}
public class Servidor {
private String login;private Grupo meuGrupo;
public Servidor (String login, Grupo grupo) {this.login = login;this.meuGrupo = grupo;meuGrupo.incluirServidor(this);
}}
Se a regra para incluir servidor for responsabilidade do Grupo, o código da classe Servidor não precisa ser alterado...
![Page 37: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/37.jpg)
37
The Open-Closed Principle
Classes devem estar abertas para extensão e fechadas para modificação
Quando os requisitos mudam (e eles mudam!) o projeto deve permitir estender o comportamento adicionando novo código e não alterando o comportamento do código existente
Se a alteração de uma classe ou método resultar em uma cascata de alterações em outras classes e métodos, você tem um projeto “ruim”
![Page 38: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/38.jpg)
38
The Open-Closed Principle
Separe o que varia
Encapsular o que varia para que não afete o resto do código
Menos conseqüências indesejadas
Mais flexibilidade
Abstração e polimorfismo são a chave para este princípio
![Page 39: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/39.jpg)
39
The Open-Closed Principle
public class Matricula {private BigDecimal totalCred;private String tipoMatr;private Obrigacao obrigacao;
public void matricular(){// ...obrigacao.calcular(totalCred, tipoMatr);
}}
public class Obrigacao {
public BigDecimal calcular(BigDecimal creditos, String tipo){
BigDecimal valor = null;
if (tipo.equals("curricular")) {// Calcula matricula curricular
} else if (tipo.equals("extra-curricular")){// Calcula valor extra-curricular
} else {// Calcula valor padrao
}return valor;
}}
![Page 40: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/40.jpg)
40
The Open-Closed Principle
![Page 41: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/41.jpg)
41
The Liskov Substitution Principle
Conformidade de Tipo
Sub-tipos podem substituir super-tipos
Guia para criação de abstrações
Contratos
Violando este princípio podemos violar também o Princípio do Aberto-Fechado
![Page 42: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/42.jpg)
42
The Liskov Substitution Principle
![Page 43: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/43.jpg)
43
The Liskov Substitution Principle
public class Bolsa {
/** * Pre-condicao: valor não pode ultrapassar o devido * @param valor Valor do desconto lancado */public void lancarDesconto(BigDecimal valor){
}}
public class Financiamento extends Bolsa {
/** * Pre-condicao: deve ser menor que o devido * @param valor Valor do desconto lancado */public void lancarDesconto(BigDecimal valor){
}}
![Page 44: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/44.jpg)
44
The Liskov Substitution Principle
![Page 45: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/45.jpg)
45
Dependency Inversion Principle
Dependa de abstrações (ou interfaces) e não de classes concretas
Programe para uma interface, não para uma implementação
Explora o polimorfismo
Interface pode ser um super-tipo
Alterações em classes que implementam uma interface não quebram código cliente
![Page 46: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/46.jpg)
46
Dependency Inversion Principle
![Page 47: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/47.jpg)
47
The Composite Reuse Principle
Preferir a composição em relação a herança
Herança excessiva pode causar fragilidade e hierarquias complexas de classes
Herança pode quebrar o encapsulamento
Com herança podemos sobrescrever um método, às vezes indesejável. Na composição os métodos devem ser utilizados como foram definidos
Novas funcionalidades podem ser agregadas sem alteração no código existente (Princípio do Aberto-Fechado)
![Page 48: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/48.jpg)
48
The Composite Reuse Principle
Herança
Comportamento é herdado
Não podemos alterar o comportamento sem escrever mais código
Composição
Comportamento como um atributo
Mais flexibilidade
Permite alterar o comportamento em tempo de execução
![Page 49: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/49.jpg)
49
The Composite Reuse Principle
Exemplo de uso de herança:
![Page 50: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/50.jpg)
50
The Composite Reuse Principle
Mesmo exemplo utilizando composição e CRP:
![Page 51: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/51.jpg)
51
The Composite Reuse Principle
Outro exemplo com herança:
![Page 52: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/52.jpg)
52
The Composite Reuse Principle
Cálculo do bônus passou a ser diferente para os empregados em tempo integral
O que fazer para garantir um bom reuso sem código duplicado?
Mas...
![Page 53: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/53.jpg)
53
The Composite Reuse Principle
![Page 54: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/54.jpg)
54
The Interface Segregation Principle
Interfaces para específicos tipos de cliente são melhores que uma interface de propósito geral
Clientes não deveriam ser forçados a depender de interfaces que eles não utilizam
Interfaces muito grandes podem introduzir acoplamentos não desejados entre os clientes
ISP não recomenda que seja criada uma interface para cada classe cliente, mas que as classes sejam classificadas por tipo
Caso 2 ou mais tipos de clientes utilizem o mesmo método, este deve estar em ambas interfaces
![Page 55: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/55.jpg)
55
The Interface Segregation Principle
![Page 56: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/56.jpg)
56
The Interface Segregation Principle
![Page 57: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/57.jpg)
57
Referências
Fundamentals of Object-Oriented Design in UML - Meilir Page-Jones
Head First Design Patterns - Elisabeth Freeman, Eric Freeman, Bert Bates and Kathy Sierra
Design Principles e Design Patternshttp://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
Domain Driven Design Quicklyhttp://www.infoq.com/minibooks/domain-driven-design-quickly
Contratos Nuloshttp://fragmental.com.br/wiki/index.php/Contratos_Nulos
![Page 58: Fundamentos e princípios do projeto orientado a objetos](https://reader034.vdocuments.net/reader034/viewer/2022051314/55799f41d8b42ac1148b46a9/html5/thumbnails/58.jpg)
58
Referências
Lei de Demeterhttp://c2.com/cgi/wiki?LawOfDemeter
Articles for Object Oriented Designhttp://www.objectmentor.com/resources/publishedArticles.html