OOP alapelvek

Szia! A mai leckében az objektum-orientált programozás alapelveiről fogunk beszélni. Gondolkozott már azon, hogy a Java miért pont úgy van megtervezve, ahogy van? Úgy értem, osztályokat deklarálsz és objektumokat hozol létre osztályok alapján, az osztályoknak vannak metódusai stb. De miért van a nyelv úgy felépített, hogy a programok osztályokból és objektumokból álljanak, és ne valami másból? Miért találták ki és helyezték előtérbe a „tárgy” fogalmát? Minden nyelvet így terveztek? Ha nem, milyen előnyökkel jár a Java számára? Amint látod, rengeteg kérdés van :) Próbáljuk meg mindegyikre válaszolni a mai órán.

Mi az objektum-orientált programozás (OOP)?

Természetesen a Java nem csak szórakozásból épül fel objektumokból és osztályokból. Nem a Java alkotóinak szeszélyei, és még csak nem is az ő találmányuk. Sok más nyelv is létezik, amelyek objektumokon alapulnak. Az első ilyen nyelvet "Simula"-nak hívták. Még az 1960-as években találták fel Norvégiában. Ráadásul a Simulában megjelent az „osztály” és a „módszer” fogalma. A szoftverfejlesztés szabványai szerint a "Simula" ősi nyelvnek tűnik, de bárki láthatja "családi hasonlóságát" a Java-val. Valószínűleg könnyen elolvashatja az ezen a nyelven írt kódot, és nagy vonalakban elmagyarázhatja, hogy mit csinál :)

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;

Ezt a kódminta kódot a Weekly-geekly "Simula - 50 years of OOP" című könyvéből vette. Mint látható, a Java nem sokban különbözik a nagyapjától :) Ez annak köszönhető, hogy a Simula megjelenése egy új koncepció születését jelentette: az objektum-orientált programozást. A Wikipédia így definiálja az OOP-t: "Az objektum-orientált programozás (OOP) egy programozási paradigma, amely az "objektumok" fogalmán alapul, amely adatokat tartalmazhat mezők (gyakran attribútumokként) és kódot formában. eljárások (gyakran módszerekként ismertek). Véleményem szerint ez egy nagyon jó meghatározás. Nem is olyan régen kezdtél tanulni Java-t, de ez a definíció valószínűleg nem tartalmaz olyan szavakat, amelyeket nem ismersz :) Ma az OOP a legelterjedtebb programozási módszertan. A Java mellett Az OOP-elveket sok népszerű nyelven használják, amelyekről már hallott. Például C++ (aktívan használják a játékfejlesztésben), Objective-C és Swift (programokat írnak Apple eszközökre), Python (a gépi tanulásban a legnépszerűbb), PHP (az egyik legnépszerűbb webfejlesztő nyelv), JavaScript ( könnyebb megmondani, mire nem használják) és még sokan mások. Tehát mik az OOP alapelvei? Elmondjuk részletesen. egyáltalán mik az OOP elvei? Elmondjuk részletesen. egyáltalán mik az OOP elvei? Elmondjuk részletesen.

OOP alapelvek

Ezek képezik az alapítvány alapjait. A 4 fő jellemző, amelyek együtt alkotják az objektum-orientált programozási paradigmát. Megértésük elengedhetetlen ahhoz, hogy sikeres programozóvá váljunk.

1. alapelv. Öröklődés

Jó hír: már ismeri az OOP néhány alapelvét! :) Öröklődéssel már találkoztunk párszor az órákon, és sikerült is használni. Az öröklődés egy olyan mechanizmus, amely lehetővé teszi egy új osztály leírását egy meglévő (szülő) osztály alapján. Ennek során az új osztály kölcsönveszi a szülőosztály tulajdonságait és funkcióit. Mire való az öröklés és milyen előnyökkel jár? Mindenekelőtt a kód újrafelhasználása. A szülő osztályokban deklarált mezők és metódusok a leszármazott osztályokban használhatók. Ha minden típusú autónak 10 közös mezője és 5 azonos metódusa van, csak át kell helyeznie őket az Auto- ba.szülői osztály. A leszármazott osztályokban gond nélkül használhatod őket. Szilárd előnyök: mind mennyiségi (kevesebb kód), mind ennek eredményeként minőségi (az osztályok sokkal egyszerűbbé válnak). Ezenkívül az öröklődés nagyon rugalmas – külön írási funkciókat is hozzáadhat, amelyek hiányoznak a leszármazottakból (néhány mező vagy viselkedés, amelyek egy adott osztályra jellemzőek). Általában, mint a való életben, valamennyien hasonlítunk a szüleinkre, de valamiben különbözünk is tőlük :)

