Seções iMasters
.NET + Gerência de Projetos

.NET: princípios de programação e padrões de projetos – Parte 01

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:

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.

Fragilidade

Programadores cínicos costumam dizer que existe 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.

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 e isso é um desperdício de tempo e é um mau cheiro.

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.

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.

Obs: Acrescente aos sintomas acima as seguintes características de um código que cheira: código duplicado, métodos e classes gigantescas, a utilização de muitos parâmetros, classes que usam métodos de outras classes em demasia e classes que possuem dependência em detalhes de implementação de outras classes.

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 projetos 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 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?

Na verdade, existem muitos princípios que podem ser adotados e você também vai encontrar muitos princípios distintos mencionados por diversos autores, mas neste artigo eu vou me ater a quatro 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: também conhecida 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 que o seu projeto seja 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:

  • Camada de apresentação;
  • Camada de serviço;
  • Camada de negócio;
  • Camada de dados;
  • Camada de persistência.

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

  • Model;
  • View;
  • Controller.

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 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 com 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#.

Comente também

3 Comentários

João Batista Neto

Belo artigo, José Carlos!

Se valer minha opinião, seria bacana você seguir exatamente a mesma linha para os próximos, por exemplo, em vez de falar sobre Factory em C#, fale sobre Factory de forma abstrata.

O conteúdo desse artigo específico, pode ser utilizado, independentemente da linguagem/plataforma que o desenvolvedor utilizará em seu projeto. Seria bacana se os próximos também fossem assim.

;)

David Ramires

Ótimo artigo, acho interessante que fale sobre Factory de forma abstrata, mas que alguns exemplos sejam em C#, já que estamos falando de .NET! :)

abs

Qual a sua opinião?