Beágyazás, öröklődés, polimorfizmus (PHP alapismeretek - Tanfolyam lecke). Az objektum-orientált programozás alapjai Polimorfizmus Példák

A JAVA az objektum-orientált programozás koncepcióján alapul, amely lehetővé teszi, hogy magasabb absztrakciós szintre léphessen, hogy bármilyen problémát reálisan megoldjon. Az objektum-orientált megközelítés a probléma megoldását valós objektumok formájában képzeli el, amelyeket könnyebb újra felhasználni egy alkalmazásban. Például: Szék (szék), ventilátor (ventilátor), kutya (kutya), számítógép (számítógép) és így tovább. A JAVA-ban az osztály egy elrendezés, sablon vagy prototípus, amely egy adott típusú objektum általános viselkedését határozza meg. A példány egy osztály különálló implementációja, és egy osztály minden példányának ugyanazok a tulajdonságai vannak, amelyek az osztálydefinícióban vannak leírva. Például megadhat egy House nevű osztályt szobák számával attribútumként, és létrehozhat az osztály példányait, például kétszobás házat, háromszobás házat stb. Előnyök: Az alábbiakban felsorolunk néhány előnyt az objektum-orientált szoftverfejlesztésből.

• Csökkentett szoftvertámogatási költségek, főként annak a ténynek köszönhetően, hogy modulárisan történik.
• Továbbfejlesztett kód-újrafelhasználás olyan funkciók révén, mint például az öröklődés, ami gyorsabb szoftverfejlesztést eredményez.
• Megnövelt kódmegbízhatóság és rugalmasság.
• Könnyű megértés a valós szimulációnak köszönhetően.
• Jobb absztrakció az objektum szintjén.
• Az egyik fejlesztési fázisból a másikba való átmenet bonyolultságának csökkentése.

• Kapszulázás
• Öröklés
• Polimorfizmus
• Absztrakció

Kapszulázás

• Egy objektum belső állapotát az attribútumok elrejtésével tudjuk megvédeni.
• Ez javítja a kódmodularitást, mivel megakadályozza, hogy az objektumok váratlan módon kölcsönhatásba lépjenek.
• Javítja a kód használhatóságát.
• Ez egy adott entitás szerződéses kapcsolatát támogatja.
• A beágyazás megkönnyíti a szoftver karbantartását.
• A kód megváltoztatása egymástól függetlenül is elvégezhető.

Polimorfizmus

• Újrafelhasználható kód létrehozása. Vagyis ha egy osztályt létrehoztunk, implementáltunk és teszteltünk, akkor szabadon használható anélkül, hogy aggódnánk, hogy pontosan mi van benne.
• Ez általánosabb és lazábban csatolt kódot tesz lehetővé.
• A fordítási idő csökken, ami felgyorsítja a fejlesztést.
• Dinamikus összekapcsolás.
• Ugyanaz a felület használható különböző megvalósítású metódusok létrehozására.
• A teljes megvalósítás helyettesíthető ugyanazon metódus aláírások használatával.

Öröklés

• Továbbfejlesztett kód-újrafelhasználás.
• Létrejön az „is a” (van valaki, valami) logikai kapcsolat. Például: Kutya az a n állati. (A kutya az állat).
• Kód modularizálás.
• Az ismétlések kizárva.

• Erős kapcsolás: egy alosztály egy szülő osztály megvalósításától függ, így a kód erősen csatolt.

Absztrakció

• Az absztrakció használatával elkülöníthetjük, hogy mi csoportosítható valamilyen típusba.
• A gyakran módosított tulajdonságok és metódusok külön típusba csoportosíthatók, így a fő típus nem változik. Ez megerősíti az OOP elvét: „A kódnak nyitva kell lennie a bővítményhez, de zárva kell lennie a módosításhoz”.
• Az absztrakció leegyszerűsíti a tartománymodellek ábrázolását.

1. Többszörös öröklés.
2. Laza tengelykapcsoló. A műveletnek van egy absztrakciója, például rétegezés, és a konkrét megvalósítás bármi lehet: JDBC, JPA, JTA stb.
3. Az interfész program nincs implementálva.
4. Polimorfizmus dinamikus kötéssel: Kibővíti egy objektum programozási felületét anélkül, hogy feltárná a tényleges megvalósítását.
5. Absztrakt szintek, a funkcionalitás szétválasztása.

• Az interfész szerződéses kapcsolat az ezt az interfészt megvalósító osztályokkal, amely kimondja, hogy a megvalósítás az interfész által meghatározott módon történik. Ez egy üres shell deklarált metódusokkal.
• Egy absztrakt osztály definiál néhány általános viselkedést, és megkéri alosztályait, hogy határozzák meg az osztályuk atipikus vagy specifikus viselkedését.
• Egy absztrakt osztály metódusait és tagjait felváltva bármilyen hozzáférés-módosítóval kijelölhetjük, minden interfész metódusnak nyilvánosnak kell lennie.
• Absztrakt osztály öröklésekor a leszármazott osztálynak absztrakt metódusokat kell definiálnia, míg egy interfész örökölhet egy másik interfészt anélkül, hogy feltétlenül meghatározná a metódusait.
• Egy leszármazott osztály csak egy absztrakt osztályt terjeszthet ki, de egy interfész kiterjeszthet vagy egy osztály sok más interfészt is megvalósíthat.
• Egy leszármazott osztály definiálhat absztrakt metódusokat ugyanazzal vagy kevésbé korlátozó hozzáférés-módosítóval, de az interfészt megvalósító osztálynak azonos láthatósági szintű metódusokat kell meghatároznia.
• Egy interfész nem tartalmaz konstruktorokat, míg az absztrakt osztály igen.
• A Java felületen deklarált változók alapértelmezés szerint véglegesek. Egy absztrakt osztály tartalmazhat olyan változókat, amelyek nem véglegesek.
• A Java felület összes tagja alapértelmezés szerint nyilvános. Egy absztrakt osztály tagjai megengedhetik maguknak, hogy nyilvánosak, védettek stb.

