.NET - Princípios de Programação e Padrões de Projetos - I

Uma das melhores maneiras de aprender a escrever um bom código é aprender a reconhecer um código ruim.

Um código que não funciona é obviamente um código ruim, mas existem outras características em um código para que ele seja declarado como 'ruim'.

Na área de desenvolvimento de software o termo code smell (código que cheira) é aplicado quando o código fonte de qualquer programa indica algum problema.

Não pense que um código que cheira é um código com bugs, não, o código aparenta estar tecnicamente correto e não impede o programa de funcionar. Na verdade o code smell indica que o projeto de software não foi bem feito e que vai apresentar uma alta taxa de manutenção com riscos de apresentar bugs catastróficos no futuro.

A seguir temos algumas das características que um código ruim possui para ser classificado dessa forma:

  1. Rigidez

Se mudar um trecho de código vai exigir mudanças em outras partes do código, que por sua vez vai exigir mudanças em um outras partes, que...etc. O código pode ser considerado rígido e malcheiroso.

  1. Fragilidade

Programadores cínicos costumam dizer que existem sempre três erros em qualquer aplicação:

  • o que você sabe que existe,
  • o que você não conhece,
  • e o que você vai criar quando for corrigir o que você conhece.

Um código frágil quebra o código de maneiras inesperadas, em áreas que não parecem estar relacionadas ao que você está trabalhando.

  1. Imobilidade

Uma situação comum: você está modificando uma aplicação, e, você quer reutilizar o que se supunha ser um código de propósito geral.

Mas o trecho de código que você precisa está tão arraigado que a única maneira de reutilizá-lo vai te obrigar a cortar e colar.
Você está se deparando com um código que é imóvel.
Isso é um desperdício de tempo e é um mau cheiro.

  1. Redundância

Um código imóvel é a causa primária de um código mal cheiroso; a redundância é outro fator que contribui para isso.

Se houver qualquer trecho de código que aparece em mais de um lugar, você tem um problema de mau cheiro, porque se o trecho precisar ser alterado (e vai), você precisará alterá-lo em todos os lugares.

  1. Opacidade

Se você já se deparou com uma situação onde precisa dizer : "Não sei como isso funciona, mas funciona..."
Você tem um problema, e eu não preciso de lhe dizer que isto é inaceitável, certo ?
Se você não compreende o código como você vai saber alterá-lo ?
Se você precisa de comentários no código para entender o que ele faz então o seu código é opaco e cheira mal.

Acrescente aos sintomas acima as seguintes características de um código que 'cheira':

Então o que um bom programador pode fazer para escapar de ter o seu código/projeto classificado como mal cheiroso ?

Quando você estiver avaliando seu projeto/código faça duas perguntas:

1- Este projeto é realmente necessário ?

2- O código usado viola de qualquer forma os princípios básicos de projeto relacionados com as boas práticas ?

Se você suspeitar que uma dessas perguntas obteve um sim como resposta, então você deve revisar o seu projeto e/ou o seu código à luz dos princípios básicos das boas práticas de projetos.

Se um código violar quaisquer um destes princípios considere o custo de corrigir o seu código agora. Se a mudança for simples então você pode implementá-lo caso contrário considere reescrever tudo novamente adotando as boas práticas.

Se para tornar o seu código ou o seu projeto aderente às boas práticas de projeto você tiver que adicionar um complexidade maior ainda considere reescrever tudo novamente à luz das boas práticas.

Mas de quais princípios estamos falando ? Quais são eles ?

Na verdade existem muitos princípios que podem ser adotados, e, você vai encontrar muitos princípios distintos mencionados por diversos autores mas neste artigo eu vou me ater a 4 princípios básicos.

Estes quatro princípios são geralmente considerados os mais importantes, e muitos dos outros princípios são variações ou aperfeiçoamentos desses princípios.

Vejamos um resumo sobre cada um deles:

1 - O Princípio da Responsabilidade Única (SRP) - The Single Responsibility Principle

Uma classe deve ter um, e somente um, motivo para mudar.

2- O princípio Aberto-Fechado (OCP) - The Open Closed Principle

Você deve ser capaz de estender um comportamento de uma entidade de software (classe), sem modificá-la.

Este princípio estabelece que os objetos devem estar abertos para extensão, mas fechados para modificação.

Basicamente, isso significa que você deve ser capaz de adicionar um novo comportamento sem mudar as coisas velhas.

3- Princípio da Substituição de Liskov - (LSP) - The Liskov Substitution Principle

As classes derivadas devem ser substituíveis por suas classes base.

O LSP é um refinamento de polimorfismo básico. Dizendo em outras palavras: você não criar uma classe filha que seja menos capaz que sua classe pai.

4- A Lei de Deméter

A Lei de Deméter, também conhecido como o Princípio do Conhecimento Mínimo, afirma que qualquer objeto dado só deve referenciar diretamente seus próprios membros e os membros dos objetos que ele instância.

Além desse princípios você deve considerar também os padrões de arquitetura e os padrões de projeto de software de forma ter o seu projeto classificado como um projeto aderente às boas práticas e um código que não cheira mal.

Um padrão de arquitetura de software básico que prega a separação das responsabilidades geralmente divide um projeto de software em camadas:

Além deste padrão podemos citar o padrão MVC (usado pelo ASP .NET MVC):

Padrões de Projeto

E os padrões de projeto que são soluções já encontradas, testadas e certificadas e que podemos aplicar aos nossos projetos e não ter que reinventar a roda...

Os padrões de projeto foram catalogados e compõem o que podemos chamar de uma espécie de manual de boas práticas a serem seguidas e utilizadas em projetos de software orientados a objetos.

Dos catálogos mais conhecidos e usados destaca-se o primeiro e considerado mais importante, escrito em 1995 pela Gang of Four ou GoF. O catálogo original apresentou algo em torno de 23 padrões de projetos descritos e implementados na linguagem C++ ou SmallTalk.

Veremos neste artigo os principais padrões, um resumo básico e sua implementação na linguagem C#.

Vamos iniciar com uma classificação dos padrões quanto a sua finalidade. Nesse quesito podemos ter os padrões classificados como:

  1. Criacionais - criação de objetos
  2. Estruturais - composição de classes e objetos
  3. Comportamentais - interação entre classes e objetos

O catálogo Gof também classifica os padrões de projeto quanto ao propósito e ao escopo da seguinte forma:

Na continuação deste artigo irei abordar o padrão Factory dando um breve resumo sobre o padrão e sua implementação na linguagem C#.

Slm 130:1 Das profundezas clamo a ti, ó Senhor.

Slm 130:2 Senhor, escuta a minha voz; estejam os teus ouvidos atentos à voz das minhas súplicas.

Slm 130:3 Se tu, Senhor, observares as iniqüidades, Senhor, quem subsistirá?

Slm 130:4 Mas contigo está o perdão, para que sejas temido.

Slm 130:5 Aguardo ao Senhor; a minha alma o aguarda, e espero na sua palavra.

 

José Carlos Macoratti