OOP-prinsipper

Hei! I dagens leksjon skal vi snakke om prinsipper for objektorientert programmering. Har du noen gang lurt på hvorfor Java er designet akkurat som det er? Jeg mener, man deklarerer klasser og lager objekter basert på klasser, klasser har metoder osv. Men hvorfor er språket strukturert slik at programmer består av klasser og objekter, og ikke noe annet? Hvorfor ble begrepet "objekt" oppfunnet og satt på spissen? Er alle språk utformet på denne måten? Hvis ikke, hvilke fordeler gir det til Java? Som du kan se er det mange spørsmål :) La oss prøve å svare på hver av dem i dagens leksjon.

Hva er objektorientert programmering (OOP)?

Java består selvfølgelig ikke av objekter og klasser bare for moro skyld. De er ikke et innfall av Javas skapere, og ikke engang deres oppfinnelse. Det er mange andre språk basert på objekter. Det første slike språk ble kalt "Simula". Den ble oppfunnet i Norge på 1960-tallet. Dessuten dukket begrepene "klasse" og "metode" opp i Simula. Etter standardene for programvareutvikling virker "Simula" som et eldgammelt språk, men alle kan se dets "familielikhet" med Java. Du kan sikkert enkelt lese koden skrevet på dette språket og forklare i store trekk hva den gjør :)

Begin
	Class Rectangle (Width, Height); Real Width, Height;
			           
	 Begin
	    Real Area, Perimeter;  
	 
	    Procedure Update;      
	    Begin
	      Area := Width * Height;
              OutText("Rectangle is updating, Area = "); OutFix(Area,2,8); OutImage;
	      Perimeter := 2*(Width + Height);
              OutText("Rectangle is updating, Perimeter = "); OutFix(Perimeter,2,8); OutImage;
	    End of Update;
	 
	    Update;               
	    OutText("Rectangle created: "); OutFix(Width,2,6);
	    OutFix(Height,2,6); OutImage;
	 End of Rectangle;

       Rectangle Class ColouredRectangle (Color); Text Color;
			           
	Begin   	  
	    OutText("ColouredRectangle created, color = "); OutText(Color);
	    OutImage;
        End of ColouredRectangle;

 
      	 Ref(Rectangle) Cr;            
	 Cr :- New ColouredRectangle(10, 20, "Green"); 
End;

Denne kodeeksempelkoden ble hentet fra "Simula - 50 years of OOP" av Weekly-geekly. Som du kan se, er ikke Java så veldig forskjellig fra sin bestefar :) Dette skyldes det faktum at utseendet til Simula markerte fødselen til et nytt konsept: objektorientert programmering. Wikipedia definerer OOP slik: "Object-Oriented Programming (OOP) er et programmeringsparadigme basert på konseptet "objekter", som kan inneholde data, i form av felt (ofte kjent som attributter), og kode, i formen av prosedyrer (ofte kjent som metoder)." Etter min mening er dette en veldig god definisjon. Det er ikke lenge siden du begynte å lære Java, men denne definisjonen inneholder sannsynligvis ingen ord du ikke kjenner :) I dag er OOP den vanligste programmeringsmetodikken. I tillegg til Java, OOP-prinsipper brukes på mange populære språk som du kanskje har hørt om. For eksempel C++ (aktivt brukt i spillutvikling), Objective-C og Swift (brukes til å skrive programmer for Apple-enheter), Python (mest populær innen maskinlæring), PHP (et av de mest populære webutviklingsspråkene), JavaScript ( det er lettere å si hva det ikke brukes til) og mange andre. Så, hva er prinsippene for OOP uansett? Vi vil fortelle deg i detalj. hva er prinsippene for OOP uansett? Vi vil fortelle deg i detalj. hva er prinsippene for OOP uansett? Vi vil fortelle deg i detalj.

OOP-prinsipper

Disse er grunnlaget for stiftelsen. De 4 hovedtrekkene som til sammen danner det objektorienterte programmeringsparadigmet. Å forstå dem er avgjørende for å bli en vellykket programmerer.

Prinsipp 1. Arv

