Meny

Java @override: Method Overriding And Runtime Polymorphism

  • Hoved
  • Annen
  • Java @override: Method Overriding And Runtime Polymorphism

java override method overriding

Prøv Instrumentet Vårt For Å Eliminere Problemer

Denne opplæringen forklarer hvordan du oppnår Runtime Polymorphism i Java ved hjelp av Method Overriding og @override-merknad med enkle eksempler:

Vi har allerede diskutert polymorfismekonseptet og kompileringstidspolymorfisme i detalj. I denne opplæringen vil vi fortsette med Runtime polymorfisme i Java.

I motsetning til kompileringstidspolymorfisme der metodeanrop løses ved kompileringstid, i løpetidspolymorfisme, blir metodekallingen løst ved kjøretid.

=> Sjekk ALLE Java-opplæringsprogrammer her.

@override_ Method Overriding In Java

Hva du vil lære:

Runtime Polymorphism In Java

En kjøretids polymorfisme som også er kjent som dynamisk polymorfisme eller Dynamisk metodeutsendelse er en teknikk der et tilsidesatt metodeanrop løses dynamisk ved kjøretid.

Runtime polymorfisme i Java oppnås ved å bruke “ metode overstyrende ”. Metodeoverstyring er en teknikk der en metode i foreldreklassen omdefineres eller overstyres i barneklassen.

Når metoden overstyres i en klasse, løser den dynamiske metodens utsendelsesteknikk den overstyrte metodeanropet ved kjøretid og ikke på kompileringstidspunktet.

Oppnå Runtime Polymorphism In Java - Method Overriding

Metodeoverstyring er tilnærmingen vi bruker for å oppnå kjøretidspolymorfisme i Java. Som allerede nevnt, er metodeoverstyring en teknikk der underklasse legger til en metode som allerede er tilstede i sin overordnede klasse og legger til ny funksjonalitet til denne metoden. Så sier vi at baseklassemetoden er overstyrt.

Den nye metoden vi definerte i underklassen med samme prototype som metoden til foreldreklassen, men annen implementering, kalles “ overordnet metode ” . Metoden i foreldreklassen er kjent som “ Overstyrt metode ”.

hvordan du åpner en kjørbar jar-fil

Når metoden er overstyrt, gjenstår spørsmålet om hvordan anropet til denne overstyrte metoden løses?

Vi kaller vanligvis den overstyrte metoden gjennom referansen til baseklassen. Vi oppretter en referanse for type base og tilordner deretter et underordnet objekt med det nye nøkkelordet.

Dermed avhenger det av innholdet i referansevariabelen eller hvilket objekt det refereres til av baseklassereferansen som bestemmer hvilken metode som skal kalles. Så hvis referanseobjektene peker mot objektet til barneklassen, kalles den overordnede metoden.

Ellers, hvis referanseobjektet inneholder et basisklasseobjekt, kalles den overstyrte metoden. Et emne vi trenger for å være tydelig i løpetidspolymorfisme, spesielt for dynamisk metodeutsendelse, er 'Upcasting', som forklares nedenfor.

Upcasting

Når et referanseobjekt til foreldreklassen vi diskuterte ovenfor, peker på eller refererer til objektet til underklassen, kaller vi det Upcasting.

Upcasting

La oss forstå utsending ved hjelp av et enkelt eksempel.

Tenk på at vi har en klasse ‘BaseClass’, og vi utvider denne BaseClass til å lage en ny klasse DerivedClass. Denne strukturen ser ut som vist nedenfor.