Összetétel

• Láthatóság szabályozás
• A megvalósítás futás közben cserélhető
• Laza csatolás, mivel az interfész osztály nem függ a megvalósítástól.

A polimorfizmus egy OOP-elv, amely lehetővé teszi egy interfész és különböző algoritmusok használatát. A polimorfizmus célja az OOP-val kapcsolatban, hogy egy nevet használjon különböző műveletek megadására. A művelet végrehajtását az adattípus határozza meg.

A polimorfizmus típusai:

Statikus (a fordítási időben meghatározva). Funkciók, módszerek, operátorok, stb. túlterhelése.

Dinamikus (futási időben meghatározva). Virtuális függvényeket és metódusokat tartalmaz.

22. Az öröklődés, mint a polimorfizmus megvalósításának és az osztályhierarchiák létrehozásának mechanizmusa. Az öröklődés típusai.

Az öröklődés egy OOP-mechanizmus, amelyen keresztül új osztályok jönnek létre a meglévők alapján. Ezek az osztályok öröklik az alaposztályok tulajdonságait és viselkedését, és újakat szerezhetnek. Ez lehetővé teszi a program méretének és a fejlesztési idő csökkentését. A polimorfizmus lehetővé teszi, hogy programokat írjunk a logikailag kapcsolódó osztályok széles skálájának kezelésére. Az öröklődés és a polimorfizmus hatékony technikák komplex programok fejlesztésére.

Az öröklődés típusai: közvetlen és közvetett, egyszerű és többszörös.

23. Osztályok. Alapvető, származtatott, polimorf, absztrakt, virtuális. Példák.

Az osztály egy speciális adattípus, amely leírja az adatattribútumokat és az attribútumokon végrehajtott műveleteket.

Az alaposztály olyan osztály, amelynek tagjai öröklődnek.

A származtatott osztály olyan osztály, amely más tagokat örököl.

A polimorf osztály egy virtuális metódusokat tartalmazó osztály.

Az absztrakt osztály tisztán virtuális metódusokat tartalmazó osztály.

A virtuális osztály olyan osztály, amely a többszörös öröklődés során nem kerül be a leszármazott osztályok közé, hanem azokban hivatkozással helyettesíti, a párhuzamosság elkerülése érdekében.

24. A korai és késői kötés elvei.

A kötés a programkódban használt azonosító és annak fizikai objektuma (általában bármely szoftverkomponens: változó, eljárás, modul, alkalmazás stb.) közötti kapcsolat létrehozásának eljárása.

A korai kötés az ilyen kapcsolatok létrehozása a program végrehajtása előtt. Ez általában azt jelenti, hogy a fordítási folyamat során össze kell kapcsolni a forrásmodulokat és a végrehajtható modulokat az objektummoduloktól.

A késői kötés a kapcsolatok létrehozása a program végrehajtása során. Általában vagy dinamikus kapcsolatokról beszélünk (amikor csak az alkalmazás működése során határozzák meg, hogy mely objektumokra lesz szükség), vagy az ilyen objektumok működés közbeni kialakításáról.

25. UML használata a specifikációhoz

26. Osztályhierarchiák leírása uml diagramokkal.

Osztálykapcsolatok  révén. És mutasson meg különböző kapcsolatokat: közvetlen, közvetett, többszörös.

27. Sablon osztályok. Leírás uml-ben.

Az osztálysablon egy C++ nyelvi eszköz, amelyet általánosított osztályalgoritmusok kódolására terveztek, bizonyos paraméterekre (például adattípusokra, pufferméretekre, alapértelmezett értékekre) való hivatkozás nélkül.

Szintaxis:

sablon

osztály NAME_CLASS

NAME_CLASS B; //Hívás

A polimorfizmus a három fő OOP paradigma egyike. Röviden, a polimorfizmus egy objektum azon képessége, hogy olyan származtatott osztály metódusait használja, amelyek nem léteznek az alap létrehozása idején. Azok számára, akik nem különösebben jártasak az OOP-ban, ez valószínűleg bonyolultan hangzik. Ezért nézzük meg egy példa segítségével a polimorfizmus használatát.

A probléma megfogalmazása

A legegyszerűbb lehetőség, ami eszünkbe jut, az, hogy három külön osztályt írunk, és dolgozunk velük. Vagy írjon egy osztályt, amely tartalmazza mindhárom típusú kiadványban rejlő összes tulajdonságot, és csak a szükségeseket használja. De a különböző típusoknál a logikailag hasonló módszereknek eltérően kell működniük. Több azonos típusú metódus elkészítése különböző típusokhoz (get_news, get_announcements, get_articles) teljesen tudatlan. Itt jön jól a polimorfizmus.

Absztrakt osztály