Gode ​​nyheter: du kjenner allerede noen av prinsippene til OOP! :) Vi har allerede møtt arv et par ganger i timene, og vi klarte å bruke det. Arv er en mekanisme som lar deg beskrive en ny klasse basert på en eksisterende (overordnet) klasse. Ved å gjøre dette låner den nye klassen egenskapene og funksjonaliteten til den overordnede klassen. Hva er arv for og hvilke fordeler gir det? Fremfor alt gjenbruk kode. Feltene og metodene som er deklarert i overordnede klasser kan brukes i etterkommerklasser. Hvis alle typer biler har 10 felles felt og 5 identiske metoder, trenger du bare å flytte dem inn i Autoforeldreklasse. Du kan bruke dem i etterkommerklasser uten problemer. Solide fordeler: både kvantitativ (mindre kode) og, som et resultat, kvalitativ (klasser blir mye enklere). Dessuten er arv veldig fleksibelt - du kan legge til skriveseparat funksjonalitet som etterkommerne mangler (noen felter eller atferd som er spesifikke for en bestemt klasse). Generelt, som i det virkelige liv, er vi alle litt like foreldrene våre, men også forskjellige fra dem :)

Prinsipp 2. Abstraksjon

Dette er et veldig enkelt prinsipp. Abstraksjon betyr å identifisere de viktigste, mest betydningsfulle egenskapene til noe, samtidig som man forkaster alt som er mindre og ubetydelig. Ingen grunn til å finne opp hjulet på nytt. La oss huske et eksempel fra en gammel leksjon om klasser. Anta at vi lager et arkivsystem for ansatte i selskapet. For å lage "medarbeider"-objekter har vi skrevet en medarbeiderklasse . Hvilke egenskaper er viktige for å beskrive dem i selskapets arkivsystem? Navn, fødselsdato, SSN og ansatt-ID. Men det er usannsynlig at vi trenger den ansattes høyde, øyenfarge eller hårfarge for denne typen registrering. Selskapet har ikke behov for slike opplysninger om en ansatt. Så i Employee- klassen erklærer vi følgende variabler:, int alder , int socialSecurityNumber og int ansatt - ID . Og vi abstraherer bort unødvendig informasjon som øyenfarge. Men hvis vi lager et arkivsystem for et modellbyrå, endrer situasjonen seg dramatisk. En modells høyde, øyenfarge og hårfarge er viktige egenskaper, men hennes SSN er absolutt irrelevant for oss. Så i Model- klassen lager vi følgende variabler: String height , String hair , String eyes .

Prinsipp 3. Innkapsling

Vi har allerede vært borti dette. I Java betyr innkapsling å begrense muligheten til å lese og endre data. Som du kan se, er begrepet basert på ordet "kapsel". Vi bruker en "kapsel" for å skjule noen viktige data som vi ikke vil at andre skal endre. Her er et enkelt eksempel fra det virkelige liv. Du har et fornavn og et etternavn. Alle vennene dine kjenner dem. Men de har ikke muligheten til å endre for- eller etternavnet ditt. Vi kan si at prosessen for å gjøre det er "innkapslet" av rettssystemet: du kan endre etternavnet ditt bare gjennom rettssekretæren, og bare du kan gjøre det. Andre "brukere" har "skrivebeskyttet" tilgang til for- og etternavnet ditt :) Et annet illustrerende eksempel er kontanter som holdes hjemme. Det er ikke en god idé å la den være synlig i midten av rommet ditt. Enhver "bruker" (person som kommer hjem til deg) vil kunne endre beløpet på pengene dine, dvs. de kan ta pengene dine. Det ville være bedre å kapsle det inn i en safe. Da vil tilgang kun være tilgjengelig for deg og kun ved å bruke en spesiell kode. Åpenbare eksempler på innkapsling som du allerede har jobbet med er tilgangsmodifikatorer (private, offentlige, etc.), samt settere og gettere. Hvis du ikke kapsler innKatteklassens aldersfelt , så kan hvem som helst skrive :

Cat.age = -1000;

Innkapslingsmekanismen lar oss beskytte aldersfeltet med en settermetode, hvor vi kan sikre at alder ikke kan settes til et negativt tall.

Prinsipp 4. Polymorfisme

Polymorfisme er evnen til å jobbe med flere typer som om de var samme type. Dessuten vil gjenstandenes oppførsel være forskjellig avhengig av type. Høres det komplisert ut? La oss forstå det akkurat nå. Ta det enkleste eksempelet: dyr. Opprett en Animal- klasse med en enkelt speak()- metode og to underklasser - Cat and Dog .

public class Animal {

   public void speak() {
      
       System.out.println("Hello!");
   }
}

public class Dog extends Animal {
  
