Atenção: esse artigo tem uma palestra complementar. Clique e assista!
Refatoração de código aplicando princípios de orientação a objetos que facilitam a implementação das soluções chamadas de padrões de projetos, implementado o padrão Strategy para definir grupos de classes com comportamentos diferentes que podem ser trocados em tempo de execução.
Para que serve
Tornar projetos de software mais flexíveis, baseando-se nos princípios da orientação a objetos, para também que se tornem reutilizáveis. Os padrões de projetos são uma maneira de usar os princípios da orientação para resolver problemas complexos do desenvolvimento de software.
Em que situação o tema é útil
No desenvolvimento de sistemas orientados a objetos, em projetos onde os requisitos possuem uma constante mudança e qualidade for uma meta a ser alcançada.
Resumo do DevMan
Algumas pessoas sentem dificuldade para usar padrões de projetos e construir designs elegantes nos seus sistemas, pois não conseguem encontrar situações para usá-los, apesar de ter o conhecimento teórico sobre alguns padrões. Isto é comum porque os problemas existentes em um software dificilmente são solucionados apenas com um padrão de projeto. Por isto você precisa encher sua cabeça com vários deles para então ser capaz de criar uma solução completa usando os padrões para criar um bom design. Fazendo uma analogia a um programa de computador, os padrões de projetos funcionam como drivers que devem ser carregados para o seu cérebro para que você possa usá-los quando necessário. Esta é maneira mais fácil de conseguir aplicá-los, por tanto quanto mais padrões diferentes você conhecer mais facilidade terá para solucionar um problema com eles.
Quando se está criando um software, a tendência é torná-lo o mais reutilizável possível, ou seja, minimizar o trabalho necessário para fazer alterações ou implementar novas funções, mas existem muitos problemas que dificultam o trabalho do programador de tornar o software reutilizável. Um exemplo destes problemas é o acoplamento entre as classes do sistema, pois sem o conhecimento adequado o programador provavelmente fará um programa cujas classes estarão fortemente interligadas.
Alto acoplamento e baixa coesão são dois problemas que acontecem muito com sistemas mal projetados. Acoplamento é o nome que se dá para a ligação existente entre duas classes, mas não no sentido de relacionamento, mas sim, no que uma conhece da outra. Quando uma classe conhece demais sobre outra, esta torna-se dependente da outra e vice-versa. Assim, se essa outra sofre alteração, é muito provável que a primeira também tenha que se ajustar em relação à mudança sofrida. Portanto, um nível grande de acoplamento não é recomendado.
A coesão por sua vez pode ser traduzida como a objetividade que uma classe pode possuir. É muito comum, mas não ideal, encontrar classes que realizam várias operações, por exemplo: imprimir um relatório e exibir uma mensagem na tela. Uma baixa coesão pode causar problemas durante a manutenção do sistema, visto que uma classe que faz várias coisas ao ter seu código alterado pode implicar em falhas e outras funcionalidades.
Um padrão de projeto é uma solução para problemas como o citado anteriormente. Claro que se pode inventar uma solução própria, mas até que ponto vale a pena investir tempo para criar uma solução para um problema que já foi solucionado? Além do mais quando um padrão de projeto é implementado, um projeto não está sendo prejudicado, pois um padrão de projeto não é simplesmente uma solução, ele normalmente é a melhor solução, uma vez que estão embasados em princípios de programação orientada a objetos.
Princípios SOLID - Essa sigla é um acrônimo para a palavra em inglês solid, que significa sólido, solidez. Cada letra representa um acrônimo de um princípio, ou seja, temos um acrônimo de um acrônimo onde: S de Single Responsability Principle (SRP), O de Open/Closed Principle (OCP), L de Liskov Substitution Principle (LSP), I de Interface Segregation Principle (ISP) e D de Dependency Inversion Principle (DIP). Esse conjunto é o resultado de estudos e experiências de vários desenvolvedores que foram coletados e organizados formando boas práticas básicas para um bom sistema orientado a objetos. Os princípios de modelagem de objetos são guias que levam a construir software flexível e estável. Evitando dependência excessiva entre as classes, duplicação de código e outros problemas mais.
Os princípios de orientação a objetos são como regras de um protocolo que devem ser seguidos para que se alcance um bom design de projeto – os princípios ensinam o que é bom e o que deve ser evitado em um projeto de software. Conhecer pelo menos alguns destes princípios já é um começo se o objetivo é dominar a técnica de programação orientada a objetos.
Um bom design de software
O bom design de um software possui três características reconhecidas:
Manutenção – É a facilidade com que um sistema pode ser alterado para aplicar novas regras de negócio exigidas, mas não só regras e sim também melhorar seu desempenho, corrigir falhas e outras solicitações mais. Aplicações que possuem um bom design exigem poucos recursos (tempo, esforço e até mesmo capital) para realizar sua devida manutenção.
Reusabilidade – Em um sistema adequado é possível que os seus componentes possam ser reutilizados por outros sem grandes dificuldades.
Robustez- É a estabilidade do sistema em situações extremas do tipo: tratamento de entradas erradas por parte de usuários, carga máxima de dados em determinado momento do dia.
...
