Open/Closed Principle: Estenda comportamentos sem alterar o código

Melhorias de código e design de software usando algumas técnicas da orientação a objetos e principalmente o princípio Aberto/Fechado (Open/Closed principle - OCP) para que possamos estender o comportamento de uma classe sem modificá-la.

De que se trata o artigo

Melhorias de código e design de software usando algumas técnicas da orientação a objetos e principalmente o princípio Aberto/Fechado (Open/Closed principle - OCP) para que possamos estender o comportamento de uma classe sem modificá-la e também sem comprometer o código-fonte que já foi implementado e testado.

Em que situação o tema é útil

Em qualquer situação onde é necessário introduzir novas funcionalidades em um sistema ou código já existente, equipes de manutenção de software que precisam fazer alterações sem que isso introduza algum tipo de erro, manutenção de código legado e melhorias de design tendo como objetivos a criação de classes que sejam extensíveis, mas, que não permitam serem modificadas.

Open/Closed Principle

Mudanças ou novos requisitos em projetos de software são sempre constantes e para isso nós alteramos o nosso código-fonte para que nosso software possa atender aos nossos clientes e usuários. O grande problema é que muito possivelmente a nossa aplicação já esteja testada e em produção. Estas novas alterações têm a possibilidade de introduzir erros. Para que isto não ocorra, podemos usar algumas técnicas que nos ajudam a abordar esse tipo de problema, de modo que as alterações sejam feitas de forma consciente e sem quebrar o que já está construído.

Uma simples mudança em uma parte de um software pode resultar em atualizações em inúmeros pontos da aplicação que fazem uso deste trecho de código que foi modificado, ou seja, existe um alto nível de dependência entre a classe modificada e os usuários que a utilizam. Na verdade, isto é considerado como sendo um design mal feito, de difícil manutenção e nem um pouco extensível, já que esta mudança deveria ser transparente para todos aqueles que dependem deste código modificado.

Por outro lado, a cada mudança feita há sempre uma possibilidade de introduzir comportamentos inesperados (bugs) na aplicação, que podem passar despercebidos durante nossos testes e, com isso, muito possivelmente estes bugs sejam descobertos somente quando o software estiver em produção.

Por mais estranhas que as possibilidades comentadas possam parecer, é muito comum nos depararmos com estes tipos de situações durante o desenvolvimento de um software. Mas, como garantir que modificações em um software sejam feitas de forma segura e da maneira mais correta possível? Como nosso código pode ser projetado de forma que todas as outras partes não precisam nem ficar sabendo desta alteração?

Infelizmente, não existe uma fórmula mágica, mas, existe um conjunto de boas práticas que devem sempre ser seguidas. Dentre este conjunto de boas práticas, podemos citar:

· Uso de padrões de projeto (ou do inglês Design Patterns)

· Desenvolvimento dirigido por testes (ou do inglês Test Driven Development – TDD)

· Não adicionar complexidade desnecessária ao nosso código (princípio YAGNI)

· Manter as coisas sempre o mais simples possível (princípio KISS)

Nota do DevMan

Test Driven Development (TDD) – é uma técnica de desenvolvimento de software na qual um desenvolvedor escreve um teste automatizado que defina uma melhoria, correção ou uma nova funcionalidade. Após isso, é feito o código a ser avaliado pelo teste e consequentemente validado. Posteriormente, o código é refatorado e testado novamente com intuito de checarmos se esta refatoração não alterou o comportamento do código escrito anteriormente.

Na verdade o nome TDD é um nome ruim, já que ele utiliza testes para guiar o desenvolvimento da aplicação, mas o foco não são os testes e sim o design da aplicação. Criando testes antes da escrita do código fornece a visão de como os outros irão utilizar o método a ser desenvolvido (semelhante ao uso de uma API), já que estamos desenvolvendo de fora para dentro (dos testes para dentro da implementação).

Nota do DevMan

Princípio YAGNI – Esta abreviação quer dizer You Ain´t Gonna Need It e defende que não devemos adicionar funcionalidades ao nosso código até que elas sejam realmente necessárias. Este princípio tem como principal função fazer com que o requisito de negócios seja satisfeito, nenhuma linha de código a mais deve ser adicionada.

Nota do DevMan

Princípio KISS – Esta abreviação em inglês que significa Keep It Simple, Stupid! e diz que devemos valorizar a simplicidade do código eliminando toda a complexidade desnecessária. Este princípio teve a sua inspiração diretamente do princípio da Navalha de Occam e das máximas de Albert Einstein ("tudo deve ser feito da forma mais simples possível, mas não mais simples que isso")." [...] continue lendo...

Artigos relacionados