Atenção: esse artigo tem uma palestra complementar. Clique e assista!
Atenção: esse artigo tem um vídeo complementar. Clique e assista!
Desenvolver sistemas é mais do que criar classes ao 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 ajustará 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 softwares orientados a objetos mal construídos são sinônimos de dores 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 as 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."
[...] continue lendo...