OOP principper

Hej! I dagens lektion vil vi tale om principper for objektorienteret programmering. Har du nogensinde undret dig over, hvorfor Java er designet præcis, som det er? Jeg mener, man erklærer klasser og laver objekter ud fra klasser, klasser har metoder osv. Men hvorfor er sproget struktureret, så programmer består af klasser og objekter, og ikke noget andet? Hvorfor blev begrebet "objekt" opfundet og sat på spidsen? Er alle sprog designet på denne måde? Hvis ikke, hvilke fordele giver det Java? Som du kan se, er der mange spørgsmål :) Lad os prøve at besvare hver af dem i dagens lektion.

Hvad er objektorienteret programmering (OOP)?

Selvfølgelig består Java ikke af objekter og klasser kun for sjov. De er ikke et indfald af Javas skabere, og ikke engang deres opfindelse. Der er mange andre sprog baseret på objekter. Det første sådan sprog blev kaldt "Simula". Den blev opfundet tilbage i 1960'erne i Norge. Hvad mere er, begreberne "klasse" og "metode" dukkede op i Simula. Efter standarderne for softwareudvikling virker "Simula" som et gammelt sprog, men enhver kan se dets "familielighed" med Java. Du kan sikkert sagtens læse koden skrevet på dette sprog og forklare i store træk, hvad den gø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 kodeeksempelkode blev taget fra "Simula - 50 years of OOP" af Weekly-geekly. Som du kan se, er Java ikke så meget forskellig fra sin bedstefar :) Dette skyldes det faktum, at Simulas udseende markerede fødslen af ​​et nyt koncept: objektorienteret programmering. Wikipedia definerer OOP således: "Object-Oriented Programming (OOP) er et programmeringsparadigme baseret på begrebet "objekter", som kan indeholde data i form af felter (ofte kendt som attributter) og kode i formen af procedurer (ofte kendt som metoder)." Efter min mening er dette en rigtig god definition. Det er ikke længe siden, du begyndte at lære Java, men denne definition indeholder sandsynligvis ingen ord, du ikke kender :) I dag er OOP den mest almindelige programmeringsmetode. Ud over Java, OOP-principper bruges på mange populære sprog, som du måske har hørt om. For eksempel C++ (aktivt brugt i spiludvikling), Objective-C og Swift (bruges til at skrive programmer til Apple-enheder), Python (mest populær i maskinlæring), PHP (et af de mest populære webudviklingssprog), JavaScript ( det er nemmere at sige, hvad det ikke bruges til) og mange andre. Så hvad er principperne for OOP alligevel? Vi fortæller dig i detaljer. hvad er principperne for OOP alligevel? Vi fortæller dig i detaljer. hvad er principperne for OOP alligevel? Vi fortæller dig i detaljer.

OOP principper

Disse er grundlaget for fonden. De 4 hovedtræk, der tilsammen danner det objektorienterede programmeringsparadigme. At forstå dem er afgørende for at blive en succesfuld programmør.

Princip 1. Arv

Gode ​​nyheder: du kender allerede nogle af principperne i OOP! :) Vi har allerede stødt på arv et par gange i undervisningen, og det lykkedes os at bruge det. Arv er en mekanisme, der lader dig beskrive en ny klasse baseret på en eksisterende (overordnet) klasse. Derved låner den nye klasse egenskaberne og funktionaliteten af ​​den overordnede klasse. Hvad er arv til for, og hvilke fordele giver det? Frem for alt genbrug af kode. De felter og metoder, der er erklæret i overordnede klasser, kan bruges i efterkommerklasser. Hvis alle typer biler har 10 fælles felter og 5 identiske metoder, skal du blot flytte dem ind i Autoforældreklasse. Du kan bruge dem i efterkommerklasser uden problemer. Solide fordele: både kvantitativ (mindre kode) og som et resultat kvalitativ (klasser bliver meget enklere). Desuden er arv meget fleksibelt - du kan tilføje skrive separat funktionalitet, som efterkommerne mangler (nogle felter eller adfærd, der er specifik for en bestemt klasse). Generelt, som i det virkelige liv, ligner vi alle vores forældre, men også på en eller anden måde forskellige fra dem :)

Princip 2. Abstraktion

Dette er et meget simpelt princip. Abstraktion betyder at identificere de vigtigste, mest betydningsfulde egenskaber ved noget, samtidig med at man kasserer noget mindre og ubetydeligt. Ingen grund til at genopfinde hjulet. Lad os huske et eksempel fra en gammel lektion om klasser. Antag, at vi opretter et arkiveringssystem for virksomhedens ansatte. For at oprette "medarbejder"-objekter har vi skrevet en medarbejderklasse . Hvilke egenskaber er vigtige for at beskrive dem i virksomhedens arkiveringssystem? Navn, fødselsdato, SSN og medarbejder-id. Men det er usandsynligt, at vi får brug for medarbejderens højde, øjenfarve eller hårfarve til denne type registrering. Virksomheden har ikke behov for sådanne oplysninger om en medarbejder. Så i Employee- klassen erklærer vi følgende variabler:, int alder , int socialSecurityNumber og int medarbejderId . Og vi abstraherer unødvendig information som øjenfarve. Men hvis vi laver et arkiveringssystem for et modelbureau, ændrer situationen sig dramatisk. En models højde, øjenfarve og hårfarve er vigtige egenskaber, men hendes SSN er absolut irrelevant for os. Så i Model- klassen opretter vi følgende variabler: Stringhøjde , Stringhår , Stringøjne .

Princip 3. Indkapsling

