Hei! La oss dedikere dagens leksjon til innkapsling og begynne med en gang med eksempler :) Prinsipper for innkapsling - 1Her har du en vanlig brusmaskin . Jeg har ett spørsmål til deg: hvordan fungerer det? Prøv å gi et detaljert svar: hvor kommer koppen fra, hvordan opprettholdes den indre temperaturen, hvor lagres isen, hvordan vet maskinen hvilken sirup som skal tilsettes osv.? Du har sannsynligvis ikke svar på disse spørsmålene. Greit nok, siden ikke alle bruker slike maskiner. De er ikke så populære i dag. La oss prøve å gi et annet eksempel. Noe du definitivt bruker mange ganger hver dag. Å, her er en idé! Prinsipper for innkapsling - 2Fortell oss hvordan Googles søkemotorvirker. Hvordan søker den etter informasjon relatert til ordene du skriver inn? Hvorfor rangeres visse resultater høyt og andre ikke? Selv om du bruker Google hver dag, er sjansen stor for at du ikke vet. Men det spiller ingen rolle. Du trenger ikke vite dette. Du kan legge inn søk i en søkemotor uten å tenke på hvordan den fungerer. Du kan kjøpe brus fra en maskin uten å vite hvordan det fungerer. Du kan kjøre bil uten å forstå hvordan en forbrenningsmotor fungerer, og uten å kunne fysikk i det hele tatt, selv på barneskolenivå. Alt dette er mulig takket være et av hovedprinsippene for objektorientert programmering: innkapsling. Når du leser ulike artikler om objektorientert programmering (OOP), må du ha kommet over det faktum at programmering involverer to vanlige begreper: innkapsling og skjul . Og forfattere bruker ordet "innkapsling" for å bety en ting og så en annen. Vi vil utforske begge begrepene slik at du får en fullstendig forståelse. I programmering er den opprinnelige betydningen av innkapsling bunting av data, sammen med metodene som opererer på disse dataene, til en enkelt enhet (dvs. en "kapsel"). I Java er klassen enheten for innkapsling. En klasse inneholder både data (felt) og metoder for å arbeide med disse dataene.Prinsipper for innkapsling - 3Dette kan virke som den åpenbart riktige tilnærmingen for deg, men i andre programmeringsparadigmer er alt ordnet annerledes. For eksempel, i funksjonell programmering, er data strengt atskilt fra operasjoner på den. I OOP består programmer av kapsler, eller klasser, som består av både data og funksjoner for å jobbe med disse dataene. La oss nå snakke om å gjemme seg . Hvordan har det seg at vi bruker alle slags komplekse enheter uten å forstå hvordan de er organisert eller hvordan de fungerer? Det er enkelt: Skaperne deres ga oss et enkelt og praktisk grensesnitt. På en brusmaskin er grensesnittet knappene på panelet. Ved å trykke på én knapp velger du koppstørrelsen. Trykker du på en annen velger du smaken. En tredje er ansvarlig for å legge til is. Og det er alt du trenger å gjøre. Den interne organiseringen av maskinen spiller ingen rolle. Det som betyr noe er at den er utformet på en måte som krever at brukeren trykker på tre knapper for å få brus . Det samme gjelder biler. Det spiller ingen rolle hva som skjer inni. Det som betyr noe er at når du trykker på høyre pedal, beveger bilen seg fremover, og når du trykker på venstre pedal, bremser den ned. Det er det å gjemme seg til. Alt av et programs "innside" er skjult for brukeren. For brukeren, denne overflødige, unødvendige informasjonen. Brukeren trenger sluttresultatet, ikke den interne prosessen. La oss se på Autoklassen som et eksempel:
public class Auto {

   public void go() {

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

   public void brake() {

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

   public static void main(String[] args) {

       Auto auto = new Auto();

       // From the user's perspective,

       // one pedal is pressed and the car accelerates.
       auto.gas();

       // The other is pressed, and the car slows down.
       auto.brake();
   }
}
Slik ser implementeringsskjul ut i et Java-program. Det er akkurat som i det virkelige liv: brukeren er utstyrt med et grensesnitt (metoder). Hvis brukeren trenger en bil i et program for å utføre en handling, ringer han eller hun bare ønsket metode. Det som skjer inne i disse metodene er overflødig. Det som betyr noe er at alt fungerer som det skal. Her snakker vi om implementeringsskjuling . Utenom det har Java også dataskjuling . Vi skrev om det i leksjonen om getters og setters , men det vil ikke skade å gå gjennom konseptet. For eksempel har vi en Catklasse:
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!");
   }


}
Kanskje du husker problemet med denne timen fra forrige leksjon? Hvis ikke, la oss huske det nå. Problemet er at dataene (feltene) er åpne for alle - en annen programmerer kan enkelt lage en navnløs katt med en vekt 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;

}
Kanskje du kan følge nøye med på om en av dine medarbeidere har laget objekter med ugyldig tilstand, men det ville være mye bedre å utelukke selv muligheten for å lage slike "ugyldige objekter". Prinsipper for innkapsling - 4Følgende mekanismer hjelper oss med å skjule data:
  1. tilgangsmodifikatorer ( privat , beskyttet , pakkestandard )
  2. gettere og settere
For eksempel kan vi sette en sjekk der for å se om noen prøver å tildele et negativt tall til kattens alder. Som vi sa tidligere, mener forfatterne av ulike artikler om innkapsling noen ganger å kombinere data og metoder, eller skjule dem, eller begge deler (kombinere og skjule dem). Java har begge mekanismene (dette er ikke nødvendigvis sant for andre OOP-språk), så den siste betydningen er mest korrekt. Innkapsling gir oss flere viktige fordeler:
  1. Kontroll over den riktige tilstanden til et objekt. Det var eksempler på dette ovenfor. En setter og den private modifikatoren sørger for at programmet vårt ikke vil ha katter som veier 0.

  2. Brukervennlighet gjennom et grensesnitt. Kun metoder blir "eksponert" for omverdenen. Ringemetoder er nok for å få et resultat - det er absolutt ingen grunn til å fordype seg i detaljene om hvordan de fungerer.

  3. Kodeendringer påvirker ikke brukere. Vi gjør alle endringer i metodene. Dette påvirker ikke brukeren av metoden: hvis den riktige koden tidligere var "auto.gas()" for å bruke gasspedalen, vil den fortsette å være det. Det faktum at vi har endret noe inne i gas()-metoden forblir usynlig for brukeren: som før mottar den som ringer rett og slett ønsket resultat.