Objektově orientované programování

Aktuální verze stránky ještě nebyla zkontrolována zkušenými přispěvateli a může se výrazně lišit od verze recenzované 15. března 2022; kontroly vyžadují 10 úprav .

Objektově orientované programování ( zkr. OOP)  je metodologie programování založená na reprezentaci programu jako množiny vzájemně se ovlivňujících objektů , z nichž každý je instancí určité třídy a třídy tvoří hierarchii dědičnosti [1] .

Ideologicky je OOP přístup k programování jako k modelování informačních objektů, řešící na nové úrovni hlavní úkol strukturálního programování : strukturování informací z pohledu ovladatelnosti [2] , což výrazně zlepšuje ovladatelnost procesu modelování. což je zase důležité zejména při realizaci velkých projektů.

Správa pro hierarchické systémy zahrnuje minimalizaci redundance dat (podobně jako normalizace ) a jejich integritu, takže to, co je vytvořeno pohodlně spravovatelné, bude také pohodlně pochopeno. Prostřednictvím taktického úkolu ovladatelnost je tedy vyřešen strategický úkol - převést pochopení úkolu programátorem do nejvhodnější podoby pro další použití.

Základní principy strukturování v případě OOP souvisejí s různými aspekty základního porozumění předmětu, který je nutný pro optimální řízení odpovídajícího modelu:

To znamená, že ve skutečnosti mluvíme o progresivní organizaci informací podle primárních sémantických kritérií: „důležité / nedůležité“, „klíč / podrobnosti“, „rodič / dítě“, „jediný / množné číslo“. Progrese zejména v poslední fázi umožňuje přejít na další úroveň detailů, která uzavírá celkový proces.

Obyčejný lidský jazyk jako celek odráží ideologii OOP, počínaje zapouzdřením reprezentace předmětu ve formě jeho jména a konče polymorfismem užívání slova v přeneseném smyslu, který v konečném důsledku rozvíjí [ 3] vyjádření reprezentace přes název objektu až po plnohodnotnou pojmovou třídu.

Základní pojmy

Abstrakce dat Abstrakce znamená zvýraznění smysluplných informací a vyloučení irelevantních informací z úvahy. OOP bere v úvahu pouze abstrakci dat (často označovanou jednoduše jako „abstrakce“), která implikuje sadu nejvýznamnějších charakteristik objektu dostupných pro zbytek programu. Zapouzdření [4] Encapsulation je systémová vlastnost, která umožňuje kombinovat data a metody, které s nimi pracují, ve třídě. Některé jazyky (jako C++ , Java nebo Ruby ) přirovnávají zapouzdření ke skrytí , ale jiné ( Smalltalk , Eiffel , OCaml ) je rozlišují. dědictví [4] Dědičnost je vlastnost systému, která vám umožňuje popsat novou třídu na základě existující třídy s částečně nebo zcela vypůjčenou funkčností. Třída, ze které dědíte, se nazývá základní, nadřazená nebo nadřazená třída. Nová třída je potomkem, následníkem, potomkem nebo odvozenou třídou. Polymorfismus podtypů [4] Polymorfismus podtypu (v OOP jednoduše nazývaný „polymorfismus“) je vlastnost systému, která umožňuje používat objekty se stejným rozhraním bez informací o typu a vnitřní struktuře objektu. Jiný druh polymorfismu – parametrický  – v OOP se nazývá generické programování . Třída Třída je univerzální, komplexní datový typ , který se skládá z tematicky jednotné množiny „polí“ (proměnných více elementárních typů) a „metod“ (funkcí pro práci s těmito poli), jedná se tedy o model informační entity s interní a externí rozhraní pro obsluhu vlastního obsahu (hodnoty polí). Zejména třídy široce využívají speciální bloky jedné nebo častěji dvou párových metod odpovědných za elementární operace s konkrétním polem (rozhraní přidělování a čtení hodnot, getter - setter ), které napodobují přímý přístup do pole. Tyto bloky se nazývají „vlastnosti“ a mají téměř identický specifický název se svým polem (například název pole může začínat malým písmenem, ale název vlastnosti může začínat velkým písmenem). Dalším projevem rozhraní třídy je, že při kopírování odpovídající proměnné prostřednictvím přiřazení se zkopíruje pouze rozhraní, ale ne samotná data, to znamená, že třída je referenčním datovým typem. Objektová proměnná daného typu třídy se nazývá instance této třídy. Současně v některých prováděcích systémech může být třída také reprezentována nějakým objektem během provádění programu prostřednictvím dynamické identifikace datového typu . Třídy jsou obvykle navrženy tak, aby byla zajištěna integrita dat objektu a také pohodlné a jednoduché rozhraní odpovídající povaze objektu a řešené úloze. Na druhé straně je integrita předmětné oblasti objektů a jejich rozhraní, stejně jako pohodlí jejich designu, zajištěna dědičností. Objekt Entita v adresovém prostoru výpočetního systému, která se objeví, když je vytvořena instance třídy (například po spuštění výsledků kompilace a propojení zdrojového kódu pro spuštění).

