En forelesningsbit med en mentor som en del av Codegym University-kurset. Meld deg på hele kurset.


"Hilsen, Amigo! Jeg hører at du allerede har god forståelse for metoder?"

"Hei, Rishi. Ja, jeg har allerede skjært meg gjennom det lærertrikset. Jeg vil si at det ikke var så ille, men du vil si til meg," Nei, nei! Du har ikke funnet ut av noe. '"

"Du har tydeligvis brukt for mye tid på å chatte med visse lærere, sannsynligvis med Diego. Uansett... Jeg håper fortsatt du forstår metoder godt nok. Tross alt, i dag skal jeg lære deg noen magiske ord som hjelper deg med å avgrense metoder «innflytelsessfærer».

"Høres spennende ut."

"Faktisk er det hele enkelt. Før hver metode kan programmerere spesifisere såkalte tilgangsmodifikatorer. Disse inkluderer følgende nøkkelord: public, protected, private.

"Disse tilgangsmodifikatorene lar deg begrense andre klassers tilgang til en metode.

"For eksempel, hvis du skriver nøkkelordet privatefør en metodeerklæring, så kan metoden bare kalles fra samme klasse som den er deklarert i. Nøkkelordet publicgir tilgang til den merkede metoden fra hvilken som helst metode av en hvilken som helst klasse.

Det er totalt 3 slike modifikatorer, men det er 4 typer tilgang til en metode. Dette er fordi fraværet av en tilgangsmodifikator også betyr noe. Her er en komplett tabell:

Tilgang fra...
Modifikatorer Hvilken som helst klasse Barneklasse Dens pakke Dens klasse
public Ja Ja Ja Ja
protected Nei Ja Ja Ja
ingen modifikator Nei Nei Ja Ja
private Nei Nei Nei Ja

"Og her er en fullstendig forklaring av tilgangsmodifikatorene:

1. publicmodifikator

En metode (eller variabel eller klasse) merket med publicmodifikator kan nås fra hvor som helst i programmet . Dette er den høyeste graden av åpenhet - det er ingen begrensninger.

2. privatemodifikator

En metode (eller variabel eller klasse) merket med privatemodifikatoren kan bare nås fra den samme klassen der den er deklarert . For alle andre klasser er den merkede metoden (eller variabelen) usynlig. Det er som om det ikke eksisterer. Dette er det høyeste nivået av begrensning - bare sin egen klasse.

3. Ingen modifikator (standardmodifikator)

Hvis en metode (eller variabel) ikke er merket med noen modifikator, anses den å ha 'standardmodifikatoren'. Variabler eller metoder med den modifikatoren (dvs. med ingen i det hele tatt) er synlige for alle klasser i pakken der de er deklarert . Og bare til dem. Denne modifikatoren kalles også noen ganger package-private, og antyder at tilgang til variabler og metoder er åpen for hele pakken der klassen deres er plassert.

4. protectedmodifikator

Hvis en metode er merket med protectedmodifikatoren, kan den nås fra samme klasse, samme pakke og etterkommere (klasser som arver klassen som metoden er deklarert i). Vi vil analysere dette emnet mer detaljert i Java Core-oppdraget."

"Interessant, men jeg er ikke sikker på om jeg umiddelbart kan plassere disse modifikatorene på alle de riktige stedene.

"Du vil komme dit gradvis. Du trenger ikke å bekymre deg på forhånd. Inntil du når slutten av Java Syntax-oppdraget, kan du bruke modifikatoren publicpå alle metodene dine (så vel som klasser og instansvariabler). Du trenger andre modifikatorer når vi begynner aktivt å lære OOP."

"Kan du forklare mer detaljert hvorfor tilgangsmodifikatorer er nødvendig?"

"De blir nødvendige for store prosjekter skrevet av titalls og hundrevis av programmerere samtidig.

"Noen ganger er det situasjoner når en programmerer ønsker å dele opp en altfor stor metode i deler og flytte deler av koden inn i hjelpemetoder. Men samtidig vil han eller hun ikke at andre programmerere skal kalle disse hjelpemetodene, fordi korresponderende kode fungerer kanskje ikke riktig."

"Så de kom opp med disse tilgangsmodifikatorene. Hvis du merker en hjelpemetode med ordet privat , kan ingen annen kode enn klassen din se hjelpemetoden din."

"Jeg tror jeg forstår."

staticnøkkelord

