SOLID Ruby: Open-Closed Principle

Semanas atrás publicamos um post sobre SOLID Ruby, artigo de Lucas Húngaro, desenvolvedor da equipe de Ruby da Gonow. Lucas examinou a aplicação do Single Responsability Principle em detalhes, e neste post analisa o Open Closed Principle.

Por Lucas Húngaro*

Muitos dos princípios da programação orientada a objetos foram criados com linguagens estáticas em mente. Esse é o caso do Open-Closed Principle, enunciado da seguinte maneira:

“Software entities (classes, modules, functions, etc) should be open for extension, but closed for modification.”

Originalmente, a ideia é que, uma vez finalizada, uma entidade só poderia ser modificada para correções. Qualquer nova “feature” deveria ser implementada em uma nova entidade, que aproveitaria o código da primeira principalmente através de herança. Isso resulta em reaproveitamento da implementação, mas não garante a consistência da interface.

Um pouco depois, com a introdução e popularização de classes abstratas e recursos de linguagem como Interfaces, o princípio evoluiu e passou a ser aplicado em conjunto com o DIP, fazendo com que o código sempre dependesse de interfaces ao invés de implementações. Com isso, era possível reaproveitar uma interface (closed) e modificar a implementação (open).

Mas e nas linguagens como Ruby, em que abrir uma classe é tão simples como defini-la e pode ser feito a qualquer momento? Será que esse princípio se aplica? Isso sempre é tema de muita discussão e aqui vai minha visão sobre isso.

Bem, com Ruby temos algumas formas de modificar uma classe, como herança, mixins, reabrir a classe ou usar metaprogramação. Perceba que, exceto pela herança, as outras maneiras infringem a ideia original do princípio. Mas, como já vimos, o próprio princípio evoluiu para abraçar mudanças nas linguagens e paradigmas.

O importante, principalmente em linguagens com Duck Typing (que, como já vimos, não dão a mínima para tipos), é que a interface seja fechada. Não importa o modo que você escolher para fazer as modificações, desde que a “superfície de contato” entre as entidades permaneça estável.

No exemplo do post anterior poderíamos modificar as classes que passamos como dependências via parâmetro e utilizá-las sem problemas, desde que a interface permanecesse a mesma. Uma vantagem adicional da tipagem dinâmica é que nesse caso podemos utilizar também herança (modificando o “tipo”) sem precisar modificar o código cliente, que só se importa com a interface.

Dessa forma, podemos modificar um pouco o enunciado do OCP para adaptá-lo à nossa linguagem preferida:

“Software entities (classes, modules, functions, etc) should be open for extension, but closed for interface modification.”

Recomendo esse vídeo-podcast sobre o assunto: Monkeypatching and the Open-Closed Principle.

*Acesse o post anterior sobre Single Responsability Principle no blog pessoal de Lucas Húngaro.

Tags:, ,

Categorias:

Gonow

O blog Gonow Tecnologia é voltado para publicação de notícias sobre eventos e temas relacionados ao mercado de Tecnologia de Informação e Comunicação (TIC), Design e User Experience (UX), além de rico conteúdo técnico - incluindo ví­deos na íntegra de palestras sobre os assuntos divulgados - e referências sobre as mais diversas linguagens de programação, frameworks e plataformas de desenvolvimento.

Veja todos os posts de "Gonow"

Comments are closed.