Mandamentos da Orientação a Objetos - Artigo .Net Magazine 79

Sempre se fala da orientação a objetos como a bala de prata para todos os problemas, desde análise à programação. Porém, colocar tudo em classes não resolve o problema, podendo até mesmo criar muito mais problemas, pois um software orientado a objetos mal construído é sinônimo de dor de cabeça.

Acredito que todos os leitores já sabem o que é uma classe, uma propriedade, um método. Já conhecem estruturalmente a orientação a objetos, o que falta é saber como modelar tudo isso de forma adequada.

Regras de negócio mudam constantemente e isso faz com que seja um desafio construir um software que responda rápido às mudanças apresentadas. Aplicativos bem desenvolvidos podem oferecer vantagem competitiva para seus clientes, contudo o projeto mal modelado pode levar a prejuízos por enrijecer processos, já que não se adapta às mudanças de forma eficiente. Vamos identificar os elementos de um bom design e de um não tão bom. Enquanto estiver lendo esses elementos, compare com o(s) sistema(s) que você desenvolve(u).

Modelagem boa

Aplicações bem desenhadas oferecem rotinas que são robustas, de fácil manutenção e reutilizáveis. Elas devem estar aptas a se adequar às mudanças sem afetar sua modelagem. Um exemplo disso seria uma aplicação onde é necessário exportar um arquivo em um determinado formato. Adicionar novos formatos ao sistema atual deve ser uma tarefa fácil. As três características de um bom design são:

• Manutenção – É a facilidade com que um sistema pode ser alterado para aplicar novas regras de negócio exigidas, mas não só regras e sim também melhorar seu desempenho, corrigir falhas e outras solicitações mais. Aplicações que possuem um bom design exigem poucos recursos (tempo, esforço e até mesmo capital) para realizar sua devida manutenção;
• Reusabilidade – Em um sistema adequado é possível que os seus componentes possam ser reutilizados por outros sem grandes dificuldades;
• Robustez - É a estabilidade do sistema em situações extremas do tipo: tratamento de entradas erradas por parte de usuários, carga máxima de dados em determinado momento do dia.

Modelagem ruim

Ninguém desenvolve um software não muito bom porque quer. Isso é decorrência da inexperiência ou de uma modelagem feita às pressas para atender a um tempo limite de entrega. Sistemas construídos dessa maneira costumam ter os seguintes problemas em comum:

• Rigidez – Dizemos que um sistema é rígido quando uma alteração nele é difícil. E essa alteração é considerada difícil porque rotinas internas estão, muito provavelmente, entrelaçadas a um ponto onde alterar qualquer coisa leva a uma cascata de alterações. Nessas situações quando o sistema fica grande, é difícil estimar o prazo para uma alteração já que todo o impacto deve ser medido antes;
• Fragilidade – Por ter rotinas muito ligadas umas às outras, a alteração em uma leva a problemas nas outras. Quem aqui nunca alterou algo em um sistema que depois causou um problema em uma parte que parecia não estar relacionada com a alteração feita? Corrigir esse tipo de problema pode levar a outros, desencadeando uma leva de ajustes que custam tempo e que consequentemente custam dinheiro. Um sistema nessa situação perde sua credibilidade, pois vive em contenção de erros, impedindo que seus desenvolvedores mantenham uma qualidade futura ao projeto;
• Reusabilidade – Neste caso, a falta da mesma. Quando for preciso reutilizar alguma rotina, o trabalho pode ser tão difícil que é menos custoso desenvolver novamente essa rotina.

Agora que vimos como se parece, do ponto de vista arquitetural, um bom sistema e um ruim, vamos conhecer alguns princípios que podem determinar o sucesso de design.

Seja S.O.L.I.D.

Essa sigla é um acrônimo para a palavra em inglês “solid”, que significa sólido, solidez. Cada letra representa um acrônimo de um princípio, ou seja, temos um acrônimo de um acrônimo. Esse conjunto é o resultado de estudos e experiências de vários desenvolvedores, e foi primeiramente catalogado por Robert “Uncle Bob” Martin (veja sessão links) em seu livro “Applying Principles and Patterns”. Vamos conhecer cada princípio." [...] continue lendo...