"Det er et annet interessant nøkkelord. Det er static. Ikke overraskende gjør det metoder statiske."

"Hva betyr det?"

"Jeg skal fortelle deg mer om det senere. Ikke bekymre deg. For nå, prøv å huske et par fakta om statiske metoder.

Fakta 1. En statisk metode er ikke knyttet til noe objekt, men tilhører i stedet klassen den er deklarert i. For å kalle en statisk metode, må du skrive:

ClassName.MethodName()

Eksempler på statiske metoder:

Klassenavn Statisk metodenavn
Thread.sleep() Thread sleep()
Math.abs() Math abs()
Arrays.sort() Arrays sort()

Klassenavnet før navnet på en statisk metode kan utelates hvis du kaller den statiske metoden fra klassen . Dette er grunnen til at du ikke trenger å skrive før navnene på hver av de statiske metodene som kalles.Solution

Fakta 2. En statisk metode kan ikke få tilgang til de ikke-statiske metodene i sin egen klasse. En statisk metode kan bare få tilgang til statiske metoder. Som et resultat erklærer vi alle metodene som vi ønsker å kalle fra metoden mainstatiske."

"Hvorfor det?"

"Du vil svare på dette spørsmålet selv når du begynner å lære OOP og forstår hvordan statiske metoder fungerer. Inntil da, bare stol på meg.

throwsnøkkelord

"Det er et annet nøkkelord som du sannsynligvis har sett i en metodeerklæring - nøkkelordet throws. I motsetning til tilgangsmodifikatorer og staticnøkkelordet, er dette nøkkelordet plassert etter metodeparameterne:

public static Type name(parameters) throws Exception
{
  method body
}

"Og hva betyr det?"

"Nok en gang må jeg fortelle deg at du vil lære dens sanne hensikt senere, når vi studerer unntak (i ​​nivå 15).

Men for å berøre det overfladisk, kan vi si at en metode merket med nøkkelordet throwskan gi feil (unntak), altså forekomster av Exceptionklassen (og klasser som arver den). Hvis flere forskjellige typer feil kan oppstå i en klasse, må du liste hver av dem atskilt med komma."

"Høres mystisk og uforståelig ut! Jeg må vente på nivå 14."

hovedmetoden

"La oss nå se nærmere på hovedmetoden. Du forstår allerede at linjen der en metode er deklarert, som inneholder alle modifikatorene, vil påvirke hvordan denne metoden kalles fra andre klasser og metoder. I tillegg påvirker den typen av Resultatet vil metoden returnere og indikerer hvilke feil som er mulige mens den kjører.

"En slik linje kalles en metodeerklæring og har følgende generelle format:

access modifier static Type name(parameters) throws exceptions
Generelt format for en metodeerklæring

Hvor access modifierser erstattet av public, protected, private, eller ingenting i det hele tatt;

hvis metoden er statisk, staticvises nøkkelordet (det er fraværende for ikke-statiske metoder)

Typeer typen returverdi ( voidhvis det ikke er noe resultat)

"Nå har du en mye bedre forståelse av hva alle disse ordene betyr i erklæringen om metoden main:

public static void main(String[] args) throws Exception
Deklarerer mainmetoden

"Vel, nå innser jeg at tilgang til main()metoden er mulig fra hvilken som helst klasse, som indikert av publicnøkkelordet. Metoden er statisk, så den kan eksplisitt kalles som Solution.main()."

"Hvilket resultat returnerer main()metoden?"

"Ingen i det hele tatt! Resultattypen er void. Det er litt som en tom type, en plassholder."

"Hva main()står det i parentesen?"

"Hmm... Det viser seg at mainmetoden tar argumenter (!). De sendes inn som en rekke strenger."

"Det stemmer. Og parameternavnet argsantyder "argumenter" for våre sinn. Når programmet starter, kan du sende det argumenter - en rekke strenger. De vil være inneholdt i matrisen argsi main()metoden."

"Wow! Jeg lurte på dette da jeg så det første gang, men så ble jeg vant til det og begynte å skrive parameterlisten uten å tenke."

"Vi har alle vært der. Endelig kan ubehandlede feil som Exception(eller dens etterkommere) oppstå i main()metoden. Vi vet dette takket være throws Exceptiondelen av erklæringen."

"Takk, Rishi. Jeg forsto ikke alt, men dette var interessant."

"Du er velkommen. Gradvis vil du forstå alle disse subtile punktene, det er jeg sikker på."