aula 04 - princípios de projeto
DESCRIPTION
Princípios de ProjetoTRANSCRIPT
![Page 1: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/1.jpg)
Princípios de Projeto Aula 04
Prof. Kleinner Farias Programa Interdisciplinar de Pós-Graduação
em Computação Aplicada – PIPCA Universidade do Vale do Rio dos Sinos
4
3/26/14 @KleinnerFarias 1
![Page 2: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/2.jpg)
Agenda
• Sintomas de degradação arquitetural • Princípios de projeto • Exemplos de aplicação dos princípios
2
![Page 3: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/3.jpg)
Sintomas de Degradação Arquitetural
• Rigidez • Fragilidade • Imobilidade • Viscosidade
3
![Page 4: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/4.jpg)
Sintomas de Rigidez
Rigidez
Rigidity is the tendency for soMware to be difficult to change, even in simple
ways. (Robert MarUn)
4
![Page 5: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/5.jpg)
Sintomas de Rigidez
• Mudanças nos requisitos causam uma cascata de subsequentes mudanças entre módulos dependentes do sistema
Efeito Dominó Efeito na Equipe 5
![Page 6: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/6.jpg)
Sintomas de Rigidez
• Tudo começa com um dia de trabalho que se transforma em 2, 3, n....semanas de mudanças tentando encontrar por onde começar
• Consequência: – Alto risco de realizar mudanças – Medo de resolver problemas críUcos – Gestor sente receio de autorizar modificações – Imprevisibilidade do fim da aUvidade de mudança
6
![Page 7: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/7.jpg)
Sintomas de Fragilidade
Fragilidade
Fragility is the tendency of the soMware to break in many places every Ume it is changed. (Robert MarUn)
7
![Page 8: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/8.jpg)
Sintomas de Fragilidade
• Mudança em um “Módulo A” do sistema provoca mudanças indesejadas em um “Módulo B” sem qualquer relação conceitual
• Quanto mais resolvo problema, mais problemas surgem
• Consequências: – As mudanças são imprevisíveis, não é possível mensurar o impacto/consequência de mudanças
– Torna-‐se dihcil esUmar os custos e as entregas 8
![Page 9: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/9.jpg)
Sintomas de Imobilidade
Imobilidade
Immobility is the inability to reuse soMware from other projects or from parts of the same project. (Robert MarUn)
9
![Page 10: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/10.jpg)
Sintomas de Imobilidade
• Um módulo que foi projetado para ser reusado torna-‐se altamente acoplado
• Framework criado na empresa que deixa de ser framework devido ao alto grau de dependência
• Consequências: – Baixo grau de reuso de soMware – Menor produUvidade do Ume de desenvolvimento – Maior custo de desenvolvimento
10
![Page 11: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/11.jpg)
Sintomas de Viscosidade
Viscosidade When faced with a change, engineers usually find more than one way to make the change. Some of the ways
preserve the design, others do not. (Robert MarUn)
11
![Page 12: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/12.jpg)
Sintomas de Viscosidade
• É mais fácil usar arUhcios de programação (vulgo gambiarra) que implementar da forma correta – Quando verificamos isso?
• Fazendo engenharia reversa • Analisando o código
• Consequências: – Arquitetura em desacordo com o código – Refactoring....
12
![Page 13: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/13.jpg)
O que provoca a degradação arquitetural?
13
![Page 14: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/14.jpg)
Causas de Degradação
• Mudanças não antecipadas: – Os requisitos mudam de tal forma que a arquitetura inicial não suporta as modificações
– Desenvolvedores novos em um Ume não estão familiarizados com a cultura da empresa/padrão de trabalho
– Documento de requisitos é um dos artefatos mais voláteis dentro do processo de desenvolvimento
14
![Page 15: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/15.jpg)
Causas de Degradação
• Gerência de Dependência – Os sintomas de degradação estão diretamente ligados ao gerenciamento de dependência entre os módulos
– Arquiteto tem dificuldade de visualizar e preservar a arquitetura, dada a dificuldade de controlar as mudanças
15
![Page 16: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/16.jpg)
Aplicando princípios de projetos e padrões de projetos para minimizar o impacto das mudanças e gerenciar as dependências
16
![Page 17: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/17.jpg)
Princípios de Projetos OO
• OCP: The Open Closed Principle • OCP: The Open Closed Principle • SRP: The Single Responsibility Principle • DIP: The Dependency Inversion Principle • LSP: The Liskov SubsUtuUon Principle • SDP: The Stable Dependencies Principle • SAP: The Stable AbstracUons Principle
17
![Page 18: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/18.jpg)
Princípios de Projetos OO
• CRP: The Common Reuse Principle • CCP: The Common Closure Principle • CRP: The Common Reuse Principle • ADP: The Acyclic Dependencies Principle • GRASP: General Responsibility Assignment SoMware Paserns
18
![Page 19: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/19.jpg)
OCP: The Open Closed Principle
A module should be open for extension but closed for modifica6on. (Bertrand Meyer)
19
![Page 20: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/20.jpg)
OCP: The Open Closed Principle
Devemos escrever módulos visando que os mesmos sejam estendidos sem ter a necessidade de serem modificados.
20
![Page 21: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/21.jpg)
Exemplo
Somar dois números
Subtrair dois números
Casos de Uso
Obje7vo: implementar uma calculadora
Desafio: implementar algo que seja flexível o bastante para suportar evoluções 21
![Page 22: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/22.jpg)
Exemplo
Soma
+ somar(a,b): double
Subtracao
+ subtrair(a,b): double
Calculadora
+ executarOperacao(Upo: String, a: double, b: double): double
Resultado: possível diagrama de classe
22
![Page 23: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/23.jpg)
Exemplo
Resultado: possível implementação da classe Calculadora
23
![Page 24: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/24.jpg)
Exemplo
Resultado: possível implementação da classe Soma e Subtração
24
![Page 25: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/25.jpg)
Exemplo
Somar dois números
Subtrair dois números
Casos de Uso
Evolução: implementar divisão e mulUplicação
Dividir dois números
MulUplicar dois números
25
![Page 26: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/26.jpg)
Qual é o
da evolução? 26
![Page 27: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/27.jpg)
Exemplo
Soma
+ somar(a,b): double
Subtracao
+ subtrair(a,b): double
Calculadora
+ executarOperacao(Upo: String, a: double, b: double): double
ANTES: possível diagrama de classe
27
![Page 28: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/28.jpg)
Exemplo
Soma
+ somar(a,b): double
Subtracao
+ subtrair(a,b): double
Calculadora
+ executarOperacao(Upo: String, a: double, b: double): double
Resultado da Evolução: possível diagrama de classe
Divisao
+ dividir(a,b): double
MulUplicacao
+ mulUplicar(a,b): double 28
![Page 29: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/29.jpg)
Exemplo
Resultado Anterior: implementação da classe Calculadora
Mudar Aqui
Mudar Aqui
29
![Page 30: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/30.jpg)
Exemplo
Resultado Depois: possível implementação da classe Calculadora
30
![Page 31: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/31.jpg)
Exemplo
IOperacao
+ executar(a: double, b: double): double
Soma
+ executar(...): double
Subtracao
+ executar(...): double
interface
realização
CalculadoraOCP
+ executarOp(...): double
Com Open-‐Closed: possível diagrama de classe
31
![Page 32: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/32.jpg)
Exemplo
Resultado: possível implementação da classe CalculadoraOCP
32
![Page 33: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/33.jpg)
Exemplo
Resultado: possível implementação da interface, Soma e Subtração
O que mudou?
33
![Page 34: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/34.jpg)
Exemplo
IOperacao
+ executar(a: double, b: double): double
Soma
+ executar(...): double
Subtracao
+ executar(...): double
MulUplicacao
+ executar(...): double
Divisao
+ executar(...): double
interface
realização
CalculadoraOCP
+ executarOp(...): double
Com Open-‐Closed: possível diagrama de classe
34
![Page 35: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/35.jpg)
Exemplo
Resultado: possível implementação da interface, Soma e Subtracao
O que mudou?
35
![Page 36: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/36.jpg)
OCP: The Open Closed Principle
Em resumo: objeUvo arquitetural do Open-‐Closed
Criar módulos que sejam extensíveis,
porém sem ser modificados
36
![Page 37: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/37.jpg)
SRP: The Single Responsibility Principle
• SRP: there should never be more than one reason for a class to change [MarUn2002]
• Inicialmente proposto como Coesão por – Tom DeMarco [DeMarco79] e – Meilir Page-‐Jones [PageJones88]
• Cada responsabilidade é um eixo de mudança
3/26/14 @KleinnerFarias 37
![Page 38: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/38.jpg)
SRP: The Single Responsibility Principle • Se uma classe assume mais de uma responsabilidade, então existe mais de uma razão para modificá-‐la
• Se uma classe tem mais de uma responsabilidade, então as responsabilidade se tornam acopladas
• Consequência: – Fragile Design: o projeto quebra de forma inesperada quando modificado
3/26/14 @KleinnerFarias 38
![Page 39: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/39.jpg)
SRP: The Single Responsibility Principle
• Exemplo [MarUn2002]: + draw() [desenha o retângulo na tela] + area() [calcula a área do retângulo]
3/26/14 @KleinnerFarias 39
![Page 40: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/40.jpg)
SRP: The Single Responsibility Principle
• Observações: – Duas aplicações diferentes usam Rectangle – Computa6onal Geometry Applica6on
• Usa a classe Rectangle para calcular a área: + area() • Nunca desenha retângulo na tela: + draw()
– Graphical Applica6on • Pode calcular área: + area() • Desenha retângulo na tela: + draw()
3/26/14 @KleinnerFarias 40
![Page 41: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/41.jpg)
SRP: The Single Responsibility Principle • Classe Rectangle viola o SRP:
– Tem duas responsabilidades • Calcula a área do retângulo: + area() • Desenha o retângulo na tela: + draw()
3/26/14 @KleinnerFarias 41
![Page 42: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/42.jpg)
SRP: The Single Responsibility Principle • Consequências:
– “Acoplamento transi6vo” • Computa6onal Geometry Applica6on (CGA) depende de Rectangle que depende de GUI. Logo, CGA depende de Rectangle que depende de GUI
3/26/14 @KleinnerFarias 42
![Page 43: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/43.jpg)
SRP: The Single Responsibility Principle • Consequências:
– Propagação de mudança • Se Rectangle mudar por causa de GraphicalApplica6on, esta mudança pode levar modificações em CGA
• Se não gerenciarmos este Upo de acoplamento, a aplicação pode sofrer propagações imprevisíveis
3/26/14 @KleinnerFarias 43
![Page 44: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/44.jpg)
SRP: The Single Responsibility Principle • Recomendação: separar as responsabilidades
3/26/14 @KleinnerFarias 44
![Page 45: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/45.jpg)
SRP: The Single Responsibility Principle • Consequências:
– Acoplamento transiUvo eliminado – Isolamento da classe Computa6onalGeometryApplica6on em relação à forma de desenhar o retângulo
– A classe CGA não depende mais indiretamente de GraphicalApplica6on
– Mudanças na forma como o retângulo é desenhado não afetará CGA
3/26/14 @KleinnerFarias 45
![Page 46: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/46.jpg)
SRP: The Single Responsibility Principle
Afinal, o que seria responsabilidade?
3/26/14 @KleinnerFarias 46
![Page 47: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/47.jpg)
SRP: The Single Responsibility Principle
• Responsabilidade: “a reason for change” • Se idenUficamos mais de um moUvo para mudar um classe, então ele terá mais de uma responsabilidade
• Modem tem quantas responsabilidades?
3/26/14 @KleinnerFarias 47
![Page 48: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/48.jpg)
SRP: The Single Responsibility Principle
• Duas responsabilidades: ① Gerenciamento de conexão: dial e hangup ② Comunicação de dados: send e recv
3/26/14 @KleinnerFarias 48
![Page 49: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/49.jpg)
SRP: The Single Responsibility Principle
• Duas responsabilidades: ① Gerenciamento de conexão: dial e hangup ② Comunicação de dados: send e recv
• Observações: – As responsabilidades têm quase nada em comum – Mudam por diferentes razões – Serão chamadas por diferentes partes da aplicação, as quais mudarão por diferentes razões também
3/26/14 @KleinnerFarias 49
![Page 50: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/50.jpg)
SRP: The Single Responsibility Principle • Um responsabilidade por interface:
① Gerenciamento de conexão: dial e hangup ② Comunicação de dados: send e recv
3/26/14 @KleinnerFarias 50
![Page 51: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/51.jpg)
DIP: The Dependency Inversion Principle
• DIP1: módulos de mais alto nível não devem depender de módulos de mais baixo nível. Ambos devem depender de abstrações
• DIP2: abstrações não devem depender de detalhes.
• Principal princípio uUlizado para projetar frameworks
3/26/14 @KleinnerFarias 51
![Page 52: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/52.jpg)
DIP: The Dependency Inversion Principle
• Módulos de mais alto nível: – aqueles que implementam regras de negócio – suas caracterísUcas idenUficam a aplicação – devem ser desacoplados de módulos de mais baixo nível
• Módulos de mais baixo nível: – responsáveis por detalhes de implementação
3/26/14 @KleinnerFarias 52
![Page 53: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/53.jpg)
DIP: The Dependency Inversion Principle
• Segundo Booch: “toda arquitetura bem estruturada deve ter
uma definição clara de suas camadas, com cada camada fornecendo uma conjunto coerente de serviços através de uma interface bem definida
e controlada.” [MarUn2002]
3/26/14 @KleinnerFarias 53
![Page 54: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/54.jpg)
DIP: The Dependency Inversion Principle
• Exemplo:
3/26/14 @KleinnerFarias 54
![Page 55: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/55.jpg)
DIP: The Dependency Inversion Principle • Exemplo:
3/26/14 @KleinnerFarias 55
Qual seria o problema com esta arquitetura?
![Page 56: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/56.jpg)
DIP: The Dependency Inversion Principle • Problema: dependência transiUva
3/26/14 @KleinnerFarias 56
![Page 57: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/57.jpg)
DIP: The Dependency Inversion Principle • Solução: cada camada superior define uma interface com os serviços que ela necessita
3/26/14 @KleinnerFarias 57
![Page 58: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/58.jpg)
DIP: The Dependency Inversion Principle • Observações:
– Camada superior: • Interage com a camada inferior considerando os serviços declarados nas suas interfaces
• Fica totalmente desacoplada das camadas inferiores
– Camada inferior: • É definida considerando os serviços definidos na(s) interface(s) da camada superior
• A camada inferior depende das interfaces (das abstrações)
3/26/14 @KleinnerFarias 58
![Page 59: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/59.jpg)
DIP: The Dependency Inversion Principle • Exemplo:
3/26/14 @KleinnerFarias 59
![Page 60: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/60.jpg)
DIP: The Dependency Inversion Principle • Exemplo:
3/26/14 @KleinnerFarias 60
![Page 61: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/61.jpg)
DIP: The Dependency Inversion Principle • Exemplo:
– Bu#on depende diretamente da Lamp – Observações:
• Sempre que Lamp mudar Bu#on também mudará • Não será possível reusar Bu#on sem reusar Lamp • Não será possível reusar Bu#on para controlar um Motor
• Ou seja, Bu#on apenas controla Lamp
3/26/14 @KleinnerFarias 61
![Page 62: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/62.jpg)
DIP: The Dependency Inversion Principle • Exemplo:
– Bu#on depende diretamente da Lamp
3/26/14 @KleinnerFarias 62
![Page 63: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/63.jpg)
DIP: The Dependency Inversion Principle • Exemplo:
3/26/14 @KleinnerFarias 63
Button depende diretamente da Lamp
Button não depende diretamente da Lamp
Importante: DIP pode ser aplicado sempre que uma classe enviar uma mensagem para outra.
![Page 64: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/64.jpg)
LSP: The Liskov SubsUtuUon Principle
Subclasses should be subs6tutable for their base classes. (Barbar Liskov)
Design by contract (Bertrand Meyer)
64
![Page 65: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/65.jpg)
if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program (e.g., correctness). (Barbara Liskov)
65
LSP: The Liskov SubsUtuUon Principle
• Em outras palavras…
![Page 66: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/66.jpg)
O “User” deve ser capaz de usar qualquer subclasse de “Base” Por que?
“User” usa a classe “Base” porque ela especifica um contrato muito bem definido Respeita o contrato
definido por “Base”
Define o contrato
66
LSP: The Liskov SubsUtuUon Principle
![Page 67: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/67.jpg)
LSP no Exemplo da Calculadora
IOperacao
+ executar(a: double, b: double): double
Soma
+ executar(...): double
Subtracao
+ executar(...): double
MulUplicacao
+ executar(...): double
Divisao
+ executar(...): double
interface
realização
CalculadoraOCP
+ executarOp(...): double
67
![Page 68: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/68.jpg)
LSP no Exemplo da Calculadora
IOperacao
+ executar(a: double, b: double): double
Soma
+ executar(...): double
Subtracao
+ executar(...): double
MulUplicacao
+ executar(...): double
Divisao
+ executar(...): double
interface
realização
CalculadoraOCP
+ executarOp(...): double
Com Open-‐Closed: possível diagrama de classe User Base
Derived
68
![Page 69: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/69.jpg)
LSP no Exemplo da Calculadora
IOperacao
+ executar(a: double, b: double): double
Soma
+ executar(...): double
Subtracao
+ executar(...): double
MulUplicacao
+ executar(...): double
Divisao
+ executar(...): double
realização
CalculadoraOCP
+ executarOp(...): double
CalculadoraOCP usa a IOperacao porque ela é “muito bem definida” no que se compromete a fazer
69
![Page 70: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/70.jpg)
LSP no Exemplo da Calculadora
IOperacao
+ executar(a: double, b: double): double
Soma
+ executar(...): double
Subtracao
+ executar(...): double
MulUplicacao
+ executar(...): double
Divisao
+ executar(...): double
realização
CalculadoraOCP
+ executarOp(...): double
CalculadoraOCP usa a IOperacao porque espera que as subclasses respeitem o contrato
70
![Page 71: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/71.jpg)
IOperacao
+ executar(a: double, b: double): double
Soma
+ executar(...): double
Subtracao
+ executar(...): double
MulUplicacao
+ executar(...): double
Divisao
+ executar(...): double
realização
CalculadoraOCP
+ executarOp(...): double
Mudança de requisitos, e agora? Para qual 7po de mudanças estamos preparados? ! Adição de novas operações à calculadora
Exponencial
+ executar(...): double 71
![Page 72: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/72.jpg)
Onde as mudanças não podem ocorrer?
Qual é o impacto?
72
![Page 73: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/73.jpg)
Mudanças em classes abstratas e interfaces com alto grau de acoplamento aferente
73
![Page 74: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/74.jpg)
IOperacao
+ executar(a: double, b: double): double
Soma
+ executar(...): double
Subtracao
+ executar(...): double
MulUplicacao
+ executar(...): double
Divisao
+ executar(...): double
realização
CalculadoraOCP
+ executarOp(...): double
Mudança de requisitos, e agora? Qual mudança causará o maior impacto/alteração? ! Mudanças em classes mais abstratas ! Classes abstratas e interfaces com alta dependência
impacto
74
![Page 75: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/75.jpg)
Classd
+ opD(): String
ClassX
+ opx(...): double
Mudança de requisitos, e agora? Qual classe causará o maior impacto?
ClassC
+ opC(): String
ClassA
+ opA(): String
ClassB
+ opB(): String
ClassX
+ opx(...): double
75
![Page 76: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/76.jpg)
Classd
+ opD(): String
ClassX
+ opx(...): double
Mudança de requisitos, e agora? Qual classe causará o maior impacto?
ClassC
+ opC(): String
ClassA
+ opA(): String
ClassB
+ opB(): String
ClassX
+ opx(...): double
76
![Page 77: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/77.jpg)
SDP: The Stable Dependencies Principle
The dependencies between packages in a design should be in the direcUon of the stability of the packages.
A package should only depend upon packages
that are more stable that it is.
How can we measure the stability of a package? 77
![Page 78: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/78.jpg)
Estabilidade • Ca: Afferent Couplings :
– The number of classes outside this package that depend upon classes within this package.
• Ce: Efferent Couplings – The number of classes inside this package that depend upon classes outside this package.
• I: Instability : (Ce/(Ca+Ce)) – This metric has the range [0,1]. – I=0 indicates a maximally stable package. – I=1 indicates a maximally instable package. 78
![Page 79: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/79.jpg)
Estabilidade
79
![Page 80: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/80.jpg)
Estabilidade
Acoplamento Aferente = 4
80
![Page 81: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/81.jpg)
Estabilidade
Acoplamento Eferente = 3
0,42
81
![Page 82: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/82.jpg)
Estabilidade
Qual é o pacote mais instável?
82
![Page 83: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/83.jpg)
Estabilidade
• Nem todo pacote deve ser estável
83
![Page 84: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/84.jpg)
Como estabilizar o projeto?
84
![Page 85: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/85.jpg)
SAP: The Stable AbstracUons Principle
Packages that are maximally stable should be maximally abstract.
Instable packages should be concrete.
The abstrac6on of a package
should be in propor6on to its stability. 85
![Page 86: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/86.jpg)
Estabilidade
86
![Page 87: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/87.jpg)
Estabilidade packages that are maximally stable and abstract
The packages that are maximally instable and
concrete
87
![Page 88: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/88.jpg)
Princípios de Projeto OO
• CCP: The Common Closure Principle
Classes that change together, belong together.
88
Classes that aren’t reused together should not be grouped together.
• CRP: The Common Reuse Principle
![Page 89: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/89.jpg)
Princípios de Projeto OO
• ADP: The Acyclic Dependencies Principle
The dependencies between packages must not form cycles.
89
![Page 90: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/90.jpg)
ADP: The Acyclic Dependencies Principle
90
![Page 91: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/91.jpg)
....mas ciclo é ruim?
....por que é ruim? 91
ADP: The Acyclic Dependencies Principle
![Page 92: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/92.jpg)
...exemplo de como resolver o ciclo?
92
ADP: The Acyclic Dependencies Principle
![Page 93: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/93.jpg)
C1
C2
C3
C4 93
ADP: The Acyclic Dependencies Principle
![Page 94: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/94.jpg)
C1
C2
C3
C4
Quebra da Arquitetura
94
ADP: The Acyclic Dependencies Principle
![Page 95: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/95.jpg)
Princípios GRASP
“A ferramenta crucial de projeto para desenvolvimento de soMware é uma mente bem educada em princípios de projeto.” (Graig Larman)
95
![Page 96: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/96.jpg)
Princípios GRASP
• GRASP: General Responsibility Assignment So_ware Pa`erns
• Padrões GRASP: – Criador – Especialista na Informação – Baixo acoplamento – Controlador – Alta coesão – Polimorfismo – Invenção Pura – Indireção – Variações Protegidas
96
![Page 97: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/97.jpg)
Princípios GRASP
• Criador: – Responsável por criar objetos
• Problema: – Quem cria objetos da classe A?
• Solução: – atribuir a responsabilidade de criar uma instância da classe A se uma
das seguintes afirmaUvas for verdadeira: – B contem A, ou agrega A de forma composta
– B registra A – B usa A de maneira muito próxima – B contém os dados iniciais de A
97
![Page 98: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/98.jpg)
Princípios GRASP
• Especialista na Informação – Trata-‐se de um dos princípios de atribuição de responsabilidades mais simples em projetos OO
– Toda responsabilidade depende de informação
• Problema: – Qual é o princípio básico para se atribuir responsabilidade às classes?
• Solução: – Atribuir responsabilidade à classe que tenha informação necessária para saUsfazê-‐la
98
![Page 99: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/99.jpg)
Princípios GRASP
• Baixo acoplamento – Acoplamento: uma medida de quão fortemente um elemento está conectado a, tem conhecimento de, ou depende de outros elementos.
– Exemplo: uma objeto A que faz uso de operações de um objeto B tem acoplamento com os serviços de B.
• Problema: – Como reduzir o impacto de modificação?
• Solução: – Atribuir responsabilidade de tal formar que o acoplamento seja baixo
99
![Page 100: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/100.jpg)
Princípios GRASP
• Controlador – Responsável por orquestrar as responsabilidades – Componente central no padrão MVC
• Problema: – Qual é o primeiro objeto que recebe e coordena uma operação?
• Solução: – Atribuir responsabilidade a uma classe que orquestra os comportamentos oferecidos
100
![Page 101: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/101.jpg)
Princípios GRASP
• Alta Coesão – Classes com baixa número de responsabilidades
• Problema: – Como manter os objetos focados, inteligíveis e gerenciáveis e, como efeito colateral, apoie o baixo acoplamento?
• Solução: – Atribuir responsabilidades de tal forma que a coesão permaneça baixa
101
![Page 102: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/102.jpg)
Princípios GRASP
• Polimorfismo – Como tratar alternaUvas com base no Upo? – Como criar componentes de soMware interconectáveis?
• Problema: – Como manter os objetos focados, inteligíveis e gerenciados e, como efeito colateral, apoiar baixo acoplamento?
• Solução: – Atribuir responsabilidades de tal forma que a coesão permaneça baixa
102
![Page 103: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/103.jpg)
Princípios GRASP
• Invenção Pura – Como atribuir responsabilidade sem comprometer a alta coesão e o baixo acoplamento?
• Problema: – Como trabalhos com conceitos ausentes no domínio do problema?
– Como persisUr os dados de uma venda? • A classe Venda possui os dados, logo deve ter esta responsabilidade? (princípio do especialista)
– Vários conceitos sobre BD sem relação nenhuma com vendas. Logo, Venda se torna não-‐coesa. 103
![Page 104: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/104.jpg)
Princípios GRASP
• Variações protegidas – Como projetar objetos, subsistemas e sistemas de modo que as mudanças nesses elementos não provoque mudanças indesejadas?
• Solução: – IdenUficar pontos com alta probabilidade de mudança
– Projetar orientado à interface
104
![Page 105: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/105.jpg)
Princípios GRASP
• Indireção – Como atribuir responsabilidade de tal forma que evite o acoplamento entre dois objetos?
– Como desacoplar os objetos visando um baixo acoplamento e uma alta coesão?
• Solução: – Atribuir a responsabilidade de ser o mediador entre outros componentes ou serviços a um objeto intermediário
105
![Page 106: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/106.jpg)
References
• [Bass2003] BASS, L., CLEMENTS, P., KAZMAN, R. So_ware architecture in prac6ce, Boston: Addison-‐Wesley Professional, 2a ediUon, 2003.
• [Buschmann2000] BUSCHMANN, F. Pa`ern-‐oriented so_ware architecture: a system of pa`erns, Chichester: John Wiley & Sons, 2000.
• [Shaw1996] SHAW, M., GARLAN, D. So_ware architecture: perspec6ves on an emerging discipline, Upper Saddle River: PrenUce-‐Hall, 1996.
106
![Page 107: Aula 04 - Princípios de Projeto](https://reader030.vdocuments.net/reader030/viewer/2022020200/55cf8ffb550346703ba1f732/html5/thumbnails/107.jpg)
References
• [DeMarco79] Tom DeMarco, Structured Analysis and System Specifica6on, Yourdon Press CompuUng Series, 1979.
• [PageJones88] Meilir Page-‐Jones, The Prac6cal Guide to Structured Systems Design, 2ª Ed., Yourdon Press CompuUng Series, 1988.
• [Mar7n2002] Robert C. MarUn, Agile So_ware Development, Principles, Pa`erns, and Prac6ces, Pearson EducaUon, 2002.
107