absztrakt osztály Kiadvány
{
// táblázat, amely az elemre vonatkozó adatokat tárolja
védett $tábla ;

// az elemek tulajdonságai ismeretlenek számunkra
védett $tulajdonságok = array();

// konstruktor

{
// vegye figyelembe, hogy nem tudjuk, melyik táblából kell az adatokat beszereznünk
$result = mysql_query ("SELECT * FROM `" . $this -> table . "` WHERE `id`="" . $id . "" LIMIT 1" );
// azt sem tudjuk, milyen adatokat kaptunk
$this -> property = mysql_fetch_assoc ($eredmény );
}

// metódus, amely minden típusú publikációnál ugyanaz, a tulajdonság értékét adja vissza
nyilvános függvény get_property ($name)
{
if (isset($this -> tulajdonságok [ $name ]))
return $this -> property [ $name ];

Return false ;
}

// metódus, amely minden típusú publikációnál ugyanaz, beállítja a tulajdonság értékét
nyilvános függvény set_property ($név, $érték)
{
if (!isset($this -> tulajdonságok [ $name ]))
return false ;

$this -> property [ $name ] = $érték ;

$érték visszaadása ;
}

// és ennek a módszernek ki kell nyomtatnia a kiadványt, de nem tudjuk pontosan, hogyan kell ezt megtenni, ezért absztraktnak nyilvánítjuk
absztrakt nyilvános függvény do_print();
}

Származtatott osztályok

osztály Hírek kiterjeszti Megjelenés
{
// a news osztály konstruktora, amely a Publications osztályból származik
nyilvános függvény __construct ($id)
{
// beállítja annak a táblának az értékét, amelyben a híradatokat tárolják
$this -> table = "hírtáblázat" ;
szülő :: __construct ($id );
}

Nyilvános függvény do_print()
{
echo $this -> property ["title" ];
visszhang"

" ;
echo $this -> tulajdonságok ["szöveg" ];
visszhang"
Forrás: " . $this -> property [ "forrás" ];
}
}

Az osztályhirdetés meghosszabbítja a megjelenést
{
// a közzétételi osztályból származó hirdetésosztály konstruktora
nyilvános függvény __construct ($id)
{
// állítsa be annak a táblázatnak az értékét, amelyben a hirdetési adatok tárolódnak
$this -> table = "bejelentések_táblázata" ;
// meghívjuk a szülőosztály konstruktorát
szülő :: __construct ($id );
}

// felülbírálja az absztrakt nyomtatási módszert
publikus függvény do_print()
{
echo $this -> property ["title" ];
visszhang "
Figyelem! A hirdetmény ig érvényes. $this -> tulajdonságok ["end_date" ];
visszhang"

" . $this -> tulajdonságok [ "szöveg" ];
}
}

Osztály Cikk kiterjeszti a publikációt
{
// a publikációs osztályból származtatott cikkosztály konstruktora
nyilvános függvény __construct ($id)
{
// beállítja annak a táblának az értékét, amelyben a cikkekre vonatkozó adatok tárolódnak
$this -> table = "cikk_táblázat" ;
// meghívjuk a szülőosztály konstruktorát
szülő :: __construct ($id );
}

// felülbírálja az absztrakt nyomtatási módszert
publikus függvény do_print()
{
echo $this -> property ["title" ];
visszhang"

" ;
echo $this -> tulajdonságok ["szöveg" ];
visszhang"
" . $this -> tulajdonságok [ "szerző" ];
}
}

Most a használatról

// töltse ki a publikációs tömböt a Publikációból származó objektumokkal
$publications = új hírek ($hírazonosító);
$publications = new Announcement($announcement_id);
$kiadványok = új cikk($cikkazonosító);

Foreach ($publications mint $publication) (
// ha a Publikáció örököseivel dolgozunk
if ($publication instanceof Publication) (
// majd nyomtassa ki az adatokat
$publication -> do_print();
) más (
// kivétel vagy hibakezelés
}
}

Ez minden. Egy enyhe kézmozdulattal elegáns rövidnadrág lesz a nadrágból :-).

A polimorfizmus fő előnye, hogy könnyű új osztályokat létrehozni, amelyek hasonlóan „viselkednek” a kapcsolódó osztályokhoz, ami viszont lehetővé teszi a bővíthetőség és módosíthatóság elérését. A cikk csak egy primitív példát mutat be, de még ez is megmutatja, hogy az absztrakciók használata hogyan könnyíti meg a fejlesztést. A hírekkel ugyanúgy dolgozhatunk, mint a reklámokkal vagy cikkekkel, és nem is kell tudnunk, mivel dolgozunk! A valós, sokkal összetettebb alkalmazásokban ez az előny még nagyobb.

Egy kis elmélet

• A felülbírálást igénylő módszereket absztraktnak nevezzük. Logikus, hogy ha egy osztály tartalmaz legalább egy absztrakt metódust, akkor az is absztrakt.
• Nyilvánvaló, hogy egy absztrakt osztályhoz tartozó objektumot nem lehet létrehozni, különben nem lenne absztrakt.
• A származtatott osztálynak vannak olyan tulajdonságai és metódusai, amelyek az alaposztályhoz tartoznak, és lehetnek saját metódusai és tulajdonságai is.
• A származtatott osztályban felülírt metódust virtuális metódusnak nevezzük. Az alap absztrakt osztályban nincs információ erről a metódusról.
• Az absztrakció lényege, hogy egy módszert ott határozzunk meg, ahol a legteljesebb információ áll rendelkezésre a működéséről.