2. elv. Absztrakció

Ez egy nagyon egyszerű elv. Az absztrakció azt jelenti, hogy azonosítjuk valaminek a fő, legjelentősebb jellemzőit, miközben egyidejűleg elvetünk minden kisebbet és jelentéktelent. Nem kell újra feltalálni a kereket. Idézzünk fel egy példát egy régi leckéből az órákról. Tegyük fel, hogy egy nyilvántartási rendszert hozunk létre a vállalati alkalmazottak számára. Az "alkalmazotti" objektumok létrehozásához írtunk egy alkalmazott osztályt. Milyen jellemzők fontosak ezek leírásához a cégnyilvántartási rendszerben? Név, születési dátum, SSN és alkalmazotti azonosító. De nem valószínű, hogy szükségünk lesz az alkalmazott magasságára, szemszínére vagy hajszínére az ilyen típusú rekordokhoz. A cégnek nincs szüksége ilyen információkra egy alkalmazottról. Tehát az Employee osztályban a következő változókat deklaráljuk:, int age , int socialSecurityNumber és int workerId . És elvonatkoztatjuk a felesleges információkat, például a szemszínt. Ha azonban egy modellügynökség számára készítünk nyilvántartási rendszert, a helyzet drámaian megváltozik. A modell magassága, szemszíne és hajszíne fontos jellemzők, de az SSN-je számunkra teljesen irreleváns. Tehát a Model osztályban a következő változókat hozzuk létre: String height , String hair , String eyes .

3. alapelv. Kapszulázás

Ebbe már belefutottunk. A Java nyelven a beágyazás az adatok olvasásának és módosításának korlátozását jelenti. Mint látható, a kifejezés a "kapszula" szón alapul. Egy „kapszulát” használunk, hogy elrejtsünk néhány fontos adatot, amelyeket nem akarunk, hogy mások megváltoztassák. Íme egy egyszerű példa a való életből. Van kereszt- és vezetékneved. Minden barátod ismeri őket. De nem tudják megváltoztatni a vezeték- vagy keresztnevét. Mondhatnánk, hogy ennek folyamatát a bírósági rendszer „befogja”: vezetéknevét csak a bírósági titkáron keresztül változtathatja meg, és azt csak Ön teheti meg. Más "felhasználók" "csak olvasási" hozzáféréssel rendelkeznek az Ön kereszt- és vezetéknevéhez :) Egy másik szemléltető példa az otthon tartott készpénz. Nem jó ötlet jól látható helyen hagyni a szoba közepén. Bármelyik "felhasználó" (az a személy, aki a házához jön) megváltoztathatja a pénze összegét, azaz elviheti a pénzét. Jobb lenne egy széfbe kapszulázni. Ekkor a hozzáférés csak Ön számára lenne elérhető, és csak egy speciális kód használatával. Nyilvánvaló példák a beágyazásra, amellyel már dolgozott: hozzáférésmódosítók (privát, nyilvános stb.), valamint beállítók és getterek. Ha nem kapszulázod be aMacskaosztály korosztálya , akkor bárki írhat :

Cat.age = -1000;

A beágyazási mechanizmus lehetővé teszi, hogy az életkor mezőt setter módszerrel védjük , ahol biztosíthatjuk, hogy az életkor ne állítható be negatív számra.

4. alapelv. Polimorfizmus

A polimorfizmus az a képesség, hogy több típussal úgy dolgozunk, mintha ugyanazok lennének. Ezenkívül az objektumok viselkedése típusuktól függően eltérő lesz. Ez bonyolultan hangzik? Most azonnal értelmezzük. Vegyük a legegyszerűbb példát: állatok. Hozzon létre egy Animal osztályt egyetlen speak() metódussal és két alosztállyal – Cat és 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!");
   }
}

