Sap – stablility and abstract principle

Oque é SampleAbstractionsPrinciple?Princípio de Estabilidade e Abstração

SAPDefiniçã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.

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

ExemploExemplo de mudança no cliente. 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.

ExemploExemplo de mudança no cliente. 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”.

ExemploExemplo do código Copy void Copy(){int c;while ((c = ReadKeyboard()) != EOF)WritePrinter(c);}

ExemploExemplo de mudança no cliente. 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.

ExemploExemplo de mudança no cliente. 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ênciasInvertendo dependências com OOD Uma forma de caracterizar o problema acima é de notar que o módulo que contémum 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.

ExemploclassReader{ 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);}

ExemploNo 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" dependesomente 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átilCertamente 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ênciaA 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 nadaem 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ênciaClasses 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áveisAs 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áveisAs 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 EstabilidadeComo 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 EstabilidadeCa: 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 EstabilidadeO PSD diz que a métrica de um pacote que deve ser maior do que as métricas I dopacotes 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 idealconfiguração de um sistema com três pacotes.

SAPEste 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 nopacote(Abstração): A = Na / NcUm 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 = Imaximamenteinstável eAbstratoI = 0, A = 0maximamenteestável econcreto

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 principalO pacote deve estar ligado ou próximo da seqüência principal(Distância D): D = | A + I - 1 | / √ 2Intervalos 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 principalD = 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íclicasDependências-EstáveisAbstrações-EstáveisEstabilidade

AutoresCláudio Roberto XavierSamuel Lopes

Sap – stablility and abstract principle

Mais conteúdo relacionado

Mais procurados (10)

Semelhante a Sap – stablility and abstract principle (20)

Mais de Engenharia de Software Ágil (20)

Último (11)

Sap – stablility and abstract principle