class BaseClass { ….//BaseClass code here } class DerivedClass extends BaseClass{ ….//DerivedClass code here }

For å implementere upcasting vil vi erklære en referansevariabel av typen BaseClass. Deretter tildeler vi et objekt av DerivedClass til referansen til klasse BaseClass som gjort i nedenstående kodeuttrykk.

BaseClass base = new DerivedClass (); //Upcasting

Så her kan vi si at vi har kastet opp DerivedClass-objektet til BaseClass. Når det gjelder polymorfisme i runtime, er begrepet upcasting veldig viktig.

Dermed er upcasting generelt prosessen med å tilordne barne- eller underklasseobjekter til referansen til en foreldre eller superklasse.

SuperClass reference = new Subclass Object;

Java-programmet nedenfor viser metodeoverstyring og viser også hvordan oppkasting utføres for å løse tilsidesatte metodeanrop ved kjøretid.

//base/parent class class Parent { void Print() //print method { System.out.println('Parent::Print() method'); } } //child class 1 inheriting from Parent class child1 extends Parent { void Print() //overridden print method { System.out.println('child1::Print() method'); } } //child class 2 inheriting from Parent class child2 extends Parent { void Print() //overridden print method { System.out.println('child2::Print() method'); } } class Main { public static void main(String() args) { Parent parent = new Parent(); parent.Print(); //executes parent Print () method parent = new child1(); //upcasting parent.Print(); //executes child1 Print () method parent = new child2(); //upcasting parent.Print(); //executes child2 Print () method

Produksjon:

Upcasting - utgang

I det ovennevnte programmet har vi to klasser, dvs. child1 og child2, som begge er avledet fra en 'Parent' -klasse. Foreldreklassen har en metode ‘Print’ som overstyres i både child1- og child2-klasser. Så i hovedmetoden lager vi et referanseobjekt til foreldreklassen som heter ‘foreldre’.

Først tildeler vi det et objekt fra foreldreklassen og kaller deretter “Print ()” -metoden. Deretter gjentar vi dette ved å tilordne først child1-objektet og deretter child2-objektet til foreldre-referansen.

hva betyr udefinert referanse i c ++

Utgangen viser, avhengig av innholdet i den overordnede referansen, og den riktige utskriftsmetoden kalles.

Fordeler med dynamisk / kjøretid polymorfisme