Vi er allerede stødt på det her. I Java betyder indkapsling at begrænse muligheden for at læse og ændre data. Som du kan se, er udtrykket baseret på ordet "kapsel". Vi bruger en "kapsel" til at skjule nogle vigtige data, som vi ikke ønsker, at andre skal ændre. Her er et simpelt eksempel fra det virkelige liv. Du har et fornavn og et efternavn. Alle dine venner kender dem. Men de har ikke mulighed for at ændre dit for- eller efternavn. Vi kan sige, at processen for at gøre det er "indkapslet" af retssystemet: du kan kun ændre dit efternavn gennem retssekretæren, og det er kun dig, der kan gøre det. Andre "brugere" har "skrivebeskyttet" adgang til dit for- og efternavn :) Et andet illustrativt eksempel er kontanter, der opbevares hjemme. Det er ikke en god idé at efterlade den i almindeligt syn midt i dit værelse. Enhver "bruger" (person, der kommer til dit hus) vil være i stand til at ændre beløbet på dine penge, dvs. de kan tage dine penge. Det ville være bedre at indkapsle det i et pengeskab. Så ville adgang kun være tilgængelig for dig og kun ved at bruge en speciel kode. Indlysende eksempler på indkapsling, som du allerede har arbejdet med, er adgangsmodifikatorer (private, offentlige osv.), samt sættere og getters. Hvis du ikke indkapslerKatteklassens aldersfelt , så kan enhver skrive :

Cat.age = -1000;

Indkapslingsmekanismen lader os beskytte aldersfeltet med en sættermetode, hvor vi kan sikre, at alder ikke kan sættes til et negativt tal.

Princip 4. Polymorfi

Polymorfi er evnen til at arbejde med flere typer, som om de var den samme type. Desuden vil objekternes adfærd være forskellig afhængig af deres type. Lyder det kompliceret? Lad os finde ud af det lige nu. Tag det enkleste eksempel: dyr. Opret en Animal- klasse med en enkelt speak()- metode og to underklasser - Cat og 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!");
   }
}

Nu vil vi prøve at erklære en dyrereferencevariabel og tildele den et hundeobjekt .

public class Main {

   public static void main(String[] args) {

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

Hvilken metode tror du vil blive kaldt? Animal.speak() eller Dog.speak() ? Metoden i Hundeklassen kommer til at hedde: Woof-woof! Vi oprettede en dyrereference , men objektet opfører sig som en hund . Hvis det er nødvendigt, kan det opføre sig som en kat, hest eller et andet dyr. Det vigtige er at tildele en specifik underklasse til den generelle dyrereferencevariabel . Det giver mening, for alle hunde er dyr. Det var det, vi havde i tankerne, da vi sagde "objekternes adfærd vil være forskellig afhængig af deres type." Hvis vi oprettede et Cat- objekt...

public static void main(String[] args) {

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

speak ()- metoden ville vise "Mjau!" Men hvad mener vi med 'evnen til at arbejde med flere typer, som om de var den samme type'? Dette er også ret ligetil. Lad os forestille os, at vi laver en barbershop for dyr. Vores barbershop burde kunne give ethvert dyr en trim, så vi laver en trim() metode med en Animal parameter (dyret der bliver klippet).

public class AnimalBarbershop {

   public void trim(Animal animal) {

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

Og nu kan vi videregive 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 eksempel: AnimalBarbershop- klassen arbejder med Cat- og Dog -typerne, som om de var den samme type. Samtidig har kat og hund forskellig adfærd: de taler hver især forskelligt.

Hvorfor har vi brug for OOP?

Hvorfor opstod OOP nogensinde som et nyt programmeringskoncept? Programmører havde fungerende værktøjer, såsom proceduresprog. Hvad fik dem til at opfinde noget grundlæggende nyt? Frem for alt kompleksiteten af ​​de opgaver, de stod over for. Hvis programmørens opgave for 60 år siden var noget i retning af "vurder et matematisk udtryk", kunne det nu være noget i retning af "implementer 7 forskellige slutninger for spillet STALKER, afhængigt af kombinationer af spillerens beslutninger truffet ved punkt A, B, C, DE , og F i spillet." Som du kan se, er opgaverne åbenbart blevet mere komplicerede i løbet af de seneste årtier. Og som følge heraf er datatyperne blevet mere komplicerede. Dette er endnu en grund til, at OOP dukkede op. Et matematisk udtryk kan nemt evalueres ved hjælp af almindelige primitiver. Her behøves ingen genstande. Men opgaven med spilafslutningerne ville være svær overhovedet at beskrive uden at bruge brugerdefinerede klasser. Når det er sagt, er det ret nemt at beskrive det ved hjælp af klasser og objekter. Vi har naturligvis brug for flere klasser: Game, Stalker, Ending, PlayerDecision, GameEvent, og så videre. Med andre ord, selv uden at begynde at løse problemet, kan vi sagtens "skitsere" en løsning i hovedet. Den stigende kompleksitet af opgaverne tvang programmører til at opdele dem i dele. Men dette var ikke så let at gøre i proceduremæssig programmering. Og ganske ofte var et program som et træ med masser af grene, der repræsenterede alle mulige udførelsesveje. Afhængigt af visse betingelser blev en eller anden gren af ​​programmet udført. For små programmer var dette praktisk, men det var meget svært at opdele et stort problem i dele. Dette var endnu en grund til fremkomsten af ​​OOP. Dette paradigme gav programmører muligheden for at opdele et program i en flok "moduler" (klasser), som hver udfører sin egen del af arbejdet. Ved at interagere med hinanden udfører alle objekterne arbejdet i vores program. Derudover kan vi genbruge vores kode andre steder i programmet, hvilket også sparer en masse tid.