Padrões de projeto no dia a dia - Revista ClubeDelphi 145

Por mais que sempre se fale de padrões de projeto, ou da própria orientação a objetos, sempre existem aqueles que dizem: “isto não é para mim”, ou “não consigo aplicar, meu projeto não está totalmente desenvolvido com OO”.Engana-se quem acredita que não é possível seguir algumas boas práticas só por não ter todo o sistema desenvolvido de forma orientada a objetos. É possível sim aplicar em pequenas partes algumas boas práticas e padrões. Como fazer isso? É justamente o que esse artigo traz. Mas antes, uma visão do que está por de trás dos padrões.

Princípios

Existe um fato irrefutável no desenvolvimento de sistemas: requisitos sempre mudam. Outro fato que sempre vejo nas organizações é que elas sabem disso e por isso, tentam melhorar sua forma de captação desses requisitos. Isso é bom. Contudo, a atenção não deve estar presa somente a isso, não significa que por se ter requisitos de qualidade, teremos um sistema de qualidade ou, se esses requisitos modificarem será fácil aplicar a modificação pedida.É aí que a orientação a objetos em conjunto com os padrões pode ajudar. Existem alguns princípios de modelagem e programação OO que levam os padrões de projetos a serem considerados como boas práticas, esses mesmos conceitos podem ser aplicados sem a utilização dos padrões. Portando, a ideia é entender esses princípios e procurar aplicá-los em nosso desenvolvimento. São eles: Modelar para interfaces, favorecer composição sobre herança e encontrar o que varia, e encapsulá-lo.

Modelando, desenvolvendo para interfaces

Em qualquer desenvolvimento, seja ele orientado a objetos ou não, temos dois problemas que impedem do mesmo ser fácil de ser alterado: baixa coesão e alto acoplamento.A baixa coesão é quando encontramos rotinas/classes que realizam várias funções, mais do que deveriam fazer por seu conceito. Já o alto acoplamento é quando temos rotinas/classes que são muito dependentes de outras, aonde um alteração nessa conduz a um cascateamento de alterações, ou seja, é o quanto as rotinas/classes estão dependentes uma das outras.Mas porque uma interface resolveria esse problema? Uma interface ou classe abstrata simplesmente expõem uma assinatura de métodos que pode ser utilizada por outra rotina. A implementação real não está nela, mas sim outra classe que a implementa. Dessa forma, se esperarmos por uma interface, teremos acesso somente à definição dos métodos, como eles serão implementados não será importante. Mais adiante teremos a parte prática onde será possível ver isso acontecendo.

Compor ou herdar?

Quem está aprendendo orientação a objetos sempre se atenta muito ao recurso de herança. É a primeira coisa que estudantes aprendem. É a primeira forma de realizar a tão sonhada reutilização de funcionalidades, isso porque ela permite que o interior de uma classe base seja vista pelas suas subclasses. Esse é o modo mais fácil. Existe um segundo recurso para reutilização de funcionalidade, a composição. Nela objetos diferentes são interligados através de suas interfaces para garantir reutilizações mais complexas. A composição pode ser um pouco mais difícil de entender inicialmente, mas possui vantagens sobre a herança.A herança permite que de forma fácil seja alterada a implementação de uma funcionalidade. Isso é obtido através da técnica de sobrecarga de operações. Por ser fácil de implementar, passa uma ideia de que agora aquele trecho de código está flexível, mas não é verdade. Ela é resolvida em tempo de compilação e isso deixa o sistema um pouco inflexível porque em tempo de execução qualquer alteração na implementação de uma classe base não é permitida. Os mais puristas em orientação a objetos dizem que a principal desvantagem da herança está na exposição do interior de uma classe base à suas subclasses, quebrando assim o conceito de encapsulamento. Essa exposição conduz a um modelo de dependência de implementações entre as classes envolvidas, isso porque a parte exportada da classe base faz parte também das subclasses. Qualquer alteração na classe base implica em alterações nas subclasses, o que não é recomendado quando se deseja um modelo flexível. A composição por sua vez é resolvida em tempo de execução. Ela exige que as interfaces sejam respeitadas, consequentemente devem ser bem planejadas para que não haja impedimentos de reutilização, isso porque a implementação de composição é feita através de referências. Algumas desvantagens vistas na herança, como quebra de encapsulamento e dependência de implementação, não são vistas na composição, isso porque os objetos envolvidos são acessados somente por suas interfaces. O impacto disso na modelagem, é que classes manterão seu encapsulamento e estarão voltadas para sua tarefa apenas, porque não há o que herdar de outras classes, obedecendo assim o conceito de alta coesão.Porém, como nada é perfeito, o uso de composição prende o comportamento do modelo aos relacionamentos entre os objetos, que pode implicar em maior complexidade. Os padrões de projeto fazem uso extenso de composição e quando é necessário criar heranças, elas são baseadas em classes abstratas. Esse é um dos motivos que consagram os padrões de projeto como prática de flexibilização de modelos, deixando um código preparado para eventuais mudanças de requisitos.

...

Quer ler esse conteúdo completo? Tenha acesso completo