Java ‘public’ Access Modifier

1. Oversikt

I denne raske artikkelen vil vi dekke offentlig modifikatoren grundig, og vi vil diskutere når og hvordan du bruker den med klasser og medlemmer.

I tillegg illustrerer vi ulempene ved å bruke offentlige datafelt.

For en generell oversikt over tilgangsmodifikatorer, ta en titt på artikkelen vår om tilgangsmodifikatorer i Java.

2. Når skal du bruke Public Access Modifier

Offentlige klasser og grensesnitt, sammen med offentlige medlemmer, definerer en API. Det er den delen av koden vår som andre kan se og bruke til å kontrollere oppførselen til objektene våre.

Imidlertid bryter overbruk av den offentlige modifisereren innkapslingsprinsippet Object-Oriented Programming (OOP) og har noen ulemper:

  • Det øker størrelsen på et API, noe som gjør det vanskeligere for klienter å bruke
  • Det blir vanskeligere å endre koden vår fordi kunder stoler på den - eventuelle fremtidige endringer kan bryte koden

3. Offentlige grensesnitt og klasser

3.1. Offentlige grensesnitt

Et offentlig grensesnitt definerer en spesifikasjon som kan ha en eller flere implementeringer. Disse implementeringene kan enten bli levert av oss eller skrevet av andre.

For eksempel eksponerer Java API Forbindelse grensesnitt for å definere databaseforbindelsesoperasjoner, og overlate den faktiske implementeringen til hver leverandør. Ved kjøretid får vi ønsket tilkobling basert på prosjektoppsettet:

Tilkoblingstilkobling = DriverManager.getConnection (url);

De getConnection metoden returnerer en forekomst av en teknologispesifikk implementering.

3.2. Offentlige klasser

Vi definerer offentlige klasser slik at klienter kan bruke medlemmene sine ved instantiering og statisk referanse:

assertEquals (0, ny BigDecimal (0) .intValue ()); // instansmedlem assertEquals (2147483647, Integer.MAX_VALUE); // statisk medlem 

Videre kan vi designe offentlige klasser for arv ved å bruke det valgfrie abstrakt modifikator. Når vi bruker abstrakt modifiserende, er klassen som et skjelett som har felt og forhåndsimplementerte metoder som enhver konkret implementering kan bruke, i tillegg til å ha abstrakte metoder som hver underklasse trenger å implementere.

For eksempel gir Java samlinger rammeverket Abstraktliste klasse som grunnlag for å lage tilpassede lister:

offentlig klasse ListOfThree utvider AbstractList {@Override public E get (int index) {// tilpasset implementering} @Override public int size () {// tilpasset implementering}}

Så, vi trenger bare å implementere få() og størrelse() metoder. Andre metoder som oversikt over() og inneholderAlle () er allerede implementert for oss.

3.3. Nestede offentlige klasser og grensesnitt

I likhet med offentlige toppklasser og grensesnitt definerer nestede offentlige klasser og grensesnitt en API-datatype. Imidlertid er de spesielt nyttige på to måter:

  • De indikerer for API-sluttbrukeren at den vedlagte toppnivåetypen og dens vedlagte typer har et logisk forhold og brukes sammen
  • De gjør kodebasen vår mer kompakt ved å redusere antall kildekodefiler som vi ville brukt hvis vi hadde erklært dem som toppklasser og grensesnitt

Et eksempel er Kart.Inngang grensesnitt fra kjernen Java API:

for (Map.Entry entry: mapObject.entrySet ()) {}

Lager Kart.Oppføring a nestet grensesnitt forholder det sterkt til java.util.Kart grensesnitt og har reddet oss fra å opprette en annen fil i java.util pakke.

Les artikkelen om nestede klasser for mer informasjon.

4. Offentlige metoder

Offentlige metoder gjør det mulig for brukere å utføre ferdige operasjoner. Et eksempel er publikum toLowerCase metoden i String API:

assertEquals ("alex", "ALEX" .toLowerCase ());

Vi kan trygt lage en offentlig metode statisk hvis den ikke bruker noen forekomstfelt. De parseInt metoden fra Heltall klasse er et eksempel på en offentlig statisk metode:

assertEquals (1, Integer.parseInt ("1"));

Konstruktører er vanligvis offentlige slik at vi kan starte og initialisere objekter, selv om de noen ganger kan være private som i singletoner.

5. Offentlige felt

Offentlige felt tillater å endre tilstanden til et objekt direkte. Tommelfingerregelen er at vi ikke skal bruke offentlige felt. Det er flere grunner til dette, som vi er i ferd med å se.

5.1. Trådsikkerhet

Å bruke offentlig synlighet med ikke-endelige felt eller endelige mutable felt er ikke trådsikkert. Vi kan ikke kontrollere å endre referanser eller tilstander i forskjellige tråder.

Vennligst sjekk artikkelen vår om trådsikkerhet for å lære mer om å skrive trådsikker kode.

5.2. Gjør tiltak for endringer

Vi har ingen kontroll over et ikke-endelig offentlig felt fordi referansen eller tilstanden kan settes direkte.

I stedet er det bedre å skjule feltene ved hjelp av en privat modifikator og bruke en offentlig setter:

offentlig klasse Student {privat int alder; public void setAge (int age) {if (age 150) {throw new IllegalArgumentException (); } this.age = alder; }}

5.3. Endring av datatype

Offentlige felt, foranderlige eller uforanderlige, er en del av kundens kontrakt. Det er vanskeligere å endre datarepresentasjonen for disse feltene i en fremtidig utgivelse fordi klienter kan trenge å omformulere implementeringen.

Ved å gi felt privat omfang og bruke aksessorer, har vi fleksibiliteten til å endre den interne representasjonen samtidig som vi opprettholder den gamle datatypen:

 offentlig klasse Student {privat StudentGrade karakter; // ny datarepresentasjon offentlig ugyldighet setGrade (int karakter) {this.grade = new StudentGrade (grade); } public int getGrade () {returner this.grade.getGrade (). intValue (); }}

Det eneste unntaket for bruk av offentlige felt er bruken av statiske endelige uforanderlige felt for å representere konstanter:

offentlig statisk finale String SLASH = "/";

6. Konklusjon

I denne veiledningen så vi at den offentlige modifikatoren brukes til å definere en API.

Vi beskrev også hvordan overbruk av denne modifikatoren kan begrense muligheten til å introdusere forbedringer i implementeringen.

Til slutt diskuterte vi hvorfor det er dårlig praksis å bruke offentlige modifikatorer for felt.

Og som alltid er kodeeksemplene i denne artikkelen tilgjengelig på GitHub.