Klasifikace podtypů OOP

Luca Cardelli a Martin Abadi vytvořili teoretické zdůvodnění OOP a klasifikaci založenou na tomto zdůvodnění [5] [6] [7] [8] . Poznamenávají, že pojmy a kategorie, které identifikovali, se nenacházejí společně ve všech OO jazycích, většina jazyků podporuje pouze podmnožiny teorie a někdy i zvláštní odchylky od ní.

Klíčové koncepty:

Třída popisuje abstraktní chování. Typy objektů jsou postaveny nad třídou přidáním různých soukromých polí a metod. Objekt (tj. hodnota typu objektu, tradičně nazývaná „instance třídy“) je generován konstruktorem na základě počátečních parametrů.

Tradičně vyjmenované základní principy OOP na toto teoretické zdůvodnění nelákají, ale jedná se o komunitně zažitá dogmata (což vede k silnému rozptylu možností prezentace v různých zdrojích). Z velké části patří k jazykům - potomkům Algolu a Simuly ; v menší míře - potomkům Smalltalku (zejména často zmiňovaný princip skrývání se v potomcích Smalltalku je sémanticky nedostupný a ideologicky považován za bezvýznamný). V mnohem větší míře teoreticky založené koncepty OOP podporují OO jazyky, které se vyvinuly v oblasti funkcionálního programování : OCaml , Haskell dialekty (O'Haskell, Mondrian), nástupce ML . Navíc hlavní myšlenky objektového modelování v tomto případě nevyžadují přímou podporu z jazyka, ale lze je relativně snadno emulovat [9] .

Nejvýraznější rozdíly v projevu ukazatelů kvality mezi jazyky různých typů jsou:

Zobecněné zdůvodnění dynamického odesílání (včetně vícenásobných ) vytvořil v polovině 90. let Giuseppe Castagna [11] [12] [13] .

Historie

OOP vznikl jako výsledek rozvoje ideologie procedurálního programování , kde data a podprogramy (procedury, funkce) pro jejich zpracování spolu formálně nesouvisí. Pro další rozvoj objektově orientovaného programování mají často velký význam pojmy událost (tzv. událostně orientované programování ) a komponenta ( komponentní programování , COP) .

Objekty interagují prostřednictvím zpráv . Výsledkem dalšího vývoje OOP bude zřejmě programování orientované na agenty , kde jsou agenti  nezávislými částmi kódu na úrovni běhu. Agenti interagují tak, že mění prostředí , ve kterém se nacházejí.

Jazykové konstrukce, které přímo nesouvisí s objekty designem, ale doprovázejí je pro jejich bezpečný ( výjimečné situace , kontroly) a efektivní provoz, jsou z nich zapouzdřeny do aspektů (v aspektově orientovaném programování ). Objektově orientované programování rozšiřuje koncept objektu tím, že poskytuje jednotnější a nezávislejší interakci mezi objekty. Může to být přechodná fáze mezi OOP a programováním agentů z hlediska jejich nezávislé interakce.

Prvním programovacím jazykem, který navrhl základní koncepty, které se později vyvinuly do paradigmatu, byla Simula , ale termín „objektově orientovaný“ se v souvislosti s používáním tohoto jazyka nepoužíval. V době jeho vzniku v roce 1967 v něm byly navrženy revoluční myšlenky: objekty, třídy, virtuální metody atd., Ale to vše nebylo vnímáno současníky jako něco grandiózního. Ve skutečnosti byla Simula „Algolem s třídami“, takže bylo snadné vyjádřit mnoho složitých konceptů v procedurálním programování . Koncept třídy v Simule lze plně definovat prostřednictvím složení konstruktů Algol (tj. třída v Simule je něco komplexního, popsaného pomocí primitiv).

„Nový úhel“ (jiný než procedurální) pohled na programování nabídli Alan Kay a Dan Ingalls v jazyce Smalltalk . Zde se koncept třídy stal základní myšlenkou pro všechny ostatní jazykové konstrukty (tj. třída ve Smalltalku je primitivum, jehož prostřednictvím jsou popsány složitější konstrukty). Byl to on, kdo se stal prvním rozšířeným objektově orientovaným programovacím jazykem .

V současné době je počet aplikovaných programovacích jazyků ( seznam jazyků ), které implementují objektově orientované paradigma, největší ve srovnání s ostatními paradigmaty. Nejběžnější jazyky v oboru (C++, Delphi, C#, Java atd.) implementují objektový model Simula. Příklady jazyků založených na modelu Smoltok jsou Objective-C, Python, Ruby.

Definice OOP a jeho hlavních pojmů

V centru OOP je koncept objektu. Objekt je entita, které lze posílat zprávy a která na ně může odpovídat pomocí svých dat. Objekt je instancí třídy. Data objektu jsou před zbytkem programu skryta. Zapouzdření zahrnuje skrývání (ale není!).

Přítomnost zapouzdření je dostatečná pro objektivitu programovacího jazyka, ale ještě neznamená jeho objektovou orientaci – to vyžaduje přítomnost dědičnosti .

Ale ani přítomnost zapouzdření a dědičnosti nečiní programovací jazyk plně objektově orientovaným z pohledu OOP. Hlavní výhody OOP se projeví až tehdy, když programovací jazyk implementuje podtypový polymorfismus  – schopnost zacházet s objekty s různými implementacemi jednotným způsobem za předpokladu, že existuje společné rozhraní.

Potíže s definováním

OOP má více než čtyřicetiletou historii, ale navzdory tomu stále neexistuje jasná obecně uznávaná definice této technologie [14] . Základní principy stanovené v prvních objektových jazycích a systémech prošly významnou změnou (nebo zkreslením) a doplněním s četnými následnými implementacemi. Zhruba od poloviny 80. let se navíc termín „objektově orientovaný“ stal módním , v důsledku toho se mu stalo totéž, co o něco dříve s pojmem „strukturální“ (který se stal módou po rozšíření strukturovaného technologie programování ) – stalo se umělým „připoutat“ k jakémukoli novému vývoji, aby byl atraktivní. Björn Stroustrup v roce 1988 napsal , že ospravedlnění „objektové orientace“ něčeho se ve většině případů scvrkává na nesprávný sylogismus : „X je dobré. Orientace objektu je dobrá. X je tedy objektově orientovaný“.

Timothy Budd píše [15] [16] :

Roger King tvrdil, že jeho kočka byla objektově orientovaná. Kočka kromě svých dalších předností projevuje charakteristické chování, reaguje na zprávy, je obdařena zděděnými reakcemi a ovládá svůj vlastní, zcela nezávislý, vnitřní stav.

Podle Alana Kaye , tvůrce jazyka Smalltalk , který je považován za jednoho ze „otců zakladatelů“ OOP, spočívá objektově orientovaný přístup v následujícím souboru základních principů (citováno z výše zmíněné knihy T. Budda).

  1. Všechno je objekt.
  2. Výpočty se provádějí interakcí (výměnou dat) mezi objekty, kdy jeden objekt vyžaduje, aby jiný objekt provedl nějakou akci. Objekty komunikují odesíláním a přijímáním zpráv. Zpráva je požadavek na provedení akce, doplněný sadou argumentů, které mohou být potřebné při provádění akce.
  3. Každý objekt má nezávislou paměť, která se skládá z jiných objektů.
  4. Každý objekt je členem třídy, která vyjadřuje obecné vlastnosti objektů (jako jsou celá čísla nebo seznamy).
  5. Třída definuje chování (funkčnost) objektu. Všechny objekty, které jsou instancemi stejné třídy, tedy mohou provádět stejné akce.
  6. Třídy jsou organizovány do jediné stromové struktury se společným kořenem, který se nazývá hierarchie dědičnosti. Paměť a chování spojené s instancemi konkrétní třídy jsou automaticky dostupné jakékoli třídě pod ní v hierarchickém stromu.

Program je tedy soubor objektů, které mají stav a chování. Objekty komunikují prostřednictvím zpráv. Přirozeně je postavena hierarchie objektů: program jako celek je objektem, aby mohl plnit své funkce, odkazuje na objekty v něm obsažené, které zase provádějí požadované odkazováním na jiné objekty programu. Přirozeně, aby se zabránilo nekonečnému opakování volání, v určité fázi objekt transformuje zprávu, která je mu adresována, na zprávy pro standardní systémové objekty poskytované programovacím jazykem a prostředím.

Stabilita a ovladatelnost systému je zajištěna jasným rozdělením odpovědnosti objektů (za každou akci odpovídá určitý objekt), jednoznačným vymezením rozhraní pro meziobjektovou interakci a úplnou izolací vnitřní struktury objektu od vnější prostředí (zapouzdření).

OOP lze definovat mnoha jinými způsoby.

Koncepty

Vzhled samostatného konceptu třídy v OOP přirozeně vyplývá z touhy mít mnoho objektů s podobným chováním. Třída v OOP je čistě abstraktní datový typ vytvořený programátorem. Z tohoto pohledu jsou objekty hodnotami daného abstraktního typu a definice třídy specifikuje vnitřní strukturu hodnot a sadu operací, které lze s těmito hodnotami provádět. Potřeba hierarchie tříd (a tím i dědičnosti) vyplývá z požadavků na opětovné použití kódu – pokud má několik tříd podobné chování, nemá smysl duplikovat jejich popis, je lepší společnou část oddělit do společné nadřazené třídy a ponechat pouze odlišné prvky v popisu těchto tříd samotných.

Potřeba sdílet objekty různých tříd, které dokážou zpracovat stejný typ zpráv, vyžaduje podporu polymorfismu  – schopnosti zapisovat různé objekty do proměnných stejného typu. Za takových podmínek objekt odesílající zprávu nemusí přesně vědět, do jaké třídy adresát patří, a stejné zprávy odeslané do proměnných stejného typu obsahující objekty různých tříd způsobí odlišnou reakci.

Koncept výměny zpráv vyžaduje samostatné vysvětlení . Zpočátku (například ve stejném Smalltalku ) byla interakce objektů prezentována jako „skutečná“ výměna zpráv, to znamená přenos z jednoho objektu na jiný zvláštního objektu zprávy. Tento model je velmi obecný. Skvěle se hodí například pro popis paralelního počítání pomocí aktivních objektů , z nichž každý má své vlastní vlákno provádění a pracuje současně s ostatními. Takové objekty se mohou chovat jako samostatné, zcela autonomní výpočetní jednotky. Odesílání zpráv přirozeně řeší problém zpracování zpráv objekty přiřazenými k polymorfním proměnným - bez ohledu na to, jak je proměnná deklarována, zpráva zpracovává kód třídy, do které objekt přiřazený k proměnné patří. Tento přístup je implementován v programovacích jazycích Smalltalk , Ruby , Objective-C , Python .

Obecnost mechanismu zasílání zpráv má však i druhou stránku – „plnohodnotné“ předávání zpráv vyžaduje další režii, což není vždy přijatelné. Proto se v mnoha moderních objektově orientovaných programovacích jazycích používá koncept „odeslání zprávy jako volání metody“  - objekty mají metody přístupné zvenčí, jejichž volání zajišťují interakci objektů. Tento přístup byl implementován v obrovském množství programovacích jazyků, včetně C++ , Object Pascal , Java , Oberon-2 . To však vede k tomu, že zprávy již nejsou nezávislými objekty a v důsledku toho nemají atributy, což zužuje možnosti programování. Některé jazyky používají hybridní reprezentaci demonstrující výhody obou přístupů současně – například CLOS , Python .

Koncepce virtuálních metod podporovaná těmito a dalšími moderními jazyky se objevila jako prostředek k zajištění toho, aby byly požadované metody prováděny při použití polymorfních proměnných, tedy v podstatě jako pokus rozšířit schopnost volání metod implementovat část. funkčnosti poskytované mechanismem zpracování zpráv.

Funkce implementace

Jak bylo uvedeno výše, v moderních objektově orientovaných programovacích jazycích je každý objekt hodnotou, která patří do určité třídy . Třída je složený datový typ deklarovaný programátorem, který obsahuje :

Datová pole Parametry objektu (samozřejmě ne všechny, ale pouze nezbytné v programu), které definují jeho stav (vlastnosti objektu předmětné oblasti). Někdy se datová pole objektu označují jako vlastnosti objektu, což může být matoucí. Pole jsou ve skutečnosti hodnoty (proměnné, konstanty) deklarované jako patřící do třídy. Metody Procedury a funkce spojené s třídou. Definují akce, které lze provádět s objektem tohoto typu a které může provádět samotný objekt.

Třídy mohou po sobě dědit. Podřízená třída obdrží všechna pole a metody nadřazené třídy, ale může je doplnit svými vlastními nebo přepsat stávající. Většina programovacích jazyků podporuje pouze jedinou dědičnost (třída může mít pouze jednu nadřazenou třídu), jen některé umožňují vícenásobnou dědičnost – generování třídy ze dvou nebo více nadřazených tříd. Vícenásobná dědičnost vytváří řadu problémů, jak logických, tak čistě implementačních, takže její plná podpora není rozšířená. Místo toho se v 90. letech objevil koncept rozhraní a začal být aktivně zaváděn do objektově orientovaných jazyků . Rozhraní je třída bez polí a bez implementace, včetně pouze záhlaví metod. Pokud třída zdědí (nebo se říká, že implementuje) rozhraní, musí implementovat všechny své členské metody. Použití rozhraní poskytuje relativně levnou alternativu k vícenásobné dědičnosti.

Interakce objektů je v naprosté většině případů zajištěna vzájemným voláním metod.

Zapouzdření je zajištěno následujícími prostředky:

Řízení přístupu Vzhledem k tomu, že metody tříd mohou být jak čistě interní, poskytující logiku fungování objektu, tak externí, s jejichž pomocí objekty interagují, je nutné zajistit, aby první byly skryté, zatímco druhé jsou přístupné zvenčí. K tomu jsou do jazyků zavedeny speciální syntaktické konstrukce, které explicitně nastavují rozsah každého člena třídy. Tradičně se jedná o veřejné, chráněné a soukromé modifikátory, které označují veřejné členy třídy, členy třídy přístupné uvnitř třídy a z podřízených tříd a skryté, přístupné pouze uvnitř třídy. Konkrétní nomenklatura modifikátorů a jejich přesný význam se v různých jazycích liší. Metody přístupu Pole tříd by obecně neměla být přístupná zvenčí, protože takový přístup by umožnil libovolnou změnu vnitřního stavu objektů. Pole jsou proto obvykle prohlášena za skrytá (nebo jazyk v zásadě neumožňuje přístup k polím třídy zvenčí) a pro přístup k datům v polích se používají speciální metody zvané accessors. Takové metody buď vracejí hodnotu určitého pole, nebo do tohoto pole zapisují novou hodnotu. Při zápisu může přístupový objekt zkontrolovat, zda je zapisovaná hodnota platná, a v případě potřeby provést další manipulace s daty objektu tak, aby zůstala správná (vnitřně konzistentní). Přístupové metody se také nazývají accessors (z anglického  access  - access), a samostatně - getters ( anglicky  get  - get) a settery ( anglicky  set  - set) [17] . Vlastnosti objektu Pseudo pole dostupná pro čtení a/nebo zápis. Vlastnosti vypadají jako pole a používají se stejným způsobem jako přístupná pole (až na některé výjimky), ale ve skutečnosti se při přístupu k nim volají metody přístupového objektu. Vlastnosti lze tedy považovat za „chytrá“ datová pole, která doprovázejí přístup k vnitřním datům objektu některými akcemi navíc (např. když je změna souřadnice objektu doprovázena jeho překreslením na nové místo). Vlastnosti ve skutečnosti nejsou nic jiného než syntaktický cukr , protože nepřidávají žádné nové funkce, ale pouze skrývají volání přístupových metod. Specifická jazyková implementace vlastností se může lišit. Například v C# deklarace vlastnosti přímo obsahuje kód přístupového objektu, který je volán pouze při práci s vlastnostmi, to znamená, že nevyžaduje samostatné metody přístupového objektu, které jsou k dispozici pro okamžité volání. V Delphi obsahuje deklarace vlastnosti pouze názvy metod přístupového objektu, které by měly být volány při přístupu k poli. Samotné přístupové objekty jsou běžné metody s některými dalšími požadavky na podpis .

Polymorfismus je implementován zavedením pravidel do jazyka, podle kterých lze proměnné typu „class“ přiřadit objekt libovolné třídy potomka její třídy.

Návrh programu obecně

OOP je zaměřena na vývoj velkých softwarových systémů vyvíjených týmem programátorů (možná poměrně rozsáhlým). Návrh systému jako celku, tvorbu jednotlivých komponent a jejich integraci do finálního produktu často provádějí různí lidé a není jediný specialista, který by o projektu věděl vše.

Objektově orientovaný design se zaměřuje na popis struktury navrhovaného systému (priorita před popisem jeho chování, na rozdíl od funkcionálního programování ), tedy ve skutečnosti jako odpověď na dvě hlavní otázky:

Přidělování dílů probíhá tak, aby každý měl minimální a přesně definovaný soubor vykonávaných funkcí (povinností) a zároveň co nejméně interagoval s ostatními díly.

Další zpřesňování vede k výběru menších fragmentů popisu. Jak je popis podrobný a je určena odpovědnost, odhalují se data, která je třeba uložit, přítomnost podobných agentů v chování, kteří se stávají kandidáty na implementaci ve formě tříd se společnými předky. Po výběru komponent a definování rozhraní mezi nimi lze implementaci každé komponenty provádět téměř nezávisle na ostatních (samozřejmě za dodržení příslušné technologické disciplíny).

Velký význam má správná konstrukce třídní hierarchie. Jedním ze známých problémů velkých systémů postavených pomocí technologie OOP je tzv. problém křehkosti základní třídy . Spočívá v tom, že v pozdějších fázích vývoje, kdy byla vytvořena hierarchie tříd a na jejím základě bylo vyvinuto velké množství kódu, se ukazuje být obtížné nebo dokonce nemožné provádět jakékoli změny v kódu základní třídy hierarchie (ze kterých jsou generovány všechny nebo mnoho tříd působících v systému). I když změny, které provedete, neovlivní rozhraní základní třídy, změna jejího chování může ovlivnit podřízené třídy nepředvídatelným způsobem. V případě velkého systému vývojář základní třídy prostě není schopen předvídat důsledky změn, neví ani, jak přesně se základní třída používá a na jakých vlastnostech jejího chování je správné fungování podřízených tříd. závisí.

Různé OOP metodiky

Programování komponent je další fází vývoje OOP; prototypové a třídně orientované programování jsou různé přístupy k vytváření programu, které lze kombinovat a mají své výhody a nevýhody.

Programování komponent

Komponentově orientované programování  je jakýmsi „doplňkem“ nad OOP, souborem pravidel a omezení zaměřených na budování velkých vývojových softwarových systémů s dlouhou životností. Softwarový systém v této metodice je sada komponent s dobře definovanými rozhraními. Změny ve stávajícím systému se provádějí vytvořením nových součástí, které doplňují nebo nahrazují dříve existující. Při vytváření nových komponent založených na dříve vytvořených je zakázáno použití dědičnosti implementace - nová komponenta může zdědit pouze rozhraní základní. Tímto způsobem programování komponent obchází problém křehkosti základní třídy.

Prototypové programování

Prototypové programování , i když si zachovalo některé rysy OOP, opustilo základní koncepty třídy a dědičnosti.

Třídně orientované programování

Třídně orientované programování je programování zaměřené na data, kde jsou data a chování neoddělitelně propojeny. Data a chování dohromady tvoří třídu. V souladu s tím jsou v jazycích založených na konceptu „třídy“ všechny objekty rozděleny do dvou hlavních typů - třídy a instance. Třída definuje strukturu a funkcionalitu (chování), která je stejná pro všechny instance této třídy. Instance je datový nosič – to znamená, že má stav, který se mění v souladu s chováním specifikovaným třídou. V třídně orientovaných jazycích se nová instance vytvoří voláním konstruktoru třídy (třeba se sadou parametrů). Výsledná instance má strukturu a chování pevně zakódované svou třídou.

Výkon objektových programů

Grady Booch poukazuje [18] na následující důvody poklesu výkonu programu v důsledku používání objektově orientovaných nástrojů:

Dynamická vazba metody Zajištění polymorfního chování objektů vede k nutnosti svázat metody volané programem (tedy určit, která konkrétní metoda bude volána) nikoli ve fázi kompilace, ale během provádění programu, což zabere další čas. Dynamická vazba je přitom ve skutečnosti vyžadována ne pro více než 20 % hovorů, ale některé OOP jazyky ji používají neustále. Značná hloubka abstrakce Vývoj OOP často vede k vytváření „vrstvených“ aplikací, kde se provedení požadované akce objektem redukuje na mnoho volání objektů nižší úrovně. V takové aplikaci je spousta volání metod a návratů metod, což samozřejmě ovlivňuje výkon. Dědičnost rozmaže kód Kód související s „konečnými“ třídami hierarchie dědičnosti, které program obvykle přímo používá, se nachází nejen v těchto třídách samotných, ale také v třídách jejich předků. Metody patřící do stejné třídy jsou ve skutečnosti popsány v různých třídách. To vede ke dvěma nepříjemným věcem: Zapouzdření snižuje rychlost přístupu k datům Zákaz přímého přístupu k polím tříd zvenčí vede k nutnosti vytvářet a používat přístupové metody. A psaní, kompilace a provádění přístupových metod je spojeno s dodatečnými náklady. Dynamická tvorba a destrukce objektů Dynamicky vytvářené objekty jsou obvykle alokovány na haldě , což je méně efektivní než jejich umístění na zásobník a navíc pro ně staticky alokovat paměť v době kompilace.

Navzdory těmto nedostatkům Booch tvrdí, že výhody používání OOP jsou větší. Kromě toho, zvýšení výkonu díky lepší organizaci kódu OOP, říká, v některých případech kompenzuje další režii na běh programu. Můžete si také všimnout, že mnoho efektů snížení výkonu lze vyhladit nebo dokonce úplně odstranit díky vysoce kvalitní optimalizaci kódu kompilátorem. Například výše uvedené snížení rychlosti přístupu k polím tříd kvůli použití přístupových objektů je eliminováno, pokud kompilátor místo volání přístupového objektu používá inline substituci (moderní kompilátory to dělají zcela sebevědomě).

Kritika OOP

Navzdory některým výtkám vůči OOP se toto paradigma v současné době používá v naprosté většině průmyslových projektů. Nelze však předpokládat, že OOP je nejlepší programovací technika ve všech případech.

Kritika OOP:

Pokud se pokusíme klasifikovat kritiku OOP, můžeme zdůraznit několik aspektů kritiky tohoto přístupu k programování.

Kritika OOP reklamy Explicitní nebo implikované ve spisech některých OOP propagandistů, stejně jako v propagačních materiálech pro "objektově orientované" vývojové nástroje, je kritizována představa objektového programování jako nějakého druhu všemocného přístupu, který magicky eliminuje složitost programování. Jak mnoho lidí, včetně výše zmíněných Brooks a Dijkstra, poznamenalo, „neexistuje žádná stříbrná kulka“ – bez ohledu na to, jakého programovacího paradigmatu se vývojář drží, vytvoření netriviálního komplexního softwarového systému vždy vyžaduje značné investice intelektuálních zdrojů a času. Z nejkvalifikovanějších odborníků v oblasti OOP zpravidla nikdo nepopírá platnost tohoto typu kritiky. Zpochybnění efektivity rozvoje OOP Kritici zpochybňují tezi, že vývoj objektově orientovaných programů vyžaduje méně zdrojů nebo vede k lepšímu softwaru. Je provedeno srovnání nákladů na vývoj různými metodami, na základě čehož dochází k závěru, že OOP nemá v tomto směru žádné výhody. Vzhledem k extrémní složitosti objektivního srovnávání různého vývoje jsou taková srovnání přinejmenším diskutabilní. Na druhou stranu se ukazuje, že stejně kontroverzní jsou i prohlášení o účinnosti OOP. Výkon objektově orientovaných programů Poukazuje se na to, že řada „vrozených vlastností“ technologií OOP činí programy postavené na jejich základě technicky méně efektivní ve srovnání s podobnými neobjektovými programy. I když se nepopírá, že pro spouštění programů OOP skutečně existuje další režie (viz část Výkon výše), kritici často zveličují výkon. V moderních podmínkách, kdy jsou technické možnosti počítačů extrémně velké a neustále rostou, je pro většinu aplikačních programů technická efektivita méně významná než funkčnost, rychlost vývoje a udržovatelnost. Pouze u velmi omezené třídy programů (software vestavěných systémů, ovladače zařízení, software nízké úrovně, vědecký software) zůstává výkon kritickým faktorem. Kritika jednotlivých technologických řešení v OOP jazycích a knihovnách Tato kritika je četná, ale netýká se OOP jako takového, ale přijatelnosti a použitelnosti v konkrétních případech určitých implementací jeho mechanismů. Jedním z oblíbených předmětů kritiky je jazyk C++, který je jedním z nejběžnějších průmyslových jazyků OOP.

Objektově orientované jazyky

Mnoho moderních jazyků je speciálně navrženo pro usnadnění objektově orientovaného programování. Techniky OOP však můžete aplikovat na neobjektově orientovaný jazyk a naopak, použití objektově orientovaného jazyka neznamená, že se kód automaticky stane objektově orientovaným.

Objektově orientovaný jazyk (OOL) obvykle obsahuje následující sadu prvků:

Některé jazyky přidávají k určené minimální sadě určité další funkce. Mezi nimi:

Některé jazyky plně dodržují principy OOP - v nich jsou všechny hlavní prvky objekty, které mají stav a související metody. Příklady takových jazyků jsou Smalltalk , Eiffel . Existují hybridní jazyky, které kombinují objektový subsystém jako celek se subsystémy jiných paradigmat jako „dva nebo více jazyků v jednom“, což umožňuje kombinovat objektové modely s ostatními v jednom programu a stírat hranici mezi objektově orientovanými a další paradigmata kvůli nestandardním funkcím, které balancují mezi OOP a jinými paradigmaty (jako je vícenásobné odeslání , parametrické třídy, schopnost manipulovat s metodami tříd jako s nezávislými objekty atd.). Příklady takových jazyků jsou CLOS , Dylan , OCaml , Python , Ruby , Objective-C . Nejběžnější jazyky však kromě tradičnější imperativní sémantiky zahrnují emulaci objektového modelu. Alan Kay nazval takové jazyky „ aglutinací rysů “  na rozdíl od „ krystalizace stylu “ jazyků , které přímo ztělesňují určité paradigma [26] . Příklady takových jazyků jsou Simula , C++ , Visual Basic , Delphi , Modula , Modula-2 , Java , C# , PHP .  

Viz také

Poznámky

  1. ↑ Butch, 1998 .
  2. ↑ Edsger W. Dijkstra Programování jako lidská činnost. 1979 (EWD117) . Získáno 26. února 2019. Archivováno z originálu 7. srpna 2018.
  3. ↑ L. V. Uspensky. "Slovo o slovech". - 5. vyd. - L .: Dětská literatura (pobočka Leningrad), 1971 . Staženo 26. února 2019. Archivováno z originálu dne 24. února 2019.
  4. ↑ 1 2 3 Pierce, 2012 .
  5. ↑ Abadi, Cardelli, 1994 .
  6. ↑ Cardelli, 1991 .
  7. ↑ Cardelli, 1985 .
  8. ↑ Pierce, 2012 .
  9. ↑ Objektově orientované programování ve standardním ML . Datum přístupu: 3. února 2016. Archivováno z originálu 14. ledna 2016.
  10. ↑ Cardelli, 1985 , 1.3. Druhy polymorfismu, str. 6.
  11. ↑ Castagna, Ghelli, Longo. Počet přetížených funkcí s podtypováním.  // Informace a výpočty. - Akademický tisk, 1995. - T. 117 , no. 1 . — S. 115–135 . - doi : 10.1006/inco.1995.1033 .
  12. ↑ Castagna. Objektově orientované programování: Jednotný základ . - Birkhäuser, 1996. - S. 384. - ISBN 978-0-8176-3905-1 .
  13. ↑ Pierce, 2012 .
  14. ↑ Nikdo se neshodne na tom, co je OO . Získáno 14. července 2012. Archivováno z originálu 14. července 2012.
  15. ↑ Timothy Budd. Objektově orientované programování v akci = Úvod do objektově orientovaného programování. - Petrohrad. : "Petr", 1997. - 464 s. - (V akci). - 6000 výtisků.  — ISBN 5-88782-270-8 .
  16. ↑ Roger King, Moje kočka je objektově orientovaná
  17. ↑ Je však třeba poznamenat, že použití přístupových objektů podkopává zapouzdření, které není o skrytí všech členů objektu, ale o použití vnitřního stavu objektu pouze pro práci, kterou přímo vykonává. V OOP programátor pracuje s pojmy, ne s daty.
  18. ↑ Butch, 1998 , str. 276-278.
  19. ↑ Thomas E. Potok, Mladen Vouk, Andy Rindos. Analýza produktivity objektově orientovaného softwaru vyvinutého v komerčním prostředí  //  Software – praxe a zkušenosti. - 1999. - Sv. 29, č. 10 . - S. 833-847.
  20. ↑ CJ Date, Úvod do databázových systémů, 6. vydání, strana 650
  21. ↑ STLport: Rozhovor s A. Stepanovem . Získáno 27. března 2007. Archivováno z originálu 4. března 2009.
  22. ↑ „Žádná stříbrná kulka. Essence and Accidents of Software Engineering“ (Computer Magazine, duben 1987)
  23. ↑ EWD 1175: Silné stránky akademického podniku . Získáno 6. srpna 2007. Archivováno z originálu dne 31. října 2007.
  24. ↑ Proč selhalo objektově orientované programování . Získáno 22. září 2010. Archivováno z originálu 23. září 2010.
  25. ↑ Steve Yegge. Poprava v Království podstatných jmen . Získáno 9. září 2015. Archivováno z originálu 5. září 2015.  (anglicky)  — částečný překlad Archivováno 2. května 2015 na Wayback Machine  (ruština)
  26. ↑ Alan Kay . Raná historie Smalltalku . — Apple Computer, ACM SIGPLAN Notices, svazek 28, č. 3, březen 1993.

Literatura

Odkazy

Recenze Kritika OOP
  Přejděte na položku Wikidata  Slovníky a encyklopedie