Vil du vite hva polymorfisme er? I den følgende artikkelen vil vi gi deg detaljert informasjon om hva som kalles Polymorfisme i objektorientert programmering.
Polymorfisme i objektorientert programmering
Selv om det kan virke som et ord med en litt kompleks beskrivelse, er denne typen datarelatert tema virkelig relatert til helt grunnleggende aspekter ved det. Når du lærer Objektorientert programmering, kan vi komme over denne beskrivelsen, hvis mening ganske enkelt er beskrivelsen av flere og mulige tilstander for en enkelt eiendom.
For databehandling er det en av de grunnleggende egenskapene for objektorientert programmering, og det er også en teknikk som brukes for datavirus eller ormer for å endre deler av koden, noe som gjør det vanskelig å oppdage dem. Dette kan å legge til rette Mange ting når vi programmerer noe når vi ikke ønsker å være så spesifikke og vi trenger noe mer funksjonelt som tilpasser seg en bredere arbeidsmåte, som reduserer arbeidet og hjelper oss til å kunne håndtere noe mer dynamisk og fleksibelt.
Før vi hopper rett til poenget, skal vi forklare noen begreper og bryte ned definisjoner som vil tjene som åpne munnen, ikke bare for å forstå det bedre, men for å forstå hvordan det fungerer, dets betydning og hvor nyttig det kan være innen databehandling, og hjelpe oss med å slappe av i arbeidet. Vi finner kanskje ikke noe nytt før vi hopper direkte til polymorfisme i OOP, men det er viktig å huske på alt følgende for å forstå det riktig.
Konseptet polymorfisme i objektorientert programmering har sin opprinnelse i Simula 67, som er et programmeringsspråk, laget for å utføre simuleringer. Dette ble laget av Ole Joha Dahl og Kristen Nygaard som tilhørte det norske datasenteret i Oslo.
Dette senteret var dedikert til simulering av skip, det var mye forvirring på grunn av eksplosjonen på grunn av forskjellene mellom det ene og det andre, da disse skipene ble gruppert etter sin respektive klassifisering for å generere mer kontroll på tidspunktet for studiene , det var da denne ideen ble til virkelighet.
Denne programmeringsstilen på 80 -tallet dominerte på nesten alle områder av databehandling på grunn av den store attribusjonen med C ++ som er et annet programmeringsspråk C. Takket være de grafiske brukergrensesnittene fungerte dominansen i denne metoden veldig bra.
Polymorfisme i objektorientert programmering har flere egenskaper, som ble brukt på forskjellige språk som ble brukt på den tiden, for eksempel: Ada, BASIC, LISP, Pascal, blant mange andre, selv om de utviklet forskjellige kompatibilitetsproblemer.
For en mer detaljert forklaring om hva polymorfisme er i objektorientert programmering, inviterer vi deg til å se følgende video:
Polymorfisme og arv
Prefikset poly har sin opprinnelse på gresk, så den eksakte beskrivelsen betyr overflod, mange eller forskjellige, og morfisme er et gresk suffiks som går inn i orddannelsen med betydningen av form, sammensetning eller struktur i et legeme. Når vi tar dette i betraktning, kan vi gå inn på det vi ønsker å forklare i dette fragmentet, vårt hovedord er i utgangspunktet per definisjon en variasjon dannet av strukturen i et legeme; I forskjellige matematikkfelt kalles kart applikasjonene mellom matematiske strukturer som bevarer den interne strukturen.
For å gjøre dette helt klart kan vi sammenligne polymorfisme og arv. Med andre ord tillater dette oss å utføre polymorfismene i klassifiseringshierarkier. Det er også viktig å nevne at disse er gitt gjennom arv, så lenge arven, som vi kunne forstå som derivater av et objekt, alltid tilhører samme klasse; For å gi et eksempel på det som er blitt forklart, kan vi si at fra ordet kjøretøy dukker det opp flere klasser, for eksempel en bil, en motorsykkel og en buss, og polymorfisme og arv er to unektelig knyttet begreper.
Betydningen av typesystemet i polymorfisme
Å nevne denne klassifiseringen som et typesystem, fordi derivatene av det ordet fremdeles er en del av dem, men hvorfor er dette viktig i objektorientert programmeringspolymorfisme?
Mange av menneskene som skrev inn denne artikkelen kan være kjent med hva det er å programmere på svakt typede språk, slik det ville være for Javascript og PHP, men det er viktig at vi forstår godt hvordan det er.
I denne typen språk, når vi definerer en variabel, må vi alltid angi hvilken type vi vil at variabelen skal inneholde, for eksempel: int myNumber.
På denne måten har vi muligheten til å indikere at variabelen som er etablert som "myNumber" alltid vil inneholde et helt tall; hvis ikke, ville kompilatoren sende oss en feilmelding og forhindre oss i å kompilere programmet vi har laget.
Faktisk kan dette også skje med objekter, hvis vi i Java definerer klassen "spillefilm", og kjenner dette ordet som en film som varer mer enn en time, når vi lager objekter i klassen "spillefilm" må vi angi variablene der objekttypen som er ment å bli laget er angitt. Vi kan uttrykke det slik:
Spillefilm miLargo = ny spillefilm
Variabelen vår ville være "myLong" og hvis vi avslører dette, vil vi ha en referanse til et objekt i klassen eller typene "Feature Film", og så lenge den varer, bør den alltid ha et objekt av samme klasse eller type, som sa det er viktig å vite slik at du ikke kan lagre et helt tall i variabelen, eller et annet objekt av en annen type eller klasse, som ikke er arv og som ikke har noe forhold.
Hvis vi kommer tilbake for å nevne eksemplet på kjøretøyer og deres typer, er det viktig å presisere at hvis vi bestemmer oss for å definere en variabel som peker på objektet i klassen «moto», mens denne variabelen varer, må den alltid peke på en relatert eller arveobjekt til klassen «moto», ikke klassen «bil», og heller ikke «buss»; På svakt slitte språk som de vi nevnte tidligere, eksisterer imidlertid denne ufleksibiliteten ikke, selv om den er et vanlig trekk ved tungt slitte språk som Java. Her er et bredere eksempel:
- Bil myCar = ny bil (Mazda 2 ″): Mazda 2 ville være vår arv av objektet som tilhører den klassen eller typen, og det er variabelen som peker til, og hvis vi ønsket det, kan det i morgen peke på et annet objekt av Bilen min.
MyCar = ny bil (Ford Focus 2.0 ″)
Det vi aldri kan gjøre er å lagre i vårt variable sett som bilklasse, noe annet som ikke har noe å gjøre med biltypen, for da ville vi ha en kompileringstidsfeil, i tilfelle det skjer, må det ha reddet New Ford Ford Focus 2.0 ville vi valgt New Moto Yamaha YBR.
Det bør presiseres at vi på dette tidspunktet ikke snakker om polymorfisme som sådan ennå, men vi tester programmering generelt med typesystemet; poenget er at vi må åpne tankene våre for de komplikasjonene som begrensningen av sterkt trippelte språk kan gi oss for senere å forstå hvorfor polymorfisme er viktig og et sentralt stykke i polymorfisme i objektorientert programmering.
I et fullt maskinskrevet dataspråk når en funksjon manifesteres, må vi alltid ha et viktig poeng når vi informerer hvilken type regler den skal motta. Vi vil ikke være i stand til å overføre noe annet enn variabler eller bokstaver med heltallsverdier til funksjonen vi har etablert. Hvis det oppstår oss å passere andre data med andre typer, vil kompilatoren endre seg, det vil ikke tillate oss for å kompilere programmet fordi det i så fall ikke kunne finne de forventede typene i funksjonsparametrene.
Polymorfisme i objekter
Endelig har vi nådd den delen som virkelig spesifiserer dette temaet av interesse, det er derfor under dette systemet vil det bli laget sine egne elementer som viser sine klasser og mål, ettersom sterkt typede språk fungerer, må en variabel alltid peke på et objekt av den typen vi angav da vi etablerte den.
Det er noe avgjørende å huske, en funksjon hvis parameter har blitt erklært for en klasse, vil bare akseptere oss for å motta objekter av den klassen; en matrise som har blitt erklært å bestå av elementer av en bestemt type, lar oss bare fylle boksene med objekter av den typen vi etablerte; vi vil presentere et annet eksempel:
Kjøretøy [] myVehiculos = nytt kjøretøy [3]
Dette eksemplet vi gir, det er en variabel som er en matrise, og i den erklærer vi at innholdet i boksene vil være objekter i kjøretøyklassen, på et sterkt trippel språk kan den bare inneholde objekter i kjøretøyklassen, slik vi hadde allerede forklart, men nå finner vi polymorfisme, som vi kan gi litt mer fleksibilitet til typesystemet, noe som gir oss muligheten for en variabel til også å akseptere objekter i klassen "barn" eller derivater.
Ved å gjøre typesystemet mer fleksibelt snakker vi ikke om det som helhet, men med hva det ville ha å gjøre med arvsklassifiseringene vi har i klassen eller typesystemene våre. Hvis vi klarer å definere en matrise ved hjelp av celler fra en etablert klasse, ville kompilatoren godta oss å sette inn ord "barn" til objektet som vi allerede hadde etablert i disse boksene. Hvis vi fastslår at en funksjon mottar objekter av en eller annen klasse som parametere , vil kompilatoren tillate oss å la oss sende den påkallelse av objekter av en klasse som stammer fra den vi allerede har erklært.
Når vi tar det til noe mer konkret, vil vårt kjøretøyserie ikke bare tillate oss å sette inn generiske kjøretøyer i variabelen, men også alle objektene til barnet eller avledede klasser i denne klassen, da ville vi ha gjenstander fra buss, bil og motorsykkel klasse eller et hvilket som helst barn. som vi har definert, og alt dette takket være polymorfisme.
Påføring av polymorfisme
Til tross for forklaringen som vi hadde gitt til spillefilmen, ønsker vi å presisere at vi i tillegg til å være en film også kan ha dokumentarer, og blant andre; kanskje begge har forskjellige egenskaper, forskjellige publikumstider, forskjellige priser, og av denne grunn kunne vi ha bestemt at vår spillefilmklasse har datterklasser eller arv som "film" eller "dokumentar".
Hvis vi lager en klasse etablert som kino og en metode som vi vil kalle "reprodusere", vil den tjene som et parameter for det vi ønsker å gjengi i en kino, dit det kan komme objekter fra både kinoklassen og dokumentarklassen, hvis vi forstår godt typesystemet (uten engang å gå inn i polymorfisme) vil metodene våre etablere typer parametere vi mottar. Det ville se slik ut:
-
Play (Movie Movie To Play)
Men i stedet hvis vi ønsker å gjengi en dokumentar, må vi endre formelen vår.
-
Play (Documentary Documentary To Play)
Og er det virkelig nødvendig å lage to forskjellige formler? Begge metodene for å gjengi de to tingene ville være nøyaktig det samme, hvorfor bry deg? Vi måtte bare sette spillefilmen i spilleren, slå på play (eller play) og lage en rekord med antall billetter som klarte å bli solgt. Selv om det ikke er en plage å gjøre begge metodene, må vi være klar over at vi kan bli presentert for situasjonen der vi må lage en annen formel, vi kan gi eksemplet på at vi har en film, men denne gangen i 3D -format.
På dette tidspunktet kan vi ty til polymorfisme, med dens hjelp kan vi lage en reproduserende metode som vil gjenkjenne alle slags elementer, dokumentarer, filmer eller noe annet av samme klasse (som er relatert), som vi må lage i framtid. Det språkene vil tillate oss er å etablere gjengivelsesmetoden, noe som indikerer at parameteren i klassen vi skal motta er et objekt med lengde, men språket og kompilatoren ville godta ethvert objekt avledet fra film eller dokumentar, vil vi sitte igjen med noe slikt: play (Feature film itemToPlay).
Enten vi ønsker å lage filmer eller dokumentarer for å reprodusere dem, vil alt dette være mulig med en enkelt metode, det å reprodusere, takket være det faktum at vi på grunn av polymorfismen i objektorientert programmering gjør systemet mer fleksibelt være nødvendig. For eksempel, hvis du vil gjengi en film og ikke en dokumentar, trenger vi ikke velge Cinema -klassen, men det er nok at det vi ønsker å gjengi er en del av arven til spillefilmobjektet.
Hvis vi går tilbake til eksempelet på kjøretøyet, selv om vi husker på nytten av polymorfisme og mulighetene det gir oss for å redusere all vedlikehold av dataprogrammer som vi måtte gjøre hvis vi ikke hadde hjelp av dette konseptet.
La oss si at vi har parkeringsklassen (på spansk vil det være klassen å lære å parkere) som vi har funksjonen som parkering. På en parkeringsplass har vi muligheten til å parkere busser og motorsykler, i tillegg til bare biler, og uten polymorfisme måtte vi lage en metode som lar oss parkere objekter av typen "bil" og en annen som lar oss parkere gjenstander av typen "buss" og en annen som lar oss parkere objekter av "motorsykkel", selv om prosedyren for å utføre disse handlingene til tross for den bemerkelsesverdige forskjellen mellom utseendet til disse tre kjøretøyene i utgangspunktet er den samme, bare at en tar mer plass enn den andre.
Det mest presise ville være å ha en enkelt metode som forenkler ting for oss og lar oss motta alle typer kjøretøyer, ikke bare biler og bilmerker, men alle aksepterte og dyrebare derivater av bilobjektet. Først ville vi ha gjenbruk av koden, for som vi allerede hadde sagt, er parkering av denne typen kjøretøy lik, med den eneste forskjellen i plassen som hver enkelt opptar, men i tillegg til dette, hvis i morgen en annen type kjøretøy var for å selge på markedet, ville vi ha muligheten for at programvaren vår kan godta den uten å måtte endre vår allerede etablerte parkeringsklasse.
Vi disponerer en enkelt metode for å akseptere alle de presise arvene som et kjøretøy kan ha, noe som gjør arbeidet mer fleksibelt og sparer oss for tiden vi ville brukt på å lage en for hver kjøretøytype. Polymorfisme i objektorientert programmering åpner dørene for en rekke objekter som kan aksepteres med en enkelt metode.
Vi prøver å forklare polymorfismen på den mest forståelige måten og foreta en bred gjennomgang av alt som ligger bak, det hadde ikke vært hensiktsmessig å hoppe til konseptet som sådan uten å gi dets bakgrunn for å hjelpe oss å forstå det og forstå dets enestående betydning og viktigheten. bruk som vi kan gi den.
Å ha muligheten til å kunne inkludere flere metoder i en, mens avledningene er enige om arv av objektet, er ganske nyttig fordi det sparer oss for behovet for å lage flere som tvinger oss til å være veldig spesifikke uten å gi oss muligheten til å gjøre mer fleksibelt arbeid i Det faktum at vi kan skape en mer dynamisk måte å håndtere det vi har programmert, så enkelt som å kjenne den riktige avledningen av et enkelt ord, det vil si alt det omfatter, hjelper oss til å gjøre en mer effektiv jobb.
Vi håper du vil like denne artikkelen og lære hva polymorfisme er i objektorientert programmering. Hvis du vil lese en annen av våre artikler om programmering, anbefaler vi at du besøker følgende som gir oss en veldig kjent form for programmering i dataverdenen: C ++ programmering.