Indkapsling i Java

Hej! Vi vil afsætte dagens lektion til Indkapsling i Java og begynde med eksempler lige ud af porten:) Her har du en almindelig sodavandsautomat . Jeg har et spørgsmål til dig: Hvordan fungerer det? Prøv at give et detaljeret svar: Hvor kommer sodavandet fra? Hvordan holdes den indre temperatur? Hvor opbevares isen? Hvordan ved maskinen, hvilken sirup der skal tilsættes? Du har sandsynligvis ikke svar på disse spørgsmål. Okay, måske ikke alle bruger disse maskiner. De er ikke så populære i øjeblikket. Lad os prøve et andet eksempel. Noget du helt sikkert bruger mange gange hver dag. Åh, jeg har en idé! Fortæl mig hvordan Google-søgemaskinenarbejder. Hvordan søger den præcist efter information om de ord, du indtaster? Hvorfor er disse resultater øverst og ikke andre? Selvom du bruger Google hver dag, ved du det sikkert ikke. Men det gør ikke noget. Det er trods alt ikke noget, du behøver at vide. Du kan bruge en søgemaskine uden at tænke over præcis, hvordan den fungerer. Du kan købe sodavand fra en maskine uden at vide, hvordan den er bygget. Du kan køre bil uden at dykke ned i, hvordan forbrændingsmotoren fungerer, og uden overhovedet at kende fysik i gymnasiet. Dette er alt muligt takket være et af hovedprincipperne for objektorienteret programmering: indkapsling. Ved at læse forskellige artikler om emnet, skal du have stødt på to udbredte programmeringskoncepter: indkapsling og informationsskjul. Som det sker, forstår forskellige mennesker ordet ' indkapsling' til at betyde forskellige ting. Vi dechifrerer begge udtryk, så du har en fuldstændig forståelse. I programmering, den oprindelige betydning afindkapsling var at kombinere data og metoder til at arbejde med disse data i én pakke ("kapsel"). I Java er indkapslingspakke klassen . Klassen indeholder både data (felter) og metoder til at arbejde med disse data. Dette kan virke indlysende for dig, men alt er arrangeret anderledes i andre programmeringsparadigmer. For eksempel i funktionel programmering er data strengt adskilt fra dataoperationer. I objektorienteret programmering (OOP) består programmer af kapsler (klasser) bestående af både data og funktioner til at arbejde med data.

Lad os nu tale om at skjule oplysninger

Hvordan bruger vi alle mulige komplekse mekanismer uden at forstå, hvordan de er bygget, eller hvordan de virker? Det er enkelt: deres skabere leverede enkle og praktiske grænseflader. På en sodavandsmaskine er grænsefladen knapperne på frontpanelet. Én knap giver dig mulighed for at vælge kopstørrelsen. Du vælger siruppen med en anden knap. En tredje er ansvarlig for at tilføje is. Og det er alt, du skal gøre. Det er lige meget, hvordan maskinen ser ud indvendigt. Det vigtige er, at det er designet, så brugeren får sodavand ved at trykke på tre knapper. Det samme gælder for en bil. Det er lige meget, hvad der foregår indeni. Det vigtige er, at når du trykker på højre pedal, bevæger bilen sig fremad, og når du trykker på venstre pedal, sænker bilen farten. Dette er essensen af ​​at skjule information. Alt sammen et program' s 'indvolde' er skjult for brugeren. Sådan information er overflødig eller unødvendig for brugeren. Brugeren har brug for et slutresultat, ikke en intern proces. For et eksempel, lad os tage et kig påKøretøjsklasse :

public class Vehicle {

   public void gas() {

       /* Some complicated things happen inside a car.
       As a result, it moves forward */
   }

   public void brake() {

       /* Some complicated things happen inside a car.
       As a result, it slows down */
   }

   public static void main(String[] args) {

       Vehicle vehicle = new Vehicle();

       // How everything looks to the user

       // Press one pedal, the car moves
       vehicle.gas();

       // Press the other pedal, the car brakes
       vehicle.brake();
   }
}

Sådan er implementeringen skjult i et Java-program. Ligesom i det virkelige liv: brugeren er udstyret med en grænseflade (metoder). I et program, hvis du har brug for en bil til at udføre en handling, kalder du blot den ønskede metode. Det, der sker inden for disse metoder, er overflødigt. Det afgørende er, at alt fungerer, som det skal. Her har vi talt om implementeringsskjul. Java har også dataskjul. Vi skrev om det i lektionen om getters og setters, men en påmindelse vil ikke skade. For eksempel har vi en kat klasse:

public class Cat {

   public String name;
   public int age;
   public int weight;

   public Cat(String name, int age, int weight) {
       this.name = name;
       this.age = age;
       this.weight = weight;
   }

   public Cat() {
   }

   public void sayMeow() {
       System.out.println("Meow!");
   }


}

Måske husker du fra en tidligere lektion, hvad problemet er med denne time? Hvis ikke, lad os huske. Problemet er, at dets data (felter) er åbne for alle. En anden programmør kunne nemt skabe en navnløs kat med en vægt på 0 og en alder på -1000 år:

public static void main(String[] args) {

   Cat cat = new Cat();
   cat.name = "";
   cat.age = -1000;
   cat.weight = 0;

}

I denne situation kan du omhyggeligt spore, om en af ​​dine kolleger opretter objekter med ugyldig tilstand, men det ville være meget bedre at eliminere selv muligheden for at oprette disse ugyldige objekter. Vi opnår dataskjul ved hjælp af:

1. adgangsmodifikatorer ( privat, beskyttet, pakkestandard );
2. gettere og sættere.

Vi bruger dem til at tjekke, om nogen forsøger at give katten en negativ alder. Som vi sagde tidligere, refererer forfatterne til forskellige artikler om indkapsling faktisk til indkapsling (kombinerer data og metoder) eller informationsskjul eller begge dele. Java har begge mekanismer (dette er ikke nødvendigvis tilfældet i andre OOP-sprog), så den sidste mulighed er mest korrekt.

Indkapsling giver os flere vigtige fordele:

1. Overvågning af korrekt objekttilstand. Vi gav eksempler på dette ovenfor: takket være setteren og den private modifikator har vi sikret vores program mod katte med en vægt på 0.


2. Brugervenlig grænseflade. Vi efterlader kun metoder eksponeret for brugeren. Brugeren skal blot ringe til dem for at få et resultat. Og der er ingen grund til at dykke ned i detaljerne om, hvordan de fungerer.


3. Kodeændringer påvirker ikke brugere. Vi foretager alle ændringer inde i metoder. Dette påvirker ikke brugerne: de skrev vehicle.gas() for at anvende gassen, og det er det, de bliver ved med at gøre. Det faktum, at vi har ændret noget inde i gas() -metoden, forbliver usynligt: ​​Som før får de simpelthen det ønskede resultat.