Polymorfi og Duck Typing i Ruby

Den polymorfisme er et programmeringsspråk teknikk som tillater bruk av deler av kildekoden som, mens resterende uendret, generere kjøre-time atferd.

Lag polymorfe kode har en bestemt mening i objektorientert programmering: betyr å skape en taksonomi av klasser som alle implementerer det samme grensesnittet.

Så hvis for eksempel definerer mitt interface en metode "getArea", hver klasse som skal implementere dette grensesnittet vil ha en metode "getArea": ​​Dette tillater oss å skrive polymorfe metoder, metoder som kan endre sin algoritme gjennomføring Avhengig av type objekt som er vedtatt som et argument.

Polymorfisme i tradisjonelle OOP språk

I Java - men det samme gjelder for C + + og andre språk Objektorientert (OO) ferdig, så får vi se stedet tilfelle av Ruby - eksempel:

 grensesnitt IFormaGeometrica







 {



   



 getArea void ();







 }









 public class Triangle implementerer IFormaGeometrica







 {



 



 @ Override



 



 public int getArea ()



 



 {



  



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



 



 }







 }

I dette tilfellet definerer vi grensesnittet IFormaGeometrica som sier at hver gjenstand som "er" en FormaGeometrica getArea vil ha en metode - for eksempel har klassen Triangle, som er en FormaGeometrica, sin egen gjennomføring av getArea, som tillater oss å skrive et program stand til å beregne de områdene av enhver geometrisk form, enten det er til stede i dag i koden og som vil bli implementert i fremtiden, uten å endre den originale kildekoden.

Faktisk, hvis jeg skriver en klasse Kalkulator:

 public endelig class Kalkulator







 {





 



 public static void main (String [] args)



 



 {



  



 Innsamling former <IFormaGeometrica> =



          



 <IFormaGeometrica> Nye ArrayList ();





  



 forme.add (nye Triangle ());



  



 forme.add (nye Square ());



  



 forme.add (nye Pentagon ());





  



 for (g IFormaGeometrica: former)



  



 {



   



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



  



 }



 



 }







 }

Dette kan ta som input noen samling av geometriske former, forutsatt at hvert objekt i samlingen IFormaGeometrica implementerer grensesnittet, og som har i hovedsak en metode getArea. Dette eksempelet Java er rent akademisk: faktisk, sannsynligvis i konstruktør av hver klasse, inkluderer vi inn mål på sidene av den geometriske formen, apothem, og så videre.

Målet er nådd: Vi skrev en klasse som kan print screen området for noen geometriske former. Jeg gjentar: dette er koden som allerede er implementert (som i tilfelle av Triangle), enten det er implementert i fremtiden.

Ikke bare at hvis gjennomføringen av Triangle området beregningen inneholdt en bug, kan jeg endre Triangle klassen uten å omskrive klassen Kalkulator. Kanskje det var utplassert på en server som trenger å starte noen endring: i dette tilfellet trenger ikke å endre koden er en stor fordel. Men annet enn det, er det alltid en fordel å begrense deler av koden som "endring" fordi hver endring bringer med seg potensielle bugs. Motsatt er det god programmering praksis å alltid vet med sikkerhet hvilke deler av koden som forblir uendret.

Hva skjer "bak kulissene" er at kompilatoren gjør at hvert objekt i det polymorfe kode den viktigste metoden for klasse Kalkulator implementerer grensesnittet. På denne måten er det sagt er et uttrykk bruk av metodikken for design av kontrakt, "kontrakten blir respektert."

Hvis ikke, hvis det er i "former" har et objekt av en klasse som vi ikke ville implementere IFormaGeometrica en feil ved kompilering, eller ikke klarer å kjøre programmet, fordi kompilatoren vil merke feilen.

Den polymorfisme i Ruby

Men hva skjer i Ruby? Og "mulig i Ruby, som ikke er kompilert, men tolket språk, skriving polymorfe metoder?

Ja, det er absolutt mulig, men det er en enorm forskjell "filosofisk" enn OO språk og kompileres, som

vi kunne beskrive det. I OO programmering i Java og klassiske, for å fastslå at et objekt tilhører en bestemt type objekter (dvs. implementerer et bestemt interface) må eksplisitt utlede objektet fra en forelder klasse: i utgangspunktet at du må bruke teknikker for arv (arve av en klasse, en abstrakt klasse eller interface).

Det ville være som å si: For å avgjøre om dette er en and foran meg, tar jeg hans DNA og studere i laboratoriet for å se om det er å anda.

I Ruby er du bruker "duck test" (duck test) ble oppfunnet av James Riley (se http://en.wikipedia.org/wiki/Duck_typing ):

hvis det går som en and og kvakksalvernes som en and, så er det en and.

(Som for øvrig er det som gjør hver av oss når han ser en and).

Hva betyr dette? Det betyr at i Ruby, og mer generelt i objekt-orientert skriptspråk, samt Python og Perl, trenger ikke å angi grensesnittet, og heller ikke eksplisitte arv relasjoner mellom klassene.

Bare tolken "stoler" som programmerer hvis metoden trinn a polymorfe objekt som "bør ha" en viss måte, vi faktisk har.

• <<
• 1
• 2
• >>