Most megpróbálunk deklarálni egy Animal referenciaváltozót, és hozzárendelni egy Dog objektumot.

public class Main {

   public static void main(String[] args) {

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

Szerinted milyen módszer lesz a neve? Animal.speak() vagy Dog.speak() ? A Kutya osztály metódusának neve: Hú-jaj! Létrehoztunk egy állati hivatkozást, de az objektum úgy viselkedik, mint egy kutya . Ha szükséges, úgy viselkedhet, mint egy macska, ló vagy más állat. Az a fontos, hogy az általános Animal referenciaváltozóhoz egy adott alosztályt rendeljünk . Ez logikus, mert minden kutya állat. Erre gondoltunk, amikor azt mondtuk, hogy „az objektumok viselkedése típusuktól függően eltérő lesz”. Ha létrehoztunk egy Cat objektumot...

public static void main(String[] args) {

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

a speak() metódus a "Miau!" De mit értünk azon, hogy „több típussal dolgozhatunk úgy, mintha ugyanazok lennének”? Ez is elég egyértelmű. Képzeljük el, hogy fodrászatot hozunk létre állatok számára. Fodrászatunknak képesnek kell lennie bármely állatnak a levágására, ezért létrehozunk egy trim() metódust egy Animal paraméterrel (az állatot levágják).

public class AnimalBarbershop {

   public void trim(Animal animal) {

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

És most átadhatjuk a macska és kutya objektumokat a trim() metódusnak!

public static void main(String[] args) {

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

   AnimalBarbershop barbershop = new AnimalBarbershop();

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

És itt a világos példa: az AnimalBarbershop osztály úgy működik a macska és kutya típusokkal, mintha ugyanazok lennének. Ugyanakkor a macska és a kutya viselkedése eltérő: mindegyik másképp beszél.

Miért van szükségünk OOP-ra?

Miért merült fel az OOP új programozási koncepcióként? A programozók rendelkeztek működő eszközökkel, például eljárási nyelvekkel. Mi késztette őket arra, hogy valami alapvetően újat találjanak ki? Mindenekelőtt az előttük álló feladatok összetettsége. Ha 60 évvel ezelőtt a programozó feladata valami olyasmi volt, hogy „kiértékel egy matematikai kifejezést”, akkor most olyasmi lehetett, hogy „valósítson meg 7 különböző befejezést a STALKER játékhoz, a játékos A, B, C, DE pontokban hozott döntéseinek kombinációitól függően. , és F a játékban." Mint látható, a feladatok nyilvánvalóan bonyolultabbá váltak az elmúlt évtizedekben. Ennek eredményeként az adattípusok bonyolultabbá váltak. Ez egy másik oka annak, hogy az OOP megjelent. Egy matematikai kifejezés könnyen kiértékelhető közönséges primitívekkel. Itt nincs szükség tárgyakra. De a feladatot a játék végével nehéz lenne leírni egyéni osztályok használata nélkül. Ennek ellenére meglehetősen könnyű leírni osztályok és objektumok segítségével. Nyilvánvalóan több osztályra lesz szükségünk: Game, Stalker, Ending, PlayerDecision, GameEvent és így tovább. Vagyis a probléma megoldásának megkezdése nélkül is könnyen "felvázolhatunk" egy megoldást a fejünkben. A feladatok egyre bonyolultabbá válása arra késztette a programozókat, hogy részekre bontsák azokat. De ezt nem volt olyan könnyű megtenni a procedurális programozásban. És gyakran egy program olyan volt, mint egy fa, amelynek sok ága az összes lehetséges végrehajtási útvonalat reprezentálja. Bizonyos feltételektől függően a program egyik vagy másik ága végrehajtódott. Kisebb programoknál ez kényelmes volt, de nagyon nehéz volt egy nagy problémát részekre osztani. Ez egy újabb oka volt az OOP megjelenésének. Ez a paradigma lehetővé tette a programozóknak, hogy egy programot egy csomó "modulra" (osztályra) osszanak, amelyek mindegyike elvégzi a munka saját részét. Egymással kölcsönhatásba lépve az összes objektum elvégzi programunk munkáját. Emellett a programban máshol is újra felhasználhatjuk a kódunkat, ami szintén sok időt takarít meg.