Vil du vide, hvad polymorfisme er? I den følgende artikel giver vi dig detaljerede oplysninger om, hvad der kaldes Polymorfisme i objektorienteret programmering.
Polymorfisme i objektorienteret programmering
Selvom det kan virke som et ord med en lidt kompleks beskrivelse, er denne type computerrelaterede emner virkelig relateret til helt grundlæggende aspekter af det. Når du lærer Objektorienteret programmering, kan vi støde på denne beskrivelse, hvis betydning ganske enkelt er beskrivelsen af flere og mulige tilstande for en enkelt ejendom.
Til computing er det en af de grundlæggende egenskaber for objektorienteret programmering, og det er også en teknik, der bruges til computervirus eller orme til at ændre dele af deres kode, hvilket gør deres registrering vanskelig. Dette kan at facilitere Mange ting, når vi programmerer noget, når vi ikke vil være så specifikke, og vi har brug for noget mere funktionelt, der tilpasser sig en bredere måde at arbejde på, der reducerer arbejdet og hjælper os med at kunne håndtere noget mere dynamisk og fleksibelt.
Inden vi springer direkte til punktet, vil vi forklare nogle begreber og nedbryde definitioner, der vil tjene som åben mund, ikke kun for at forstå det bedre, men for at forstå dets funktion, dets betydning og hvor nyttigt det kan være inden for computing, hvilket hjælper os med at slappe af i vores arbejde. Vi finder måske ikke noget nyt, før vi springer direkte til polymorfisme i OOP, men det er vigtigt at huske alt det følgende for at forstå korrekt.
Begrebet polymorfisme i objektorienteret programmering har sit udspring i Simula 67, som er et programmeringssprog, der er lavet til at udføre simuleringer. Dette blev skabt af Ole Joha Dahl og Kristen Nygaard, der tilhørte det norske datacenter i Oslo.
Dette center var dedikeret til simulering af skibe, der var meget forvirring på grund af eksplosionen på grund af forskellene mellem dem, da disse skibe blev grupperet efter deres respektive klassificering for at generere mere kontrol på tidspunktet for undersøgelserne, var det så at denne idé blev til virkelighed.
Denne programmeringsstil i 80'erne dominerede inden for næsten alle computingområder på grund af dens store tilskrivning med C ++, som er et andet programmeringssprog C. Takket være de grafiske brugergrænseflader fungerede dominans af denne metode meget godt.
Polymorfisme i objektorienteret programmering har flere egenskaber, der blev anvendt på forskellige sprog, der blev brugt på det tidspunkt, såsom: Ada, BASIC, LISP, Pascal, blandt mange andre, selvom de udviklede forskellige kompatibilitetsproblemer.
For en mere detaljeret forklaring på, hvad polymorfisme er i objektorienteret programmering, inviterer vi dig til at se følgende video:
Polymorfisme og arv
Præfikset poly har sin oprindelse på græsk, så den nøjagtige beskrivelse betyder overflod, mange eller forskellige, og morfisme er et græsk suffiks, der kommer ind i dannelsen af ord med betydningen af form, sammensætning eller struktur af et legeme. Når vi tager dette i betragtning, kan vi gå ind på, hvad vi vil forklare i dette fragment, vores hovedord er grundlæggende pr. Definition en sort dannet af en krops struktur; Inden for forskellige matematikområder kaldes kort applikationer mellem matematiske strukturer, der bevarer den interne struktur.
For at gøre dette helt klart kan vi sammenligne polymorfisme og arv. Med andre ord giver dette os mulighed for at udføre polymorfierne i klassifikationshierarkier. Det er også vigtigt at nævne, at disse er givet gennem arv, så længe arven, som vi kunne forstå som afledte af et objekt, altid tilhører samme klasse; For at give et eksempel på det, der er blevet forklaret, kan vi sige, at der fra ordet køretøj dukker flere klasser op, såsom en bil, en motorcykel og en bus, og polymorfisme og arv er to unægteligt forbundne begreber.
Typesystemets betydning for polymorfisme
Navngiver denne klassificering som et typesystem, fordi derivaterne af dette ord stadig er en del af dem, men hvorfor er dette vigtigt i objektorienteret programmeringspolymorfisme?
Mange af de mennesker, der kom ind i denne artikel, kender muligvis til, hvad det er at programmere på svagt indtastede sprog, som det ville være i tilfælde af Javascript og PHP, men det er vigtigt, at vi godt forstår, hvordan det er.
I denne type sprog, når vi definerer en variabel, skal vi altid angive den type, som vi vil have, at variablen skal indeholde, for eksempel: int myNumber.
På denne måde har vi mulighed for at angive, at variablen etableret som "myNumber" altid vil indeholde et helt tal; hvis sagen ellers var, ville kompilatoren sende os en fejlmeddelelse, der forhindrede os i at kompilere det program, vi har lavet.
Faktisk kan dette også ske med objekter, hvis vi i Java definerer klassen "spillefilm", idet vi kender dette ord som en film, der varer mere end en time, når vi opretter objekter i klassen "spillefilm", skal vi angive de variabler, hvori den type objekt, der skal laves, er angivet. Vi kan udtrykke det på denne måde:
Spillefilm miLargo = ny spillefilm
Vores variabel ville være "myLong", og hvis vi udsætter dette, vil vi have en reference til et objekt i klassen eller typerne af "Feature Film", og så længe det varer, skal det altid have et objekt af samme klasse eller type, når det er sagt dette er vigtigt at vide, så du ikke kan gemme et helt tal i variablen eller et andet objekt af en anden type eller klasse, der ikke er arv, og som ikke har noget forhold.
Hvis vi vender tilbage for at nævne eksemplet på køretøjer og deres typer, er det vigtigt at præcisere, at hvis vi beslutter at definere en variabel, der peger på objektet i klasse «moto», mens denne variabel varer, skal den altid pege på en relateret eller arv objekt til klassen «moto», ikke klassen «bil» eller «bus»; i svagt rensede sprog som dem, vi nævnte tidligere, eksisterer denne ufleksibilitet imidlertid ikke, selv om det er et fælles træk ved stærkt rensede sprog som Java. Her er et bredere eksempel:
- Bil myCar = ny bil (Mazda 2 ″): Mazda 2 ville være vores arv efter objektet, der tilhører den klasse eller type, og det er den, variablen peger på, og hvis vi ville, kunne den i morgen pege på et andet objekt af Min bil.
MyCar = ny bil (Ford Focus 2.0 ″)
Det, vi aldrig kan gøre, er at gemme i vores variable sæt fra bilklassen, noget andet, der ikke har nogen relation til biltypen, for så ville vi have en kompileringstidsfejl, hvis det sker, skal det have gemt New Car Ford Focus 2.0 ville vi have valgt New Moto Yamaha YBR.
Det bør præciseres, at vi på nuværende tidspunkt ikke taler om polymorfisme som sådan endnu, men vi tester programmering generelt med typesystemet; pointen er, at vi skal åbne vores sind for de komplikationer, som begrænsningen af stærkt trippede sprog kan give os for senere at forstå, hvorfor polymorfisme er vigtig og et centralt stykke i polymorfisme i objektorienteret programmering.
I et fuldt indtastet computersprog, når en funktion manifesterer sig, skal vi altid beholde det som et vigtigt punkt, når vi informerer den type regler, den kommer til at modtage. Vi vil ikke være i stand til at videregive andet end variabler eller bogstaver med heltalsværdier til den funktion, vi har oprettet, hvis vi tilfældigvis videregiver andre data med andre typer, vil kompilatoren ændre det, det vil ikke tillade os at kompilere programmet, fordi det i så fald ikke kunne finde de forventede typer i funktionsparametrene.
Polymorfisme i objekter
Endelig har vi nået den del, der virkelig specificerer dette emne af interesse, derfor vil der under dette system blive lavet sine egne elementer, der viser sine klasser og mål, da stærkt indtastede sprog virker, skal en variabel altid pege på et objekt af den slags, som vi angav på det tidspunkt, vi etablerede det.
Det er noget vigtigt at huske, nu vil en funktion, hvis parameter er blevet erklæret for en klasse, kun acceptere os til at modtage objekter af denne klasse; En matrix, der er erklæret for at bestå af elementer af en bestemt type, tillader os kun at udfylde dens bokse med objekter af den type, som vi har oprettet; vi vil præsentere et andet eksempel:
Køretøj [] myVehiculos = nyt køretøj [3]
Dette eksempel giver vi, det er en variabel, der er en matrix, og i den erklærer vi, at kassenes indhold vil være objekter i køretøjsklassen, i stærkt tredobbelt sprog kan den kun indeholde objekter af køretøjsklassen, som vi havde allerede forklaret, men nu finder vi polymorfisme, hvormed vi kan give lidt mere fleksibilitet til typesystemet, hvilket giver os mulighed for en variabel til også at acceptere objekter af klassen "børn" eller derivater.
Ved at gøre typesystemet mere fleksibelt taler vi ikke om som helhed, men med hvad det ville have at gøre med de arvsklassifikationer, vi har i vores klasse- eller typesystemer. Hvis vi formår at definere en matrix ved hjælp af bokse af en etableret klasse, ville kompilatoren acceptere, at vi indsatte ord "børn" af det objekt, som vi allerede havde oprettet i disse felter. Hvis vi konstaterer, at en funktion modtager objekter af en bestemt klasse som parametre , vil kompilatoren tillade os at lade os sende påkaldelsen af objekter af en klasse, der stammer fra den, vi allerede havde erklæret.
Når vi tager det til noget mere konkret, vil vores køretøjsserie ikke kun give os mulighed for at indsætte generiske køretøjer i dens variabel, men også alle objekterne for barnet eller afledte klasser i denne klasse, så ville vi have objekter fra bussen, bilen og motorcyklen klasse eller ethvert barn. som vi har defineret, og alt dette takket være polymorfisme.
Anvendelse af polymorfisme
På trods af den forklaring, som vi havde givet til spillefilmen, vil vi præcisere, at vi udover at være en film også kan have dokumentarfilm, og blandt andre; måske begge har forskellige karakteristika, forskellige publikumstider, forskellige priser, og derfor kunne vi have besluttet, at vores spillefilmklasse har datterklasser eller arv såsom "film" eller "dokumentar".
Hvis vi opretter en klasse etableret som biograf og en metode, som vi vil kalde "gengiv", vil den fungere som et parameter for, hvad vi vil gengive i en biograf, hvor genstande fra både biografklassen og dokumentarklassen kan ankomme, hvis vi godt forstår typesystemet (uden selv at gå ind i polymorfisme), vil vores metoder etablere typerne af de parametre, vi modtager. Det ville se sådan ud:
-
Play (Movie Movie To Play)
Men hvis vi i stedet vil gengive en dokumentarfilm, bliver vi nødt til at ændre vores formel.
-
Play (Documentary Documentary To Play)
Og er det virkelig nødvendigt at oprette to forskellige formler? Begge metoder til at gengive de to ting ville være nøjagtig det samme, hvorfor gider du? Vi skulle kun lægge spillefilmen i afspilleren, trykke på play (eller spille) og oprette en rekord med det antal billetter, der lykkedes at sælge. Selvom det ikke er noget besvær at gøre begge metoder, skal vi være opmærksom på, at vi kan blive præsenteret for den situation, hvor vi skal oprette en anden formel, vi kunne give eksemplet på, at vi har en film, men denne gang i 3D -format.
På dette tidspunkt kan vi ty til polymorfisme, med dens hjælp kan vi oprette en gengivelsesmetode, der genkender alle former for elementer, dokumentarer, film eller andet i samme klasse (som er relateret), som vi skal oprette i fremtid. Hvad sprogene ville tillade os, er at etablere gengivelsesmetoden, der angiver, at parameteren i klassen, som vi skal modtage, er et objekt med længde, men sproget og kompilatoren accepterer ethvert objekt, der stammer fra film eller dokumentarfilm, ville vi stå tilbage med noget i stil med dette: play (spillefilm element ToPlay).
Uanset om vi vil oprette film eller dokumentarfilm for at gengive dem, vil alt dette være muligt med en enkelt metode, reproducering, takket være det faktum, at vi på grund af polymorfismen i objektorienteret programmering gør systemet mere fleksibelt være nødvendige. For eksempel, hvis du vil gengive en film og ikke en dokumentarfilm, skal vi ikke vælge Cinema -klassen, men det er nok, at det, vi ønsker at gengive, er en del af arven fra spillefilmobjektet.
Hvis vi vender tilbage til køretøjets eksempel, selv om vi husker på nytten af polymorfisme og de muligheder, det giver os til at reducere al vedligeholdelse af computerprogrammer, som vi skulle gøre, hvis vi ikke havde hjælp fra dette koncept.
Lad os sige, at vi har parkeringsklassen (på spansk ville det være klassen at lære at parkere), inden for hvilken vi har funktionen parkering. På en parkeringsplads har vi mulighed for at parkere busser og motorcykler, udover kun biler, og uden polymorfisme skulle vi oprette en metode, der giver os mulighed for at parkere objekter af typen "bil" og en anden, der giver os mulighed for at parkere genstande af typen "bus" og en anden, der tillader os at parkere "motorcykel" -genstande, selvom proceduren for at udføre disse handlinger på trods af den bemærkelsesværdige forskel mellem disse tre køretøjers udseende stort set er den samme, kun at man optager mere plads end den anden.
Det mest præcise ville være at have en enkelt metode, der forenkler tingene og giver os mulighed for at modtage alle typer køretøjer, ikke kun biler og bilmærker, men alle accepterede og værdifulde derivater af bilens genstand. Først ville vi have genbrug af koden, for som vi allerede havde sagt, er parkering af disse typer køretøjer ens med den eneste forskel i den plads, hver enkelt optager, men ud over dette, hvis der i morgen var en anden køretøjstype for at sælge på markedet, ville vi have mulighed for, at vores software er i stand til at acceptere det uden behov for at ændre vores allerede etablerede parkeringsklasse.
Vi råder over en enkelt metode til at acceptere alle de præcise arv, et køretøj måtte have, hvilket gør arbejdet mere fleksibelt og sparer os den tid, vi ville have brugt på at oprette en for hver køretøjstype. Polymorfisme i objektorienteret programmering åbner dørene for en række objekter, der kan accepteres af en enkelt metode.
Vi forsøger at forklare polymorfismen på den mest forståelige måde og foretage en bred gennemgang af alt bagved, det ville ikke have været passende at straks springe til konceptet som sådan uden at give dets baggrund for at hjælpe os med at forstå det og forstå dets enestående betydning og betydning. brug, som vi kan give det.
At have muligheden for at kunne inkludere flere metoder i én, mens afledningerne er enige om arv efter objektet, er ganske nyttig, fordi det sparer os for behovet for at oprette flere, der tvinger os til at være meget specifikke uden at give os mulighed for at gøre mere fleksibelt arbejde i Det faktum, at vi kan skabe en mere dynamisk måde at håndtere det, vi har programmeret, så simpelt som at kende den korrekte afledning af et enkelt ord, det vil sige alt, hvad det omfatter, hjælper os med at udføre et mere effektivt stykke arbejde.
Vi håber, at du vil nyde denne artikel og lære, hvad polymorfisme er i objektorienteret programmering. Hvis du vil læse en anden af vores artikler om programmering, anbefaler vi, at du besøger følgende, der giver os en meget kendt programmeringsform i computerverdenen: C ++ programmering.