A programozás az „élő”, dinamikus problémák megoldásának kidolgozásának folyamata kód, adat, függvények és algoritmusok merev struktúráinak formájában. A homályos szemantikából szigorú szintaxis kialakításának eljárása. A valós problémák jól ismert nagy problémája az algoritmizálásnak: a kívánt megoldás eléréséhez a feladatot pontos szintaktikai struktúrákba kell helyezni.

Az OOP kétszer kísérelte meg „megtörni” ezt az ősi programozási koncepciót, de a klasszikus adatkódolási stílus és algoritmusok „béklyói” még mindig erősek.

Szint és végzettség

A számítástechnika a számításokkal kezdődött, de az információfeldolgozás területére való mozgás gyorsulása még nem elég gyors ahhoz, hogy a klasszikus programozás lehetetlenné váljon és megszűnjön.

Az is objektív, hogy a fejlesztő ne ragaszkodik hozzá, és a megrendelő ne követeljen valódi megoldást valós problémákra. Mindkét fél megszokta, hogy korlátozzák a rendelkezésre álló eszközök és az ismert képességek.

Az OOP polimorfizmus formái, a kódbeágyazás gondolatai és a tulajdonságok (módszerek) öröklődése a programozás körébe tartoznak, de nem a megoldandó probléma körébe.

Jó példa erre a PHPOffice/PHPWord könyvtár. Használatához fejlesztői végzettség szükséges, saját objektumrendszert kell létrehozni, de a megrendelő jelenlegi szintje (vevői igények) egy triviális kompozíció, amit a programozó saját fejlesztésével fed le (különben a követelmények nem teljesíthetők ). A helyzet valami ilyesmi:

Ebben az esetben a könyvtárhasználat a dokumentumformázás feladata, például oklevelet, szakdolgozatot kell a szabvány szerint formázni. Az ügyfél előadta igényeit, a programozó pedig sokkal tovább ment a maga útján.

Megtörtént a dokumentum teljes elemzése, összeállítása a szükséges formátumban, munka bármilyen beágyazási szintű táblázatokkal, cellák összevonása és felosztása, nyomtatás tetszőleges irányban stb.

Polimorfizmus és OOP

Nem tudok jobb definíciót elképzelni a polimorfizmusra, mint az objektum-orientált programozás eszméjének fejlődéstörténetére hivatkozni, amely ma oly népszerű, gyakran használt, de meg nem valósult lényegében még mindig az.

• tokozás;
• polimorfizmus;
• öröklés.

Egyesek azt is hozzáteszik: az absztrakciót, és leggyakrabban ez, és valójában a lényeg, alapul szolgál az OOP lényegének leírásához.

Tehát az OOP-ról alkotott vélemények polimorfak: egy dolgot írnak le, másképpen terveztek, vagy fordítva, különböző dolgokat írnak le, de négy azonos állásponton alapulnak.

A demokratikus elv nem jellemző az informatika területére, de meg kell adni a maga érdemét: sok, ugyanarról a dologról alkotott vélemény kombinációja és együttélése valódi polimorfizmus.

A polimorfizmus népszerű definíciói

Az OOP az információs technológia fejlődésének következő állomása. Ezzel kevesen vitatkoznak, de fő axiómái és rendelkezései szemantikailag annyira eltérnek, hogy nem érdemelnek figyelmet a totalitásukon kívül.

1. A polimorfizmus a programozásban az a képesség, hogy ugyanazt az interfészt biztosítsuk a különböző mögöttes formákhoz (adattípusokhoz).
2. A polimorfizmus az objektumok azon képessége, hogy különböző megvalósításokkal rendelkezzenek.
3. A polimorfizmus egy függvény képessége...
4. Klasszikus (a C/C++ megalkotójától): „egy interfész – sok megvalósítás.”
5. A paraméteres polimorfizmus azt jelenti...
6. A polimorfizmus a típuselmélet egyik rendelkezése...
7. Az absztrakció lehetetlen tokozás és öröklődés nélkül, ahogy a polimorfizmus sem öröklődés nélkül...

Egyetérthetünk abban, hogy mindez ugyanarra vonatkozik: de a gondolat kifejezési formája, a lényeg és a tartalom nem hasonló. De még mindig van valami közös.

Entitás: fejlesztő – ügyfél

A klasszikus programfejlesztés feltételezi a programozó és egy feladat (kliens, ügyfél) jelenlétét. A programozó megvizsgál egy problémát, formalizálja, és kódot készít, amely megoldáshoz vezet. A megrendelő mindent, vagy annak csak egy részét tagadja, rámutatva a hiányosságokra, és a programozó ismét elvégzi a munkáját.

A problémamegoldási folyamat ezen ciklusa arra utal, hogy itt két teljesen különböző entitás egyértelműen kombinálódik:

• a számítógép maga nem tudja megoldani a problémát;
• programra van szükség, hogy a számítógép „meg tudja érteni” és „meg tudja oldani” a problémát.

A feladat az ügyfél kompetenciája, a program egy algoritmus a feladatnak a számítógép képességeihez való „igazítására” - a programozó kompetenciájába. Ez utóbbinak az a szerepe, hogy a számítógépet a feladat követelményeihez „igazítsa”, ez pedig felesleges!

