This repository has been archived by the owner on Aug 10, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
/
11.01-Design
143 lines (121 loc) · 5.88 KB
/
11.01-Design
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
Design
========
* Definições de dicionário
- Aurélio
1. Concepção de um prjeto ou modelo, planejamento
2. O produto desse planejamento.
- Houaiss
1. A concepção de um produto (máquina, utensílio, mobiliário,
embalagem, publicação, etc), especialmente no que se
refere à sua forma física e funcionalidade.
2. O produto desta concepção.
- Wikipedia
- Design (em alguns casos projeto) é um esforço criativo
relacionado à sua configuração, elaboração e especificação
de um artefato. Esse esfprçonormalmente é orientado por uma
inteção ou objetivo, ou paraa solução de um problema.
* Até o momento, já vimos 3 passsos:
- Requisitos (arquiteto) } Segundo a concepção vista nas
- Modelagem (arquiteto) } definições, tudo poderia ser
- Design de classes (engenheiro) } chamado de 'design'.
Design estrutural
^^^^^^^^^^^^^^^^^-- Estão envolvidos com a passagem do plano
conceitual para a PROGRAMAÇÃO (estrutura
do código para ser implementada).
* Análise x design
- Análise: fazer a coisa certa
- Foco no entendimento do problema (o que?)
- Análise de requisitos
- Análise do domínio
- Design: fazer certo a coisa
- Foco no endedimento da solução (como?)
- Arquitetura
- Estrutura
- Infraestrutura
- Perto do código real
- Operações e atributos
- Ciclo de vida dos objetos
* Há vários conceitos relacionados a um bom design
- Atender aos requisitos funcionais e não funcionais
da aplicação da melhor maneira.
- Geralmente, tem-se maior atenção aos requisitos não funcionais,
durante esta fase.
- Em geral, o requisito não funcional MAIS IMPORTANTE é a
Manutenibilidade (capacidade de evoluir).
- As mudanças são inevitáveis e frequentes. Os bons softwares são
fáceis de serem mudados, e os métodos ágeis aceitam "com prazer"
mudanças nos requisitos mesmo quando aparecem tardiamente.
- Com o passar do tempo, programas passam por uma 'degradação'
(também chamada de 'deteriorização' ou 'apodrecimento'), em
que mudanças ("gambiarras") feitas no código para resolver um
problema rapidamente podem se acumular, até que o software se
torna INSUSTENTÁVEL.
- Os métodos ágeis tentam, ao máximo, evitar os problemas de
mudanças e modificações: refatorações, pair programming e testes
reduzem a introdução de novos bugs. Eles usam também tabelas
com a 'dívida técnica' (as "gambiarras" feitas no código), a
serem pagas no futuro, para evitar a degradação.
* Definições
- Encapsulamento:
- É um mecanismo usado para ocultar os dados, a estrutura
interna e os detalhes de implementaçãode algum elemento,
como um objeto ou subsistema.
- Acoplamento
- É uma medida de quãofortemetne umelemento está conectado a,
tem conhecimento de, ou depende de outros elementos
- Princípio do baixo acoplamento (low coupling)
- Coesão
- Coesão mede o grau de conectividade entre os elementos de um
mesmo módulo, classe ou objeto. Cada classe deve executar um
conjunto bastante específico de ações intimamente
relacionadas.
- Princípio da alta coesão (high cohesion).
- Interfaces
- Codificar para uma interface ao invés de codificar para uma
implementação torna o seu software mais fácil de ser estendido
e facilida a testabilidade.
- Código funcionará com todas as implementações da interface:
inclusive aquelas que não foram criadas.
- OCP: Open/Closed Principle
- Definição de responsabilidades
- Métodos ágeis aceitam "com prazer" mudanças nos requisitos
mesmo quando aparecem tardiamente.
- Cada classe deve ter uma única razão para mudar, uma única
responsabilidade.
- SRP: Single Responsability Principle
- DRY (Don't Repeat Yourself)
- Evite código duplicado abstraindo coisas que são comuns e
as colocando em um local único.
- Um requisito, um lugar.
- Liskov Substitution Principle
- Subtipos devem ser subistituíveis por seu tipo básico.
- Uso correto de herança: deve ser possível substituir a
subclasse pela classe base sem que haja efeitos colaterais.
- Composição
- Um objeto composto de outros objetos torna-se "dono" deles.
- Quando o objeto é destruído, todas as suas partes também são
(controle do ciclo de vida).
- Herança
- Deve ser utilizada para explorar o polimorfismo
- Favoreça delegação, composição, agregação contra herança.
* "Maus cheiros" (bad smells) de design
- Rigidez
- Difícil de mudar.
- Efeito dominó.
- Fragilidade
- Quebra em muitos lugares na presença de mudanças.
- Efeito borboleta-maremoto (uma borboleta bate uma asa e
gera um maremoto do outro lado do mundo).
- Imobilidade
- Baixo grau de reuso.
- Efeito banana-gorila (para trazer a banana, leva-se o gorila).
- Viscosidade
- Design não preparado para mudanças.
- Fácil fazer a coisa errada e difícil fazer a coisa certa.
- Complexidade desnecessária
- Repetição desnecessária
* Em alguns casos, podemos querer inserir trechos de código em todas
as classes ou métodos. Não há suporte para tratar esses casos na
orientação a objetos tradicional. Para isso, surgiu a Aspect Oriented
Development (AOD), que define ASPECTOS como sendo trechos de código
a inseridos dentro de classes antes da compilação.