   @Override
   public void speak() {
       System.out.println ("Woof-woof!");
   }
}

public class Cat extends Animal {

   @Override
   public void speak() {
       System.out.println("Meow!");
   }
}

Nå skal vi prøve å erklære en dyrereferansevariabel og tilordne et hundeobjekt til den.

public class Main {

   public static void main(String[] args) {

       Animal dog = new Dog();
       dog.speak();
   }
}

Hvilken metode tror du vil bli kalt? Animal.speak() eller Dog.speak() ? Metoden i Hundeklassen vil hete: Woof-woof! Vi opprettet en dyrereferanse , men objektet oppfører seg som en hund . Om nødvendig kan den oppføre seg som en katt, hest eller et annet dyr. Det viktige er å tilordne en spesifikk underklasse til den generelle dyrereferansevariabelen . Dette er fornuftig, fordi alle hunder er dyr. Det var det vi hadde i tankene da vi sa "objektenes oppførsel vil være forskjellig avhengig av deres type." Hvis vi opprettet et Cat- objekt...

public static void main(String[] args) {

   Animal cat = new Cat();
   cat.speak();
}

speak ()- metoden ville vise "Mjau!" Men hva mener vi med 'evnen til å jobbe med flere typer som om de var samme type'? Dette er også ganske enkelt. La oss forestille oss at vi lager en frisørsalong for dyr. Frisøren vår skal kunne gi ethvert dyr en trim, så vi lager en trim()- metode med en Animal- parameter (dyret som blir klippet).

public class AnimalBarbershop {

   public void trim(Animal animal) {

       System.out.println("The haircut is done!"); 
   }
}

Og nå kan vi sende Cat and Dog -objekter til trim() -metoden!

public static void main(String[] args) {

   Cat cat = new Cat();
   Dog dog = new Dog();

   AnimalBarbershop barbershop = new AnimalBarbershop();

   barbershop.trim(cat);
   barbershop.trim(dog);
}

Og her er det klare eksempelet: AnimalBarbershop- klassen jobber med katt- og hund -typene som om de var samme type. Samtidig har katt og hund forskjellig oppførsel: de snakker forskjellig.

Hvorfor trenger vi OOP?

Hvorfor oppsto OOP noen gang som et nytt programmeringskonsept? Programmerere hadde fungerende verktøy, for eksempel prosedyrespråk. Hva fikk dem til å finne på noe fundamentalt nytt? Fremfor alt kompleksiteten til oppgavene de sto overfor. Hvis programmererens oppgave for 60 år siden var noe sånt som "vurdere et matematisk uttrykk", kunne det nå være noe sånt som "implementer 7 forskjellige avslutninger for spillet STALKER, avhengig av kombinasjoner av spillerens avgjørelser tatt på punktene A, B, C, DE , og F i spillet." Som du kan se, har oppgavene åpenbart blitt mer kompliserte de siste tiårene. Og som et resultat har datatypene blitt mer kompliserte. Dette er en annen grunn til at OOP dukket opp. Et matematisk uttrykk kan enkelt evalueres ved å bruke vanlige primitiver. Her trengs ingen gjenstander. Men oppgaven med spillavslutningene ville være vanskelig å beskrive uten å bruke egendefinerte klasser. Når det er sagt, er det ganske enkelt å beskrive det ved hjelp av klasser og objekter. Selvfølgelig trenger vi flere klasser: Game, Stalker, Ending, PlayerDecision, GameEvent, og så videre. Med andre ord, selv uten å begynne å løse problemet, kan vi enkelt "skissere" en løsning i hodet. Den økende kompleksiteten til oppgavene tvang programmerere til å dele dem inn i deler. Men dette var ikke så lett å gjøre i prosedyreprogrammering. Og ganske ofte var et program som et tre med mange grener som representerte alle mulige utførelsesveier. Avhengig av visse forhold ble en eller annen gren av programmet utført. For små programmer var dette praktisk, men det var veldig vanskelig å dele opp et stort problem i deler. Dette var nok en grunn til fremveksten av OOP. Dette paradigmet ga programmerere muligheten til å dele et program inn i en haug med "moduler" (klasser), som hver gjør sin egen del av arbeidet. Ved å samhandle med hverandre, utfører alle objektene arbeidet med programmet vårt. I tillegg kan vi gjenbruke koden vår andre steder i programmet, noe som også sparer mye tid.