Ajánlatok absztrakt. Vannak tárgyak - ez az ügyfél szférája; ott van az objektumok megvalósítása - ez a programozó szférája. A megrendelő és a fejlesztő között nincs „technológiai” kapcsolat. Az ötlet radikális, a mai napig nem valósult meg, de valami már stabilan működik.

Ablakok, gombok és egyéb objektumok

Az Air Art Technology, az Object Magazine, a Turbo Vision, a Graph Vision története már történelem. Kevesen emlékeznek az OOP ezekre a megvalósításaira, gyakorlatilag nem használják és elfelejtik őket, de a Windows ablakfelületet több millió felhasználó ismeri, és a PHP, JavaScript és más internetes technológiai nyelvek objektumait kódfejlesztők százezrei használják. , és a webes források látogatóinak milliói tudnak róluk.

Valószínűleg ez az egyetlen helyes út, ahogyan az OOP-nak fejlődnie kellett: tokozás, öröklődés, polimorfizmus a fejlesztő számára, de nem a felhasználó számára. Jellemző, hogy ez a pozíció volt a fő a Windows-szoftverek és az olyan alkalmazási programok, mint a Turbo Vision és a Graph Vision látványtervének (interfészének) fejlesztésében.

Az olyan termékek mögött meghúzódó koncepció, mint az Air Art Technology és az Object Magazine, jelentősen eltérő volt. Itt az absztrakt objektum volt az információs struktúra legelső őse, amely az információfeldolgozó kódot absztrakt szinten zárta be. Itt másodlagosak voltak az ablakok, gombok, látványelemek tárgyai.

Az első verzióban (Windows és stb.) az OOP paradigmát: beágyazás, öröklődés, polimorfizmus egy absztrakt ős szintjén jelölték ki, és a kód implementációja az öröklődési ág mentén az egyes leszármazottak szintjén alakult ki a szerint. a kívánt szerkezetre és tartalomra.

A második lehetőségnél (az Air Art Technology and Object Magazine) az absztrakt objektum szintje fontos. Nem az a lényeg, hogy egy adott leszármazottnak mi lesz, a lényeg, hogy az öröklődési ága a gyökérabsztrakcióig minden szülő követelményét kielégítse.

Objektum és objektumrendszer: algoritmus

Egy ideális objektum-orientált koncepció csak objektumokat és objektumrendszereket képes manipulálni.

A modern programozási nyelvekben az objektum (osztály) általában egy objektum leírása és egy objektum példánya, és az objektum leírásának használatához a nyelvek lehetővé teszik a programozó számára, hogy statikus objektumokkal dolgozzon, míg dinamikus objektum - leírások, saját egyedi tartalommal és szerkezettel, de ugyanazokat a leírási módszereket (tulajdonságokat) használják.

A jelenlegi gyakorlat az objektum fogalmát egy eszközhöz, azaz egy programozási nyelvhez, interfészhez, adatbázis-eléréshez, hálózati kapcsolathoz köti, de semmi sem utal a megrendelő érdekeire, a megoldandó problémára.

Ez ideális az egyszerű OOP-hoz: a polimorfizmus lehetővé teszi, hogy sokféle tervezési elemet készítsünk, de ugyanazzal a kóddal kezeljük őket. De itt nem a probléma tárgyairól beszélünk, amely egyáltalán nem tekinthető tárgyorientált elemzés tárgyának.

A programozók az OOP-t mint eszközt alkalmazták munkájuk minőségének és termelékenységének javítására, de a „területükből” egy darabot sem engedtek át az ügyfélnek. Az OOP alapfogalmai - kapszulázás, öröklődés, polimorfizmus - a fejlesztési területen maradtak, nem kerültek át a feladatterületre.

Tárgy és objektumrendszer: probléma és megoldás

Számítógép - programozó - feladat. A középső link felesleges. Ideális esetben csak két relatíve függő áramkör legyen: (számítógép - programozó) - feladat. Vagyis a felhasználónak, vásárlónak vagy látogatónak van eszköze a problémája megoldására. A vásárlót nem érdekli az eszköz megvalósítása.

Ideális esetben ez csak egy számítógép, amely képes megérteni, hogy az ügyfél mit akar, és azt csinálja, amit akar. Hogy fog kinézni: egy helyi program vagy egy böngészőn keresztül elérhető webhely, egy speciális program az elosztott információfeldolgozáshoz, egy információs rendszer az ügyfél számára - nem számít.

Fontos, hogy ne legyen felesleges kapcsolat a feladat és a számítógép között, hanem az elsőt a második megérti és megoldja. A cél eléréséhez a számítógépet és az ügyfelet egy objektumrendszerrel kell összekötni, és az egyes objektumok jelentését, szerkezetét és tartalmát a megrendelő határozza meg, az objektumok módszereit és tulajdonságait pedig a programozó valósítja meg.

Ideális, ha a megrendelőnek a számára szükséges objektumrendszer létrehozásán és az ezen objektumok módszereinek és tulajdonságainak megvalósításán végzett munka időben elválik egymástól. Minél távolabb van egy objektumrendszer (programozó) megvalósítása a szemantikai tartalmától (ügyfél), annál jobb a folyamat minősége.

Semmi sem akadályozza meg az ügyfél és a programozó interakcióját a probléma megoldása során, de fontos a szemantika világos elkülönítése. Mindenki tegye a saját dolgát, a programozó nem köteles elsajátítani a feladatkört, a megrendelő pedig ne értse a kódot, ráadásul a felek ne adjanak tanácsot egymásnak, ami őket nem érinti.

