Sap – stablility and abstract principle

Princípio de Estabilidade e Abstração

SAP Definição: Um pacote deve ser tão abstrato quanto

estável.

Um pacote estável deve ser também abstrato de

modo que sua estabilidade não impeça que ele seja

estendido.

Um pacote instável deve ser concreto desde que o

código concreto dentro dele seja facilmente alterado.

Exemplo Exemplo de mudança no cliente.

Usuários e gerentes são incapazes de prever a qualidade de seus

produto. Uma simples mudança em uma parte do pedido pode

provocar falhas em outras partes que parecem ser completamente

independentes. Corrigindo esses problemas podem surgir ainda

mais problemas, e o processo de manutenção começa a se

assemelhar a um cachorro correndo atrás do rabo.

É difícil reutilizar um projeto que é altamente interdependente. Por

isso os desenvolvedores se assustam com a quantidade de trabalho

para separar uma parte indesejável do projeto, da parte desejável se

um projeto possui essa característica.


Muitas vezes o custo é menor do que fazer a separação, sendo

assim, é comum vermos projetos desse tipo serem remodelados do

zero.

Para ilustrar vamos utilizar um programa simples que é carregado

com a tarefa de copiar caracteres digitados em um teclado para uma

impressora, e que a plataforma de implementação não dá suporte a

independência dos dispositivos.

Exemplo


Há três módulos. O módulo "Copy" chama os outros dois. Imagine um loop dentro do módulo "Copy". O corpo do loop que chama o módulo "Read Keybord” (leitura do teclado) para buscar um caracter do teclado, que envia um caracter para omódulo "Write Printer” (Escrever impressora) que imprime o caráter.

Os dois módulos de baixo nível são bem reutilizáveis. Eles podem ser usados em muitos outros programas para ter acesso ao teclado e a impressora. Este é o mesmo tipo de reutilização que ganhamos com bibliotecas de rotinas.

Veja um exemplo de código parecido com o módulo “Copy”.

Exemplo Exemplo do código Copy

void Copy()

{

int c;

while ((c = ReadKeyboard()) != EOF)

WritePrinter(c);

}


Note que o módulo "Copy" é dependente do módulo "Write Printer", e portanto, não pode ser reutilizado em um novo contexto, apesar da funcionalidade desse módulo ser muito interessante, ele não é reutilizável em qualquer contexto que não envolva um teclado ou uma impressora.

Por exemplo, considere esse contexo: um programa que copia os caracteres digitados em um teclado para um arquivo em disco.

Certamente poderíamos modificar o módulo "Copiar" para dar-lhe a nova funcionalidade desejada.


Poderíamos acrescentar um “if” para que possamos escolher entre o

módulo "Write Printer" e o "Write Disk”, dependendo somete de

algum tipo de comando.

No entanto, isso acrescenta novas interdependências, para o

sistema, e conforme o passar do tempo, cada vez mais dispositivos

podem participar do programa, então o módulo "Copy" estará repleto

de declarações “if” e “else” e será dependente de vários módulos de

nível inferior. Ele se tornará rígido e frágil.

Ivertendo Dependências Invertendo dependências com OOD

Uma forma de caracterizar o problema acima é de notar que o

módulo que contém

um alto nível de acoplamento, ou seja, o módulo "Copy", é

dependente de seus detalhes.

Se pudéssemos controlar os outros módulos a partir de qualquer

dispositivo de entrada para qualquer dispositivo de

saída, poderíamos reutilizar livrimente o “Copy”. O OOD nos dá

mecanismos para a realização dessa inversão de dependência.

Ivertendo Dependências

Exemploclass Reader{ public:virtual int Read() = 0;};class Writer{public:virtual void Write(char) = 0;};void Copy(Reader& r, Writer& w){int c;while((c=r.Read()) != EOF)w.Write(c);}

Exemplo No entanto, essa classe "Copy" de não depende em tudo da

"Keyboard Reader", nem da "Printer Writer". Assim, as

dependências foram invertidas. Agora, a classe "Copy" depende

somente das abstracts, e o “Read” e o “Writer”.

Agora podemos reutilizar a classe "Copy", independentemente do

"Keyboard Reader" e do "Printe Writer". Podemos inventar novos

tipos de "Reader" e "Writer" que podem dar suporte à classe "Copy".

Além disso, não importa quantos tipos de "Reader e "Writer" são

criados, "Copy" não dependerá de nenhum deles.

Não haverá interdependências para deixar o programa frágil ou

rígido. Esta é a essência do DIP.

Estável VS Volátil Certamente poderíamos imaginar algumas mudanças se

estendecemos um pouco o nosso pensamento. Mas no curso dos

acontecimentos normal, essas classes têm baixa volatilidade.

Desde "Copy" dependa de módulos que são do tipo não-volátil, é

muito pouco provável que a “Copy” sofra alterações. "Copy" também

é um exemplo do princípio "Open/Closed". "Copy" está aberta a ser

expanção, uma vez que podem criar novas versões de "Reader"

e "Writer". No entanto, "Copy" está fechada para a modificação, já

que não tem que modificá-lo para alcançar essas extensões.

Assim, podemos dizer que uma dependência boa é uma

dependência de algo com baixa volatilidade. Quanto menos volátil o

objetivo da dependência, melhor a dependência. Da mesma forma

uma "Má Dependência" é uma dependência de algo que é volátil.

Quanto mais volátil o objetivo da dependência, pior é a

dependência.

