Polimorfisme i escriptura d'Ànec a Rubí

El polimorfisme és una tècnica de programació que permet l'ús de parts del codi font que, mentre es manté constant, generar comportaments en temps d'execució.

Crear codi polimòrfic té un significat específic en la programació orientada a objectes: significa la creació d'una taxonomia de classes que implementen la mateixa interfície.

Així que si, per exemple, la meva interfície defineix un mètode de "getArea", cada classe que implementarà aquesta interfície té un mètode "getArea": ​​això ens permet escriure mètodes polimòrfics, mètodes que poden canviar d'execució de l'algorisme Depenent del tipus d'objecte que s'usa per al'argument.

Polimorfisme en els llenguatges OOP tradicionals

En Java - però el mateix és cert per a C + + i qualsevol altre llenguatge orientat a objectes (OO) ha acabat, llavors anem a veure en lloc de el cas de Ruby - exemple:

 interfície IFormaGeometrica







 {



   



 buit getArea ();







 }









 Triangle public class IFormaGeometrica







 {



 



 @ Override



 



 pública getArea int ()



 



 {



  



 return (* this.base this.altezza) / 2;



 



 }







 }

En aquest cas es defineix el IFormaGeometrica interfície que estableix que tots els objectes que "és" un getArea FormaGeometrica tindrà un mètode - per exemple, el Triangle de la classe, que és un FormaGeometrica, té la seva pròpia implementació de getArea, el que ens permet escriure un programa capaç de calcular les àrees de qualsevol forma geomètrica, si aquest és present avui en el codi i que es durà a terme en el futur, sense canviar el codi font original.

De fet, si jo escric una calculadora de classe:

 Calculadora public final class







 {





 



 public static void main (String [] args)



 



 {



  



 Formularis de recollida de <IFormaGeometrica> =



          



 <IFormaGeometrica> New ArrayList ();





  



 forme.add (nou triangle ());



  



 forme.add (nova Plaça ());



  



 forme.add (nou Pentàgon ());





  



 de (g IFormaGeometrica: les formes)



  



 {



   



 System.out.println (g.calcolaArea ());



  



 }



 



 }







 }

Això pot prendre com a entrada qualsevol col · lecció de formes geomètriques, a condició que tots els objectes del IFormaGeometrica col · lecció implementa la interfície, i que té essencialment un mètode getArea. Aquest exemple Java és purament acadèmic: de fet, probablement en el constructor de cada classe, que inclouen mesures d'entrada dels costats de la forma geomètrica, l'apotema, i així successivament.

L'objectiu s'aconsegueix: escrivim una classe que pot imprimir la pantalla de l'àrea de qualsevol figura geomètrica. Repeteixo: aquest és el codi que ja s'ha implementat (com en el cas del triangle), si es porta a terme en el futur.

No només això, si l'aplicació del càlcul de l'àrea del triangle contenia un error, que pot canviar la classe de triangle sense haver de reescriure la Calculadora de classe. Potser va ser desplegat en un servidor que ha de reiniciar cap canvi: en aquest cas no ha de canviar el codi és un gran avantatge. Però a part d'això, sempre és convenient limitar les parts de codi que "el canvi", perquè cada canvi comporta possibles errors. Per contra, és bona pràctica de programació per saber sempre amb certesa el que parts del codi que es manté sense canvis.

El que passa "entre bastidors" és que el compilador s'assegura que tots els objectes a l'interior del codi polimòrfic el mètode principal de la calculadora de classe implementa la interfície. D'aquesta manera, es diu que és una expressió que utilitza la metodologia de disseny per contracte ", el contracte es respecta."

Si no, si és que en les "formes" tenir un objecte d'una classe que no es portaria a terme IFormaGeometrica un error en temps de compilació, o no aconsegueix executar el programa, ja que el compilador es donaria compte de l'error.

El polimorfisme en Ruby

Però el que passa en Ruby? I 'possible en Ruby, que no es compila, però el llenguatge interpretat, per escrit els mètodes polimòrfics?

Sí, és certament possible, però hi ha una profunda diferència "filosòfica" de llenguatges orientats a objectes i compilat, el que

Podríem descriure-la. En la programació OO en Java i clàssic, per determinar que un objecte pertany a un tipus particular d'objectes (és a dir, implementi una interfície determinada) han de explícitament es deriven de l'objecte d'una classe pare: bàsicament, cal utilitzar les tècniques de l'herència (l'herència per una classe, una classe abstracta o interfície).

Seria com dir: Per determinar si es tracta d'un ànec davant meu, em prenc l'ADN i l'estudi en el laboratori per veure si és ànec.

En Ruby s'utilitza la "prova d'ànec" (prova d'ànec) inventat per James Riley (veure http://en.wikipedia.org/wiki/Duck_typing ):

si camina com un ànec i claca com un ànec, llavors és un ànec.

(Que per cert és el que fa cada un de nosaltres quan veu un ànec).

Què significa això? Això significa que en Ruby, i més generalment en llenguatges de programació orientats a objectes, així com de Python i Perl, no cal especificar la interfície, ni relacions explícites herència entre classes.

Simplement l'intèrpret de "confia" que el programador si el mètode dels passos d'un objecte polimòrfic que "ha de tenir" una certa manera, que en realitat tenen l'extensió.

• <<
• 1
• 2
• >>