Hagyományos és objektum programozás

Az OOP alapvető posztulátumai: beágyazódás, öröklődés, polimorfizmus abban a formában, amelyben megismerték és keresett, észrevehető javulást eredményeznek a kód minőségében és megbízhatóságában, jelentősen felgyorsítják a programozó munkáját és sokat egyéb pozitív tulajdonságokkal.

De a dolgok még mindig ott vannak: a klasszikus programozás nem rosszabb, mint a pozíciója, és sok objektum-orientált ötletet klasszikus kódban valósítanak meg.

Az OOP és a rekurzió ötletei azonban megfelelő hatást gyakoroltak a klasszikus szintaxis operátorok szintaxisára, a hétköznapi kód felépítésének logikájára, amelynek semmi köze az objektum-orientált írás- és gondolkodásstílushoz.

A listák és a sorok átalakultak, megjelent a tömb első és utolsó elemének fogalma, megjelentek az „mindegyikhez” ciklusok, és a korábbiaknál is népszerűbbek lettek az elnevezési, felhasználási és végrehajtási hivatkozási lehetőségek.

Valójában az a tény, hogy a változók elvesztették „tiszta” arcukat (a változó típusa szükség szerint változhat, és egyáltalán nem kell változót leírni), azt mondja, hogy a klasszikusok valójában régen objektummá váltak. orientálta és felismerte az OOP alapelveit: a kapszulázást, az öröklődést, a polimorfizmust, mint jelentős jelentőségű gondolatokat.

Mire épül: tárgyra vagy rendszerre?

Az absztrakció, mint az OOP fő fogalmi pozíciója, függetlenül attól, hogy az objektum felelősségi területe (megvalósítása) hol található - az első absztrakt objektum szintjén vagy egy konkrét leszármazott szintjén - nyitva hagyja a kérdést: hol kezdjek mindent, az objektumtól vagy a rendszertől?

Ha egy tárgyat adunk alapul, akkor abból soha nem lesz rendszer, hiszen a rendszer benne lesz, és maga egy nagyon konkrét kezdet merev képe lesz. Itt az absztrakcióval kapcsolatos problémák merülnek fel: a kezdeti objektum pontosan megragadja a megoldandó probléma lényegét, vagyis többé nem ültethető át egy másik problémába.

Ha egy objektumrendszerre alapozzuk, akkor rendszerrendszert kapunk. Ez nehezen képzelhető el egy konkrét feladat kapcsán, és az is nehezen érthető, hogy hol kezdjem a fejlesztést. Összességében az OOP polimorfizmusa az entitásokban, a megvalósítási formákban és a függvényekben lévő tényleges paraméterek számában mutatkozó különbségekkel képet ad a kezdeti rendszerről:

• a probléma megoldásának lehetőségeiről (például menü);
• kezdeti feltételekről (a probléma alkalmazása különböző körülmények között, adatok);
• az üzemmódokról (tesztelés, beállítás, működés).

De ez és a hasonlók nem adnak alapot arra, hogy a probléma megoldását tárgyrendszerre alapozzuk. Gyakran elegendő egyetlen kezdő objektum definiálása.

A problémamegoldási folyamat története

Az OOP legfontosabb alapelvei: polimorfizmus és absztrakció - a kezdeti objektumot mint objektumrendszert helyezi előtérbe. Abban a vitában, hogy melyik legyen előbb, a tyúk vagy a tojás, itt a csirke nyer.

Kétségtelen, hogy mindennek egy absztrakt tárggyal kell kezdődnie, nem pedig a tárgyak rendszerével. De ha figyelembe vesszük az idő tényezőjét, és minden objektum szintjén alkalmazzuk, a legelső absztrakttól kezdve, akkor az az ellentmondásos gondolat, hogy a tárgyat és a rendszert is a döntés elejére helyezzük csak egy ésszerű.

Ha a klasszikus programozási koncepció egy probléma megoldása során megváltoztatja az adatokat, az adatbázis tartalmát, megváltoztatja a fájlokat stb., akkor az OOP koncepcióban a polimorfizmus, a beágyazás és az időfaktor megváltoztatja a tartalmat, a szerkezetet és a tulajdonságokat. a megoldandó probléma objektumrendszeréről.

Az OOP programozót a legkevésbé érdekli a fájl, az adatbázis, az algoritmus fogalma – ezek itt a programozó objektumokban gondolkodnak, de az objektumok időben léteznek, és a kívánt elérése során változnak.

Kezdetben tehát az objektum mint objektumrendszer és ennek a rendszernek a logikája - az időskálája rejlik: egy feladat elindítása, az első objektum kialakítása, adatbevitel vagy -gyűjtés, a következő objektum kialakítása, de semmi sem akadályozza meg az első objektumot abban, hogy továbblép a következő megoldásra.

Az objektumok mindegyik szintje önálló tárgyrendszerként működik, vagyis egy objektum, de a megkezdődött folyamat és az idő jelentésének összefüggésében az időskálán lévő objektumok rendszere. Az OOP teljes megvalósításához a polimorfizmus, az öröklődés és az időtényező együttesen biztosítják az első dinamikáját, vagyis egy objektum nemcsak idővel változhat, hanem a fejlesztő által nem tervezett objektumokat is generálhat, amelyek egy végrehajtással generálódnak. a folyamat során a megrendelő által tervezett feladat.

