O t\u00edtulo \u00e9 bastante provocador, afinal, ao contr\u00e1rio do que ele sugere, o paradigma orientado a objetos prop\u00f5e justamente oferecer alternativas mais elegantes para a extens\u00e3o de uma classe.<\/p>\n
Li o artigo intitulado Uniform Function Call Syntax<\/em> (Bright, Walter) e foi uma interessante reflex\u00e3o sobre as formas que utilizamos para estender as funcionalidades de uma classe j\u00e1 existente. As op\u00e7\u00f5es que tipicamente se apresentam:<\/p>\n 1. Adicionar a nova funcionalidade diretamente na classe<\/p>\n Essa alternativa s\u00f3 \u00e9 poss\u00edvel quando o c\u00f3digo fonte da classe est\u00e1 dispon\u00edvel para nossa aplica\u00e7\u00e3o, o que nem sempre \u00e9 o caso. Mesmo quando est\u00e1 acess\u00edvel, nem sempre \u00e9 conveniente faz\u00ea-lo: ser\u00e1 que aquela funcionalidade justifica a sobrecarga que impomos \u00e0 classe, e a prov\u00e1vel viola\u00e7\u00e3o do princ\u00edpio da responsabilidade \u00fanica?<\/p>\n 2. Heran\u00e7a<\/p>\n Seria a maneira mais adequada, mas esbarra com uma limita\u00e7\u00e3o imposta por Java ou outras linguagens de heran\u00e7a simples: como combinar v\u00e1rias extens\u00f5es? O exemplo do artigo \u00e9 muito bom. Imagine a classe Integer do Java, e que eu quisesse adicionar a funcionalidade aoQuadrado numa subclasse de Integer. Outro colega necessita do m\u00e9todo aoCubo e cria outra subclasse. Sem heran\u00e7a m\u00faltipla, como posso utilizar os dois m\u00e9todos de maneira simples?<\/p>\n Al\u00e9m disso, nem sempre essa \u00e9 uma op\u00e7\u00e3o: h\u00e1 classes que, justamente para evitar a confus\u00e3o oriunda do descontrole sobre subclasses, colocam-as como ‘final’. Ou seja, est\u00e3o seladas para heran\u00e7a.<\/p>\n 3. Composi\u00e7\u00e3o e Classe utilit\u00e1ria<\/p>\n As duas s\u00e3o maneiras mais elegantes, no meu ponto de vista, de adicionar a funcionalidade a uma classe existente. Digo isso do ponto de vista do encapsulamento. Sou capaz de adicionar a nova funcionalidade sem afetar a classe alvo. Mas n\u00e3o \u00e9 chato ter que saber que existe uma classe IntegerUtil, ou, pior ainda, regredir do formato sint\u00e1tico tradicional que se aplica na orienta\u00e7\u00e3o a objetos para o uso procedural? N\u00e3o \u00e9 muito melhor escrever objeto.metodo<\/strong> do que ClasseUtilitaria.fazAlgo(objeto)<\/strong> ?<\/p>\n Foi a\u00ed que esbarrei com essa nova modalidade de extens\u00e3o: os m\u00e9todos de extens\u00e3o (Extension Method). Ele n\u00e3o difere do ponto de vista conceitual de uma classe utilit\u00e1ria. O diferencial dele \u00e9 a forma de uso.<\/p>\n N\u00e3o seria legal, ao inv\u00e9s de usar:<\/p>\n usar:<\/p>\n Pois \u00e9 isso que os m\u00e9todos de extens\u00e3o habilitam. O c\u00f3digo abaixo seria uma aproxima\u00e7\u00e3o em C# da classe utilit\u00e1ria:<\/p>\n O this<\/strong>, no c\u00f3digo anterior, faz a m\u00e1gica. Ainda n\u00e3o consegui relacionar o impacto desse novo recurso com as linguagens din\u00e2micas, como o Ruby. Alguma opini\u00e3o?<\/p>\n Refer\u00eancias:<\/p>\n Bright, Walter. Uniform Function Call Syntax<\/a>. Dr.Dobb’s. 2012.<\/p>\nInteger resultado = IntegerUtil.aoQuadrado( meuInteger );<\/pre>\n
Integer resultado = meuInteger.aoQuadrado();<\/pre>\n
public static class IntegerUtil {\n\u00a0\u00a0 public static Integer aoQuadrado(this<\/strong> Integer valor) {\n\u00a0\u00a0\u00a0\u00a0\u00a0 return valor * valor;\n\u00a0\u00a0 }\n}<\/pre>\n