Desenvolver sistemas é mais do que criar classes a esmo, formulários e colocar tudo ali. É pensar no problema, possíveis soluções e unir tudo em algo que não cause mais problemas. Por isso existem os bons princípios para desenvolvimento de softwares orientados a objetos. Neste artigo vamos estudar os mais divulgados.
Para que serve
Os princípios são resultado de estudos da engenharia de software, e são utilizados para que se criem sistemas que sejam fáceis de dar manutenção, que possam responder rápido às mudanças de regra de negócios e flexíveis.
Em que situação o tema é útil
Desenvolver um sistema flexível é bom para você, como desenvolvedor, e bom para seu cliente. Para você é bom porque levará menos tempo para ajustar o sistema e o fará com segurança. Para seu cliente é bom porque ele verá que o sistema que ele utiliza é estável e que não vai deixá-lo na mão.
Resumo do DevMan
Os princípios de modelagem de objetos são guias que nos levam a construir softwares flexíveis e estáveis. Evitando dependência excessiva entre as classes, duplicação de código e outros problemas mais. Neste artigo vamos estudá-los com exemplos práticos para que você leitor os assimile e possa utilizá-los no seu dia-a-dia.
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.
S de Single Responsability Principle (SRP)
Este é o princípio da responsabilidade única, que recomenda que uma classe só deva ter um motivo para sofrer alguma alteração. Sendo assim, podemos resumir que uma classe qualquer em seu sistema deva ter uma tarefa única e específica. Isso, contudo, não quer dizer que se tenha apenas um único método, mas que todos os métodos criados trabalhem juntos em um único objetivo, atender a responsabilidade da classe. Outros autores também chamam este princípio de coesão.
Para entendermos seu significado vamos imaginar um cenário que todos conhecem. Digamos que você possui uma classe que represente uma Nota Fiscal, a classe NotaFiscal. E você a codificou de tal forma que ela mesma, além de conter seus itens, seus cálculos, também sabe como se salvar e se recuperar do banco de dados e até mesmo sabe como se exportar nos mais diversos formatos. Se pararmos para pensar, você acha que é responsabilidade da NotaFiscal saber tudo isso? Apesar da forma que foi construída, temos essa classe lidando com mais de uma situação de responsabilidades diferentes. Se amanhã a forma de exportação é alterada, é preciso corrigir a classe. Se também algo muda na regra de negócio referente a uma nota fiscal, essa classe também precisa ser corrigida, ou seja, temos aqui mais de um motivo para essa classe ser alterada, e isso não é bom. Não é bom porque cada responsabilidade é um arco de mudanças, que muito provavelmente estão entrelaçadas. Estamos falando aqui de responsabilidade, mas o que é isso para uma classe?
...