Valódi OOP polimorfizmus, példa

Az OOP által megoldható problémák összetettsége nem hasonlítható össze az írási programok klasszikus verziójával. Természetesen mindig meg lehet oldani bármilyen problémát a szokásos módon, de az a kérdés, hogy mennyibe fog ez időbe és erőfeszítésbe kerülni, gyakran használhatatlanná teszi az eredményt.

A PHPOffice/PHPWord könyvtárat nem régen fejlesztették ki, de a képességeinek kihasználásához szinte mindig saját objektumrendszert kell létrehozni. Például egy egyszerű *.docx fájl:

számos fájl és mappa zip archívuma Office Open XML formátumban (OpenXML, OOXML). Minden fájl XML címkékben van írva, és amikor betűket, szavakat, táblázatokat, listákat és egyéb elemeket adunk hozzá, módosítunk és törölünk, a fájlok tartalma olyan címkék sorozatát kezdi képviselni, amelyek nem mindig tartalmaznak teljes elemeket sok címkével írva.

Ha ezt a fájlt címkék sorozataként képzeli el, érdekes képet kap:

Könnyen észrevehető, hogy a dokumentum első és egyetlen bekezdését sok címke képviseli. Ami a táblát és az abba beépített táblákat illeti, az összes elem leírásának volumene nem érzékelhető, de egy objektum-orientált alkalmazás számára elérhető.

Valójában az ábrán a zöld a címkék tesztkimenete, a sárga a címke paraméterei és típusa, a bézs pedig a tartalom. A létrehozott objektumok gépi feldolgozásra vannak orientálva. Csak a dokumentumfájl megnyitásának, formázásának és írásának műveletei válnak elérhetővé az ember számára.

A megoldás egyszerű és praktikus, de a megvalósítás inkább számítógép-, mint emberorientált a végrehajtott funkcionalitás mennyisége és az objektumok közötti bonyolult kapcsolatok miatt.

OOP terület állam

A weboldal-kezelő rendszerek, a szerverek beállítására és kezelésére szolgáló technológiák fejlesztése, valamint a dinamikus weboldalak fejlesztésében szerzett tapasztalat mindenki számára elérhetővé tette az objektumorientált programozást. A probléma az, hogy hogyan változtasd meg a gondolkodásodat, és hogyan szoktasd meg az objektumok szintjén való gondolkodást, nem pedig a szekvenciálisan végrehajtott kód kontextusában.

A klasszikus programozásról az objektum-orientált programozásra való átállás általában két-három hónapot vesz igénybe, de a költségek több mint megérik. A modern programozási nyelvek, elsősorban a PHP és a JavaScript lehetőségei kielégítik a legkifinomultabb fejlesztőket is.

A modern OOP - polimorfizmus, öröklődés és az objektumtulajdonságok kialakításának képessége - kényelmes és praktikus, a nyelvi szintaxis és a segédeszközök egyszerű használatot és kódhatékonyságot biztosítanak.

A tárgygondolat perspektívái

Nehéz megmondani, meddig fog tartani a klasszikus programozás, és hogyan fog fejlődni az OOP. Úgy tűnik, az eszközfejlesztők nem tervezik figyelembe venni a fogyasztó (felhasználó, vásárló) kontextusát.

Az OOP eszközök – polimorfizmus, öröklődés, tokozás és absztrakció – fejlesztő-orientáltak.

A modern információs rendszerek és webes források arra törekszenek, hogy tükrözzék a valóságot, biztosítsák a valós objektumok működését, és olyan egyszerű környezetet teremtsenek működésükhöz, hogy az elérhető legyen a programozástól távol álló, saját területén teljesen elmerült fogyasztó számára. kompetencia.

RENDBEN. A polimorfizmust soha nem szabad más alapvető fogalmaktól – az absztrakciótól, a beágyazástól és az öröklődéstől – elkülönítve tekinteni. A tárgyat és hasonlókat axiómákból csatolják (bár ezek is axiómák).

Tulajdonképpen képzeljünk el egy poharat, egy bögrét, egy vízforralót, egy kávéfőzőt, egy kerékpárt és egy gördeszkát a közelben. Mi a közös bennük? Legalább, hogy léteznek. Vagyis ezek olyan objektumok, amelyeket létrehoztak. De hogyan jöttek létre? Valószínűleg a gyártó gyárában a rajzok szerint. Rendben, nevezzük a konstruktort rajznak. Nos, mi lesz az osztállyal? Mi ez? De nem a mi univerzumunkban van – ez a lényeg egy absztrakció, amely csak a gondolatainkban él. A való világban nem létezik és nem is fog, ilyen a fizika - nem érdekli, hogy a madaraknak és az emlősöknek vannak távoli rokonai -, csak a természetes szelekció lehetőségét biztosítja. Mi, emberek pedig rokonokat találunk egymásnak.

Kiválogattuk a tárgyakat és az osztályokat, de mi a helyzet a szemüvegünkkel és a kerékpárokkal? Azt már megértettük, hogy minden egy objektum, vagyis nagyjából minden objektum örökölhető valamilyen szuperőstől, szuperosztálytól, ami bizonyos nyelveken megvalósul. De mi a közös még például egy gördeszkában és egy pohárban? Természetesen mélyebbre lehet menni, és figyelembe venni, hogy mindegyik molekulákból, és mind szilárd anyagokból áll. Ez azonban mind nonszensz és SRSG, így a válasz egyszerű - semmi. Vagyis ezek teljesen különböző objektumok, teljesen eltérő funkcionalitással. Ezenkívül természetesen a számítógépes modellek és hierarchiák nagyon különböznek a fizikától és a kémiától. És ez normális, a modellek megfelelőségének kérdése csak akkor vetődik fel, ha a modell nem megfelelő, és addig bármit lehet vágni, amíg működik.