  • Med dynamisk polymorfisme har programmereren lov til å overstyre metoder.
  • Det tillater klasser å definere en metode med generell implementering som dens derivater deretter kan overstyre og gi den spesifikke implementeringen.
  • Med utsendelse av dynamisk metode løses metodeanropet ved kjøretid, i motsetning til overbelastning som avgjøres på kompileringstidspunktet. Dette gir mer fleksibilitet for programmererne.

Når polymorfisme i kjøretid binder den riktige metoden til samtalen på kjøretid, og vi kaller den også dynamisk binding eller sen binding . Kompileringstid polymorfisme derimot støtter statisk binding eller tidlig binding .

Statisk vs. dynamisk binding

Statisk bindingDynamisk binding
Metodeanrop løst ved kompileringstid er statisk bindende.Metodeanrop løst ved kjøretid er dynamisk bindende.
Metodeoverbelastning er et eksempel på statisk binding.Metodeoverstyring er et eksempel på dynamisk binding.
Klasse- og felttyper brukes til statisk binding.Objekter brukes til dynamisk binding.
Private, endelige og statiske enheter bruker statisk binding.Virtuelle metoder bruker dynamisk binding.

Virtuell funksjon / metode i Java

Virtuell funksjon eller metode i Java er en funksjon som brukes med Runtime polymorfisme. I motsetning til C ++, Java har ikke et spesielt 'virtuelt' nøkkelord å betegne at en metode er virtuell. En metode som er definert i basisklassen og overstyrt i den avledede klassen er virtuell.

I Java er som standard ikke-statisk metode bortsett fra privat og endelig en virtuell funksjon. Så vær oppmerksom på at metodene vi diskuterte ovenfor for å implementere polymorfism for kjøretid også er virtuelle metoder.

Ettersom den statiske metoden er bundet til klasse og ikke kan kalles ved hjelp av et objekt, kan den ikke brukes sammen med polymorfisme i løpetid, og den er heller ikke en virtuell funksjon.

Grensesnitt i Java er som standard virtuelle. Klasser som implementerer grensesnitt gir implementeringer for grensesnittmetodene. Som i løpetid polymorfisme, blir samtaler til grensesnittmetoder også løst ved kjøretid.

Husk at siden metoder i et grensesnitt er designet for å bli overstyrt, er alle grensesnittmetoder virtuelle funksjoner.

Tenk for eksempel på følgende kode:

interface car{ void accelerate(); } class Maruti implements car{ void accelerate () { System.out.println(“Maruti car accelerated!!”); } }

I ovennevnte kode er metoden accelerate () en virtuell funksjon, siden den er en del av grensesnittbilen og er designet for å bli overstyrt.

@override Annotation In Java

@Override-merknaden er standardkommentar i Java. Denne kommentaren ble introdusert i Java 1.5. @Override-merknaden brukes når underklassemetoden overstyrer superklassemetoden.

Ved å bruke Java @override-merknad for å indikere at metoden overstyrer sin overordnede klassemetode, utsteder en kompilator en advarsel hvis den merkede metoden ikke overstyres. Så gjør det obligatorisk at metoden overstyres når @override-merknaden brukes.

For det andre, ved å bruke @override-merknaden, gjør vi koden mer lesbar. Vi kan med en gang innse at metoden som blir erklært skal overstyres.

Den generelle syntaksen til Java @override-merknaden er

public @interface override

Java-programmet nedenfor viser bruken av @override-merknader.

//base class definition class BaseClass { public void display() { System.out.println('BaseClass::display () method'); } } //derived class inheriting base class class DerivedClass extends BaseClass { @Override //indicates the display method being overridden public void display() { System.out.println('DerivedClass::display () method'); } } // main class public class Main { public static void main(String args()) { System.out.println('@Override Example'); //BaseClass type object;contain child object BaseClass testObj = new DerivedClass(); //call display method based on contents of object i.e. derived class display () testObj.display(); } }

Produksjon:

@ Override Eksempel

I programmet ovenfor har vi en BaseClass som definerer en visningsmetode. Deretter utleder vi en klasse DerivedClass fra denne BaseClass og markerer visningsmetoden med @override-merknaden. Denne metoden overstyres i DerivedClass.

I hovedmetoden oppretter vi en BaseClass-objektreferanse og peker den til DerivedClass-objektet som får referansen til å kalle DerivedClass-visningsmetoden.

Hvis vi ikke hadde implementert display () -metoden i Derived-klassen, ville kompilatoren ha gitt en kompilatorvarsel da den er merket med @override-kommentar.

Overbelastning og overstyring i Java

Nå som vi har diskutert både overbelastning og overstyring i Java, la oss oppsummere disse to konseptene.

Overbelastning er relatert til kompileringstidspolymorfisme, dvs. vi implementerer kompileringspolymorfisme ved bruk av overbelastning. Overbelastning gjøres på to måter, dvs. metodeoverbelastning og overbelastning av operatør.

Metodeoverbelastning er teknikken der vi har mer enn en metode med samme navn, men forskjellige parameterlister. Parameterlisten er differensiert basert på antall parametere, parametertyper eller sekvensen av parametere.

Overbelastning av operatører i Java er begrenset, og det lar oss bare overbelaste ‘+’ operatøren som brukes til å legge til to tall og sammenkoble to strengobjekter.

Overbelastning løses ved kompileringstid og er statisk. Det kalles også ‘Tidlig binding’ .

Metodeoverstyring er en funksjon der vi implementerer kjøretidspolymorfisme. I metodeoverstyring overstyres en metode for foreldreklassen i barneklassen. Dette betyr at metoden prototypen i både super og underklasse forblir den samme, men implementeringene er forskjellige.

Overstyring av metoden bruker den dynamiske metodens utsendelsesteknikk for å løse metodeanropet og bestemme om det skal kalles en superklasse- eller underklassemetode, og dette gjøres ved kjøretid.

Derfor kalles polymorfisme også dynamisk polymorfisme eller sen binding.

La oss deretter tabellisere forskjellene mellom overbelastning og overstyring i Java.

Overbelastning mot overstyring i Java

OverbelastningOverstyring
Overbelastning brukes i polymorfisme under kompileringstid.Overstyring er implementert i løpetid polymorfisme.
Kan gjøres i samme klasse. Kan kreve arv eller ikke.Overstyring krever alltid arv.
Metoder er overbelastet med samme metodenavn og annen parameterliste.Overstyrte metoder har de samme prototypene.
Returtypen blir ikke vurdert ved overbelastning av metoden.Returtype skal være den samme i overstyrte og overordnede metoder.
Forbedrer lesbarheten til programmet.Overstyring tillater å ha spesifikk implementering klassevis.

ofte stilte spørsmål

Q # 1) Kan vi overstyre den statiske metoden?

Svar: Nei. Statiske metoder kan ikke overstyres i Java. Dette er fordi statiske metoder er klassebaserte og kalles direkte av klasse. De trenger ikke gjenstander for å påkalle på kjøretid. Derfor blir den statiske metoden sendt av kompilatoren.

Q # 2) Kan vi overstyre konstruktøren?

Svar: Nei, vi kan ikke overstyre en konstruktør. En konstruktør kalles når objektet er opprettet. Det kalles ikke et objekt. Et av kravene til overstyring er også den overstyrte metoden, og den overordnede metoden skal ha samme metodesignatur som ikke er mulig i tilfelle av konstruktører.

Q # 3) Hvorfor kalles metodeoverstyring som dynamisk polymorfisme?

Svar: I tilfelle metodeoverstyring løses metodeanropet dynamisk ved kjøretid. Derfor kalles det dynamisk polymorfisme.

Q # 4) Hva er bruken av dynamisk polymorfisme i Java?

Svar: Dynamisk polymorfisme bruker en dynamisk metode for utsendelse av metoder som støtter overstyring av metoden slik at underklassen kan gi spesifikk implementering av den overstyrte metoden. På denne måten kan vi implementere de spesifikke funksjonene som lar oss skrive effektive programmer.

hvordan du bruker stringstream c ++

For det andre trenger vi heller ikke bekymre oss for å løse metodeanrop, ettersom utsendelse av dynamisk metode bestemmer hvilken metode vi skal ringe.

Q # 5) Hva er forskjellen mellom statisk og dynamisk binding?

Svar: Koblingen mellom en metodeanrop og implementeringen av den kalles bindende. Når denne koblingen er løst på kompileringstid, kaller vi det som statisk binding. Når bindingen gjøres dynamisk ved kjøretid, kaller vi det som dynamisk binding.

Den statiske bindingen bruker datatypen klasse og felt for å løse metodeanrop. Den dynamiske bindingen bruker objekter til å løse metodeanrop. Statisk binding kalles også polymorfisme for kompileringstid og dynamisk binding kalles også polymorfisme for kjøretid.

Konklusjon

I denne veiledningen har vi diskutert polymorfisme i Java i detalj.

Runtime polymorfisme er implementert ved hjelp av metodeoverstyring. Metodeoverstyring gjøres i underklassen hvor en metode definert i superklassen omdefineres eller overstyres i underklassen. Metodesignaturen forblir den samme i super- og underklassen.

Ved å bruke metodeoverstyring kan vi gi spesifikk implementering av den samme metoden i underklassen. På denne måten kan vi skrive mer effektive programmer som involverer arv. Java gir @override-merknader for å indikere at metoden skal overstyres.

Som standard er alle ikke-statiske metoder som ikke er endelige virtuelle i Java. Alle virtuelle metoder kan overstyres.

=> Se opp den enkle Java-treningsserien her.

Anbefalt lesing

^