SOLID: Padrões flexíveis para suas classes C#

[rotulo-mentoring/]

Uma das maiores dificuldades nos dias atuais em termos de desenvolvimento de software se refere à manutenção de sistemas computacionais. Pesquisas indicam que as empresas gastam mais de 80% do orçamento destinado ao software em manutenção.

Isso ocorre porque na maioria dos desenvolvedores de sistemas não seguem os princípios da orientação a objetos e não utilizam os padrões de projetos e técnicas corretas de desenvolvimento.

São sistemas mal codificados que o tornam difícil de manter e evoluir. Outros ainda utilizam outros paradigmas, como a programação estruturada, que demanda muito mais manutenção que o paradigma orientado a objetos.

Em sistemas de informação que adotam o paradigma orientado a objetos, existem vários padrões, princípios e técnicas que o desenvolvedor deve seguir para que o sistema seja de fácil entendimento para outros desenvolvedores, de fácil manutenção após o sistema estar em ambiente de produção, que mudanças e novas funcionalidades não causem impacto em todo o sistema já existente.

Para um melhor entendimento sobre padrões de projetos é necessário um sólido conhecimento de orientação a objetos, do contrário, os padrões não serão bem compreendidos e o leitor acaba não sabendo aplicar estes no seu dia a dia.

Os princípios SOLID são a base para vários padrões de projetos criados e tornam softwares mais evolutivos, de fácil manutenção e mudanças efetuadas depois de finalizado, não impactando em outras áreas do programa, mudanças não propagam erros por outras partes desse sistema.

Muitos desenvolvedores discutem sobre os padrões de projeto de software, alguns dizem que os eles servem simplesmente para resolver problemas das linguagens de programação orientadas a objetos e que outras linguagens, com mais recursos, não precisam implementar nenhum desses padrões, mas esse não é um tópico abordado neste artigo.

Mas o que todos não discutem é que os princípios SOLID da orientação a objetos são a base para todo e qualquer projeto que siga este paradigma de desenvolvimento.

Com certeza, um código que não segue estes princípios não é de qualidade e um desenvolvedor ao olhar para esse código percebe isso. Existem várias dicas, macetes e técnicas para aplicação de todos estes princípios.

Para um código limpo e de qualidade, ele deve estar bem modularizado, cada classe deve ter a sua responsabilidade e as relações entre essas classes devem ser claras e bem definidas. É aqui que entra a ideia de código sólido, de onde vem o tema deste artigo.

Antes de entrarmos no estudo destes princípios, veremos quais os principais problemas encontrados em sistemas e que poderiam ser evitados com a aplicação de padrões de projetos e princípios de orientação a objetos (BOX 1):

• Rigidez: o sistema foi desenvolvido de forma que é muito difícil de mudar, qualquer alteração provoca uma cascata de operações por todo o restante do sistema;
• Imobilidade: a codificação foi feita de forma que o reuso é muito difícil, nenhuma parte do sistema pode ser reaproveitada em outro sistema;
• Fragilidade: o sistema foi feito de maneira que qualquer mudança o desestabiliza e o torna inoperante;
• Complexidade: o sistema foi desenvolvido utilizando-se de muitos padrões para resolver problemas simples, algo desnecessário (dependendo do caso);
• Repetição: mesmos trechos de códigos espalhados por todo o sistema, ao invés de estarem encapsulados em um método ou classe.

Aplicar boas práticas de engenharia de software nos rende muitos benefícios como manutenção facilitada, código organizado, dependências mais leves e uma arquitetura completamente aberta a receber atualizações, melhorias e novos recursos.

Além disso, quando temos o sistema com várias classes desempenhando bem o seu papel e cada método tendo o seu objetivo bem definido, ficam muito mais fáceis de ser realizados os testes unitários do sistema.

BOX 1. Padrões de Projeto GoF

Padrões de Projeto do GoF tem como objetivo solucionar problemas comuns de software relacionados as orientação a objetos.

Ganharam este nome de GoF, pois foram concebidos num livro de 1995 chamado Design Patterns: Elements of Reusable Object-Oriented Software por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, a chamada Gangue of Four. São organizados em três grupos:

• Padrões de criação: relacionados à criação de objetos (Abstract Factory, Builder, Factory Method, Prototype, Singleton);
• Padrões estruturais: tratam das associações entre classes e objetos (Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy).
• Padrões comportamentais: tratam das interações e divisões de responsabilidades entre as classes ou objetos (Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor)." [...] continue lendo...