Itt. Van egy szuper-ősobjektumunk, amelytől alapértelmezés szerint minden objektum örököl. Tegyük fel, hogy minden objektum örökli azt a tényt, hogy az objektumok atomokból állnak. De minden kiegészítés és szerkesztés polimorfizmus. Tehát atomokból kerekeket készítettünk, és egy deszkára rögzítettük - ok, ez egy gördeszka. Felállhatsz rá és gurulhatsz, vagy erősen csavarodva repülhetsz három méterrel a föld felett, csak úgy sugározva ragyogó egódat. Míg az üveg az, ahol atomokból sűrű tartályt formáztunk, amiből a gravitáció hatására nem ömlik ki a víz. A pohár közvetlen felhasználása pedig az, hogy vizet öntünk és a szájunkra billentjük, hogy a víz közvetlenül a gyomorba folyjon. Ezt teszik az igazi fiúk anélkül, hogy aggódnának a csuklástól vagy a fulladástól való félelemtől, szóval ez megvan – polimorfizmus.

De mi van a többivel? Van még absztrakciónk, beágyazódásunk és öröklődésünk is. Ok, kezdjük az örökléssel, ez a legközelebb. Mi a közös bögrében és pohárban? Nos, mindkettőbe lehet vizet önteni, de a bögrének van egy fogantyúja, amibe bele lehet kapaszkodni. Vagyis előállhat egy bizonyos általános osztály - kapacitás. De mi is ez az osztály? Például ehhez az osztályhoz vehet egy poharat, akkor az összes tartály alapértelmezés szerint pohár, minden más pedig módosított pohár. De van, aki jobban szereti a kancsót, van, aki a fején hordja, és azt gondolja, hogy kényelmes. Nos, hadd hordják, de valahogy el kell dönteniük, mi a fontosabb és ideálisabb. Tehát - az elérhetetlen ideál a fő - ezt nevezik absztrakt osztálynak. Vagyis egy nem létrehozható konténer, amelyhez nincs teljes rajz. A teljes formájúra kibővített összes rajz pedig a kapacitásosztály öröklött osztálya.

Itt elérkeztünk az absztrakcióhoz. Ez a hierarchikus öröklődés elvezet minket az OOP talán fő gondolatához. Így hát vettünk és külön osztályba kiemeltünk mindent, ahol vizet lehetett önteni, általános rajzot rajzoltunk, de szándékosan nem fejeztük be, hézagot hagyva a leendő alkotóknak, és edénynek neveztük a rajzot. Évezredek óta feltalálták az összes világot, és megalkották saját konténereiket, egyik jobb, mint a másik. Ez persze különböző embereknél más. De az üvegmolekulákat minden alkalommal meghatározott módon csoportosítani nem könnyű feladat. Ezért a kézművesek egy trükkhöz folyamodtak: létrehozták a világ kézműveseinek titkos tanácsát, és úgy döntöttek, hogy megosztják egymással eredményeiket. Vagyis készítsen kis rajzokat, és osztályként deklarálja, például egy csavart tollat ​​Möbius csík formájában. Talán egy ilyen toll csak idegen lények számára kényelmes, de a rajz elkészült, és hivatkozni lehet rá saját rajz létrehozásakor. Így elvonatkoztatunk a „molekulák mozgatásával tárolóedények kialakításának” alacsony szintű feladatától a „tartály építése alkatrészek és elemek kombinálásával” felé. Ez az absztrakció.

De elérkeztünk az utolsó ponthoz - a tokozáshoz. Elválaszthatatlan az absztrakciótól, sőt, ennek köszönhető, hogy működik. A tokozás egyfajta ragasztó (vagy kék elektromos szalag), amelyet különböző rajzok ragasztására használnak. Vagyis az alkatrészek kombinálása saját létrehozásához beágyazás. Sőt, kombináláskor előfordulhat, hogy nem írjuk le ennek a kombinációnak a részleteit (vagyis az osztálytagok lehetnek privátak), így segítve az absztrahálást a rajzot használók számára. Nézzük a teáskannát – mi az? Ez egy pohár (vagy bögre), amihez az aljára (vagy esetleg a közepére?) fűtőelem van ragasztva. Ha áramot vezetünk át rajta, a fűtőelembe zárt Ohm-törvény szerint hő szabadul fel, és a víz felmelegszik. Mi a helyzet a kávéfőzővel? Ez egy sokkal összetettebb eszköz, sok szivattyúval, tartállyal, légzsilippel, darálóval és vízforralóval. És minden össze van ragasztva ragasztóval. Vagy talán kék elektromos szalag. Ez megint a kapszulázás.

Így az absztrakció lehetetlen tokozás és öröklődés nélkül, mint ahogy a polimorfizmus is lehetetlen maga az öröklődés nélkül. Nos, a polimorfizmus is lehetetlen tokozás nélkül, ami öröklődés és polimorfizmus nélkül egyszerűen haszontalan. Ezek a háromszögek pitékkel. Kár, hogy hazudtak a lepényről. És a születésnapról.