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)
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).
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.
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").
Classes Abstratas
Quando criamos nossas classes é comum percebermos que algumas delas possuem alguns métodos em comum (por exemplo: andar, voar ou correr) e que estes métodos podem se comportar de forma idêntica, ou assumir um comportamento diferente em cada classe que o contém.
As classes abstratas são a base do modelo de abstração na programação orientada a objetos. Uma classe abstrata representa um modelo abstrato para outras classes. Através da herança, este modelo permite reaproveitar métodos já implementados, possuindo assim um comportamento igual neste caso, e também fazer com que as classes derivadas definam as suas próprias versões de um mesmo método, possuindo assim um comportamento diferente neste outro caso.
A abstração é um poderoso recurso que faz com que os usuários de uma classe não precisem conhecer a sua implementação concreta, ao invés disso, apenas conhecer o modelo abstrato que possui o método em que ela necessita, não importando como as diferentes classes se comportam em relação a este método.
...