Estabilidade Independência A definição clássica da estabilidade palavra é: "Não é facilmente

abalado."

Esta é a definição que iremos utilizar neste artigo. Ou seja, a

estabilidade não é uma medida da probabilidade que um módulo vai

mudar, e sim é uma medida da dificuldade de um módulo em mudar.

Como se alcançar a estabilidade? Por que, por exemplo

"Reader" e "Writer", são tão estáveis?

Considere novamente as forças que poderiam fazê-los mudar. Eles

não dependem de nada

em tudo, então a mudança de uma dependencia não podem

estender-se até eles e levá-los a mudar.

Essa característica é chamda de "Independência".

Estabilidade Independência Classes Independente são classes que não dependem de qualquer

outra coisa.

Outra razão que "Reader" e "Writer" são estáveis é que eles são

dependencias de outras classes. Entre "Copy", "KeyboardReader" e

"KeyboardWriter“.

O fato é que, podem existir alterações de "Reader" e

"Writer", mas, quanto mais dependencias essas classes

tiverem, mais difícil será alteralas.

Se alterarmos "Reader" ou "writer" que teria que mudar todas as

outras classes que dependem delas. Assim, essa mudança daria

muito trabalho e isso nos impede de mudar essas classes, e

aumentando a sua estabilidade.

Classes Estáveis

As classes mais estáveis, são classes que são

independentes e responsáveis. Essas classes não

têm nenhuma razão para mudar, e muitas razões

para não mudar

Dependências Estáveis

As dependências entre pacotes em um projeto devem ser no sentido da estabilidade dos PACOTES. Os PACOTES devem depender apenas de pacotes que são MAIS ESTÁVEL que ele.

Projetos não podem ser completamente estáticos. Alguma volatilidade é necessário ser mantida no projeto.

Métricas de Estabilidade Como podemos medir a estabilidade de um

pacote?

Uma maneira é contar o número de

dependências que entram e saem desse pacote.

Estas contagens nos permitirá calcular a posição

estabilidade do pacote.

Métricas de Estabilidade Ca: Acoplamentos Aferentes: O número de classes de fora deste

pacote, que dependemem classes dentro deste pacote.

Ce: Acoplamentos eferente: O número de classes dentro desse pacote que depende declasses de fora deste pacote.

I: Instabilidade: (Ce/(Ca + Ce)): Esta métrica tem no intervalo [0,1].

I = 0 (indica ser um pacote maximamente estável).

I = 1 (indica um pacote máximamente instável).

As métricas de Ca e Ce são calculados pela contagem do número de classes fora do pacote em questão que têm dependências com as classes dentro do pacote em questão.

Métricas de Estabilidade O PSD diz que a métrica de um pacote que deve ser maior do que

as métricas I do

pacotes que ele depende. ou seja, eu métricas devem diminuir na

direção de dependência.

Nem todos os pacotes devem ser estáveis. Se todos os pacotes em

um sistema foram maximamente estável, o sistema seria imutável.

Esta não é uma situação desejável. Na verdade, queremos projetar

a nossa estrutura de pacotes, de modo que alguns pacotes são

instáveis, e alguns são estáveis. A figura a seguir mostra o ideal

configuração de um sistema com três pacotes.

Métricas de Estabilidade

SAP Este princípio estabelece uma relação entre a

estabilidade e a abstração.

Ele diz que um pacote estável deve também ser

abstrato de modo que sua estabilidade não impeça

que ele seja modificado. Por outro lado, ele diz que

um pacote instável deve ser de concreto, uma vez

que a sua instabilidade permita que o código de

concreto dentro dele seja facilmente alterado.

SAP- Como mensurar? (NC): O número de classes do pacote

(Na): O número de classes abstratas no

pacote

(Abstração): A = Na / Nc

Um A tem o intervalo [0,1]

A = 0 (implica que o pacote não tem classes abstratas)

A = 1 (implica que o pacote possui somente classes

abstratas)

SAP - Gráfico A.I.

I = 1, A = I

maximamente

instável e

Abstrato

I = 0, A = 0

maximamente

estável e

concreto

SAP - Gráfico A.I.

I = 1, A = I

maximamente

instável e

Abstrato

I = 0, A = 0

maximamente

estável e

concreto

SAP - Gráfico A.I.

Pacotes que são maximamente ESTÁVEIS devem ser maximamente ABSTRATOS.

PACOTES instáveis DEVEM SER CONCRETOS.

A abstração de um pacote deve ser PROPORCIONAL a sua estabilidade.

Um pacote que fica na seqüência principal não é abstrato o bastante para a sua estabilidade,nem é instável para a sua abstração.

SAP - Distância da seqüência principal O pacote deve estar ligado ou próximo da seqüência

principal

(Distância D): D = | A + I - 1 | / √ 2

Intervalos D‟ a partir de [0, 0,707 ~]

(Distância normalizada D „): D‟ = | I + A - 1 |

Intervalos D 'a partir de [0, 1]

D = 0 indica que o pacote está diretamente ligadoa seqüência principal

D = 1 indica que o pacote está tão longelonge possível a partir da seqüência principal

SAP – Média e variância de todas as métricas D.

SAP- Plotando a métrica D’ de cada pacote ao longo do tempo



SAP

Dependências-Acíclicas

Dependências-Estáveis

Abstrações-Estáveis

Estabilidade

Autores

Cláudio Roberto Xavier

Samuel Lopes

Technology

Sap – stablility and abstract principle