Úvod do objektově orientovaného programování. Objektově orientované jazyky. Základy objektově orientovaného programování

Proč je ve většině projektů preferováno objektově orientované programování? OOP nabízí efektivní způsob, jak se vypořádat s jejich složitostí. Namísto zobrazení programu jako sekvence spustitelných instrukcí jej představuje jako skupinu objektů s určitými vlastnostmi a provádí s nimi určité akce. Výsledkem jsou čistší, spolehlivější a udržitelnější aplikace.

Základní principy se objevily, protože byla objevena omezení v již existujících přístupech. Patří mezi ně neomezený přístup k datům a velké množství připojení, které omezují provádění změn. Jejich povědomí a důvody jsou důležité pro pochopení toho, co je OOP v programování a jaké jsou jeho výhody.

Procesní jazyky

C, Pascal, FORTRAN a podobné jazyky jsou procedurální. To znamená, že každý z jejich operátorů nařídí počítači, aby něco udělal: přijal data, sečetl čísla, vydělil šesti, zobrazil výsledek. Aplikace v procedurálním jazyce je seznam instrukcí. Pokud je malý, není vyžadován žádný jiný organizační princip (často nazývaný paradigma). Programátor vytvoří seznam instrukcí a počítač je provede.

Rozdělení do funkcí

Jak se aplikace zvětšují, seznam se stává nepraktickým. Jen málo lidí dokáže porozumět více než několika stovkám pokynů, dokud nejsou seskupeny. Z tohoto důvodu se funkce stala způsobem, jak učinit aplikace pro jejich tvůrce srozumitelnějšími. V některých jazycích může být stejný koncept nazýván podprogram nebo procedura.

Aplikace je rozdělena do funkcí, z nichž každá má jasně definovaný účel a rozhraní.

Myšlenku dělení procedur lze rozšířit jejich seskupením do většího objektu zvaného modul, ale princip je podobný: seskupování komponent, které provádějí seznamy instrukcí.

Rozdělení na funkce a moduly je jedním ze základních kamenů strukturovaného programování, které bylo dominantním paradigmatem několik desetiletí před příchodem OOP.

Problémy strukturovaného programování

Jak se aplikace zvětšovaly, strukturované programování začalo mít potíže. Projekty byly příliš složité. Jízdní řády posunuty. Zapojilo se více programátorů. Složitost rostla. Náklady vyletěly do nebes, harmonogram se posunul dále a nastal kolaps.

Analýza příčin těchto selhání ukázala nedostatky procesního paradigmatu. Bez ohledu na to, jak dobře je implementován přístup ke strukturovanému programování, velké aplikace se stávají příliš složitými.

Jaké jsou příčiny těchto problémů spojených s procedurálními jazyky? Za prvé, funkce mají neomezený přístup ke globálním datům. Za druhé, nesouvisející postupy a hodnoty dobře nemodelují skutečný svět.

Při zvažování těchto otázek v kontextu programu zásob je jedním z nejdůležitějších globálních datových prvků populace účetních jednotek. Mohou k nim přistupovat různé funkce pro zadání nové hodnoty, její zobrazení, změnu atd.

Neomezený přístup

V programu napsaném například v C existují dva typy dat. Lokální jsou skryty uvnitř funkce a jiné procedury je nepoužívají.

Když dvě nebo více funkcí potřebují přístup ke stejným datům, musí být tato data globální. Jedná se například o informace o zohledňovaných položkách. Globální data jsou přístupná jakýmkoliv postupem.

Velký program má mnoho funkcí a mnoho globálních prvků. Problém s procedurálním paradigmatem je v tom, že vede k ještě většímu potenciálnímu spojení mezi nimi.

Takový velký počet spojení vyvolává několik problémů. Za prvé, je obtížné pochopit strukturu programu. Za druhé, je obtížné provádět změny. Změna globální datové položky může vyžadovat úpravy všech funkcí, které k ní přistupují.

Například v účetním programu někdo rozhodne, že kód účtované položky by se neměl skládat z 5 číslic, ale z 12. To bude vyžadovat změnu z krátkého na dlouhý. Nyní je třeba změnit funkce související s kódem, aby fungovaly s novým formátem.

Když se prvky ve velké aplikaci změní, je obtížné určit, které procedury k nim mají přístup. Ale i když se to zjistí, jejich změna může vést k nesprávnému fungování jiných globálních dat. Vše souvisí se vším, takže změna na jednom místě se projeví v jiném.

Simulace reálného světa

Druhým a důležitějším problémem procedurálního paradigmatu je, že jeho uspořádání jednotlivých dat a funkcí nemodeluje dobře věci v reálném světě. Zde máme co do činění s předměty, jako jsou lidé a auta. Nevypadají jako data nebo funkce. Složité reálné objekty mají vlastnosti a chování.

Atributy

Příklady atributů (někdy nazývaných vlastnosti) pro lidi jsou barva očí a pracovní zařazení a pro auta výkon a počet dveří. Jak se ukazuje, atributy v reálném světě jsou ekvivalentní datům v programu. Mají specifické významy, například modrá (barva očí) nebo čtyři (počet dveří).

Chování

Chování je to, co objekty v reálném světě produkují v reakci na nějaký druh vlivu. Pokud požádáte svého šéfa o zvýšení platu, odpověď bude „ano“ nebo „ne“. Pokud sešlápnete brzdu, auto se zastaví. Mluvení a zastavení jsou příklady chování. Chování je jako procedura: je povoláno něco udělat a ono to udělá. Data a funkce samy o sobě tedy efektivně nemodelují objekty reálného světa.

Řešení

Objekt v OOP je reprezentován jako kolekce dat a funkcí. Pouze procedury, nazývané členské funkce v C++, vám umožňují získat jeho hodnoty. Data jsou skryta a chráněna před změnami. Hodnoty a funkce jsou zapouzdřeny do jednoho celku. Zapouzdření a skrytí jsou hlavními pojmy v popisu OO jazyků.

Pokud potřebujete změnit data, přesně víte, které funkce s nimi interagují. Žádné jiné procedury k nim nemají přístup. To usnadňuje psaní, ladění a údržbu programu.

Aplikace se obvykle skládá z více objektů, které se vzájemně ovlivňují voláním členských funkcí.

Dnes nejrozšířenějším programováním) je C++ (plus-plus). Java postrádá některé funkce, jako jsou ukazatele, šablony a vícenásobná dědičnost, takže je méně výkonná a všestranná než C++. C# ještě nedosáhlo popularity C++.

Je třeba poznamenat, že takzvané členské funkce v C++ se v některých jiných objektově orientovaných jazycích, jako je Smalltalk, nazývají metody. Datové prvky se nazývají atributy. Volání metody na objektu znamená odeslání zprávy.

Analogie

Objekty si můžete představit jako oddělení společnosti. Ve většině organizací zaměstnanci jeden den nepracují v HR, druhý den mzdy a pak tráví týden maloobchodem. Každé oddělení má své vlastní zaměstnance s jasně přidělenými odpovědnostmi. Nechybí ani vlastní data: mzdové ukazatele, tržby, evidence zaměstnanců atd. Lidé v odděleních pracují s vlastními informacemi. Oddělení společnosti tak usnadňuje sledování jejích aktivit a zachování integrity dat. Účetní oddělení zodpovídá za Pokud potřebujete znát celkovou výši vyplacených mezd v jižní pobočce v červenci, není třeba se prohrabávat archivem. Stačí odeslat poznámku odpovědné osobě, počkat, až tato osoba získá přístup k datům a odešle odpověď s požadovanými informacemi. Tím je zajištěno dodržování předpisů a nepřítomnost vnějšího rušení. Stejně tak objekt v OOP poskytuje organizaci pro aplikaci.

Je třeba mít na paměti, že objektová orientace se netýká podrobností o tom, jak program funguje. Většina příkazů C++ odpovídá operátorům v procedurálních jazycích, jako je C. Ve skutečnosti jsou členské funkce v C++ velmi podobné funkcím v C. Pouze širší kontext určí, zda je příkaz procedurální nebo objektově orientovaný.

Objekt v OOP: Definice

Při zvažování problému programování v objektově orientovaném jazyce vyvstává místo otázek o jeho rozdělení na samostatné funkce problém jeho rozdělení na objekty. OOP myšlení výrazně usnadňuje vývoj aplikací. K tomu dochází v důsledku podobnosti mezi softwarem a skutečnými objekty.

Jaké věci se stávají objekty v OOP? Níže jsou uvedeny typické kategorie.

Fyzický objekt v OOP je:

  • doprava v proudových modelech;
  • elektrické prvky v programech pro návrh obvodů;
  • země v ekonomickém modelu;
  • letadla v systému řízení letového provozu.

Prvky počítačového prostředí uživatele:

  • Jídelní lístek;
  • okno;
  • grafika (čára, obdélník, kruh);
  • klávesnice, myš, tiskárna, diskové jednotky.
  • dělníci;
  • studenti;
  • klienti;
  • prodejců.
  • Účetní kniha;
  • soukromé podnikání;
  • slovník;
  • tabulka zeměpisných šířek a délek obydlených oblastí.

Spojení mezi objekty reálného světa a OOP bylo výsledkem kombinace funkcí a dat: způsobily revoluci v programování. V procedurálních jazycích taková těsná korespondence neexistuje.

Třída

Objekty v OOP jsou členy tříd. Co to znamená? Programovací jazyky mají vestavěné datové typy. Typ int, tedy celé číslo, je v C++ předdefinován. Můžete deklarovat tolik proměnných int, kolik chcete.

Sada objektů stejné třídy je definována podobně. Definuje funkce a data obsažená ve svých objektech, aniž by je vytvářela, stejně jako int nevytváří proměnné.

Třída v OOP je popisem řady podobných objektů. Prince, Sting a Madonna jsou zpěváci. Neexistuje nikdo s tímto jménem, ​​ale lidé se tak mohou nazývat, pokud mají odpovídající vlastnosti. Objekt OOP je instancí třídy.

Dědictví

V životě se třídy dělí na podtřídy. Například zvířata se dělí na obojživelníky, savce, ptáky, hmyz atd.

Princip tohoto druhu dělení spočívá v tom, že každá podtřída má společné vlastnosti s třídou, ze které pochází. Všechna auta mají kola a motor. To jsou určující vlastnosti vozidel. Kromě obecných charakteristik má každá podtřída své vlastní charakteristiky. Autobusy mají dostatek míst k sezení a kamiony mají prostor pro přepravu těžkých nákladů.

Podobně se základní třída může stát rodičem několika odvozených podtříd, které lze definovat tak, aby sdílely své vlastnosti a zároveň přidaly své vlastní. Dědičnost je jako funkce, která zjednodušuje procedurální program. Pokud několik částí kódu dělá téměř totéž, můžete extrahovat společné prvky a vložit je do jediné procedury. Tři oblasti aplikace mohou volat funkci k provádění běžných akcí, ale mohou také provádět své vlastní operace. Podobně základní třída obsahuje data společná pro skupinu odvozených tříd. Stejně jako funkce zkracuje dědičnost objektově orientovaný program a objasňuje vztahy mezi jeho prvky.

Znovu použít

Jakmile je třída vytvořena a odladěna, lze ji sdílet s ostatními programátory pro opětovné použití v jejich vlastních aplikacích. Je to jako knihovna funkcí, které lze zahrnout do různých aplikací.

V OOP je dědičnost rozšířením myšlenky opětovného použití. Z existující třídy, aniž byste ji měnili, můžete vytvořit novou s přidáním dalších funkcí. Snadné opětovné použití stávajícího softwaru je důležitou výhodou OOP. Předpokládá se, že to zajistí vyšší návratnost počáteční investice.

Vytváření nových datových typů

Objekty jsou užitečné pro vytváření nových datových typů. Předpokládejme, že program používá dvourozměrné hodnoty (například souřadnice nebo zeměpisná šířka a délka) a chcete s nimi vyjádřit operace pomocí aritmetických operací:

pozice1 = pozice + počátek,

kde a původ jsou dvojice nezávislých číselných hodnot. Vytvořením třídy, která obsahuje tyto dvě hodnoty, a deklarováním jejích proměnných jako objektů vznikne nový datový typ.

Polymorfismus, přetížení

Operátory = (rovná se) a + (plus) používané v poziční aritmetice výše nefungují stejným způsobem jako s vestavěnými typy, jako je int. Objekty pozic atd. nejsou předdefinovány, ale jsou definovány programově. Jak tito operátoři vědí, jak s nimi zacházet? Odpověď zní, že jim lze přiřadit nové vzorce chování. Tyto operace budou členskými funkcemi třídy Position.

Použití operátorů nebo procedur v závislosti na tom, s čím operují, se nazývá polymorfismus. Když stávající operátor, jako je + nebo =, dostane možnost pracovat s novým datovým typem, říká se, že je přetížený. Přetížení v OOP je typ polymorfismu. Je to jeho důležitá vlastnost.

Kniha o OOP „Object-Oriented Programming for Dummies“ umožní každému seznámit se s tímto tématem podrobněji.

v podstatě využíval paradigma normativního programování – cílem bylo vytvořit kód, který by vhodně fungoval na datech. Tento přístup je dobrý pro řešení malých problémů, ale při pokusu o vytvoření vytváří mnoho neřešitelných problémů velké softwarové systémy.

Jedna z alternativ direktivní programování je objektově orientované programování, který opravdu pomáhá vyrovnat se s nelineárně rostoucí složitostí programů s rostoucím objemem. Neměli bychom však dospět k závěru, že použití paradigmatu objektově orientovaného programování zaručuje úspěšné řešení všech problémů.

Abyste se stali profesionálem v programování, potřebujete talent, kreativitu, inteligenci, znalosti, logiku, schopnost budovat a používat abstrakce a hlavně zkušenosti.

V této části budeme pokračovat v úvodu do základních pojmů objektově orientovaného programování, který jsme začali v první kapitole knihy. Nejprve budou probrány koncepty OOP společné pro různé programovací jazyky a poté jejich implementace v jazyce Java.

Měli byste si být vědomi toho, že kurz objektově orientovaného programování je vyučován vysokoškolským studentům v průběhu celého semestru, a proto níže uvedený materiál představuje pouze velmi základní úvod do světa OOP. Mnohem úplnější zpracování mnoha problémů souvisejících s objektově orientovaným návrhem, inženýrstvím a programováním je obsaženo v knize a ve třetí kapitole knihy můžete najít velmi jasný popis všech objektově orientovaných aspektů jazyk Java.

Základní koncepty OOP

Objektově orientované programování nebo OOP (objektově orientované programování) - metodika programování založené na reprezentaci programu jako kolekce objektů, z nichž každý je implementací určitého typu, pomocí mechanismu přeposílání zpráv a třídy organizované v dědičná hierarchie.

Ústředním prvkem OOP je abstrakce. Data jsou převedena na objekty pomocí abstrakce a sekvence zpracování těchto dat se změní na sadu zpráv předávaných mezi těmito objekty. Každý z objektů má své vlastní jedinečné chování. S objekty lze zacházet jako s konkrétními entitami, které reagují na zprávy, které jim přikazují provést nějakou akci.

OOP se vyznačuje následujícími principy (podle Alana Kaye):

  • vše je předmět;
  • výpočty se provádějí prostřednictvím interakce (výměny dat) mezi objekty, kdy jeden objekt vyžaduje, aby jiný objekt provedl nějakou akci; objekty interagují odesíláním a přijímáním zpráv; zpráva je požadavek na provedení akce doplněný o sadu argumentů, které mohou být potřebné při provádění akce;
  • každý objekt má nezávislou Paměť, který se skládá z dalších objektů;
  • každý objekt je zástupcem třídy, která vyjadřuje obecné vlastnosti objektů daného typu;
  • nastavit ve třídě funkčnost(chování objektu); tedy všechny objekty, které jsou instancemi stejné třídy, mohou provádět stejné akce;
  • třídy jsou organizovány do jediné stromové struktury se společným kořenem, tzv dědičná hierarchie; paměť a chování spojené s instancemi konkrétní třídy jsou automaticky dostupné jakékoli třídě níže v hierarchickém stromu.

Definice 10.1. Abstrakce- způsob řešení problému, při kterém jsou objekty různého druhu sjednoceny společným konceptem (konceptem), a poté jsou seskupené entity považovány za prvky jediné kategorie.

Abstrakce umožňuje oddělit logický význam fragmentu programu od problému jeho implementace, dělení vnější popis(rozhraní) objektu a jeho vnitřní organizace(implementace).

Definice 10.2. Zapouzdření- technika, ve které se v něm skrývají informace, které jsou z hlediska rozhraní objektu nevýznamné.

Definice 10.3. Dědictví- vlastnost objektů, jejichž prostřednictvím instance třídy získávají přístup k datům a metodám tříd předků, aniž by je předefinovaly.

Dědičnost umožňuje různým datovým typům sdílet stejný kód, což má za následek menší kód a větší funkčnost.

Definice 10.4.

Ahoj všichni.

Týden článků o Habrém věnovaný OOP. Poslední článek ve mně vyvolal spoustu emocí a bohužel i velmi špatné emoce. Článek se mi opravdu nelíbil. Proč? Protože to vyvolává některé negativní emoce ohledně používání OOP. Emoce jsou způsobeny pouze tím, že člověk plně nechápe plnou sílu OOP a chce všechny přesvědčit, že OOP je zlo. Nejsmutnější je, že lidé začnou naslouchat a vyhazují hrozné argumenty, které nemají nic společného s realitou. Myslím, že takové články jsou pro studenty kontraindikovanější než GoF, který bych dal co nejdříve. :)

Pojďme začít.

Co je OOP? OOP je jak OO programování, tak design. Jedno bez druhého je téměř bezvýznamné. Vytvořil OOP pro navrhování/programování softwarových produktů. Ne pro procesní modelování. Ne pro navrhování protokolů, ale speciálně pro softwarové produkty, pro jejich implementaci. Zjednodušit systém, který bude implementovat protokol nebo obchodní proces nebo něco jiného.

Když začnete používat OOP, první věc, kterou byste měli udělat, je začít používat objektové myšlení. Už jsem jednou řekl, že to je největší problém OOP naučit se objektivně myslet. A je velmi důležité naučit se, jak to udělat co nejdříve (GoF s analogiemi jako most, konstruktor, fasáda s tím hodně pomůže). Pomocí objektového myšlení můžete snadno navrhovat složité systémy Pomocí objektového myšlení můžete snadno vyřešit jakýkoli problém (je velmi důležité, aby jakýkoli problém s návrhem/programováním, pokud jej lze v zásadě vyřešit absolutně jakýkoli) provozováním s objekty a interakcí mezi jim. Tito. OOP bez objektového myšlení vám nedovolí začít využívat plnou sílu a sílu OOP.

Pojďme dále. Je tedy pro nás důležité objektivně myslet, abychom našli abstrakce objektů, které potřebujeme k řešení našich problémů. Pokud jsou analogie a abstrakce zvoleny dobře, pak vidíme velmi jasný obraz, který nám umožňuje rychle pochopit, co se v systému děje. A zde si začínáme pamatovat na dědičnost a polymorfismus. Tyto dva nástroje jsou potřebné pro snadné škálování systému bez duplikace kódu. Ale síla těchto mechanismů závisí na tom, jak dobře si vyberete abstrakce a analogie. Pokud vám vaše objektové myšlení neumožňuje vytvořit pohodlný rozklad objektů, pak vám nepomůže dědičnost a polymorfismus. Tito. dědičnost a polymorfismus nejsou nic jiného než nástroje, které umožňují vyřešit problém škálování systému.

Jak tyto nástroje fungují? Ano, je to jednodušší než tuřín v páře, protože je založen na věcech, které jsou nám známé. Mám rád jednoduché příklady ze života:

1. Dědictví. Je tam pekař. K dispozici je elektrická a plynová trouba. Vaším úkolem je simulovat proces vaření pekařem v každé z pecí. Při řešení problému čelně, budeme mít hodně duplicitních kódů kvůli tomu, že proces přenosu jídla do trouby a práce s troubami jsou u obou pecí shodné. Ale pokud zapneme myšlení objektů a vzpomeneme si na nástroj dědičnosti, dostaneme něco jako následující (příliš líní na kreslení diagramu, omlouvám se):
K dispozici je sporák (abstraktní sporák). Má chování - zapnout, vypnout, zvýšit nebo snížit teplotu, něco vložit, něco vyndat a stav - teplota v troubě, zapnuto nebo vypnuto. Jedná se o vynikající příklad abstraktního objektu, který se řídí principy zapouzdření (určitě se jimi budu řídit při implementaci). A je tu pekař, konkrétní pekař Ivan. Ví, jak pracovat s abstraktní pecí. Tito. sledovat teplotu, zapínat a vypínat atd. rozuměl jsi. Síla dědictví spočívá v tom, že našeho Ivana nemusíme přepisovat na každý z kamen, ať už je to elektrický nebo plynový sporák. Myslím, že je všem jasné proč? Ukázalo se, že nástroj byl aplikován správně.
2. Polymorfismus. Pece fungují jinak. Plynový sporák spotřebovává plyn, elektrický sporák spotřebovává elektřinu. Pomocí polymorfismu můžeme snadno změnit chování v nástupcích abstraktní pece.
3. Zapouzdření. Hlavní věc na zapouzdření je, že nemusím vědět, co se děje uvnitř mé trouby. Řekněme, že nevolám metodu pro zapnutí trouby, ale změním její vlastnost enabled na true. Co se stane v tuto chvíli? Pokud nebude dodržena zásada zapouzdření, tak budu nucen říct kamnům, aby začali spotřebovávat palivo, protože... Zapnul jsem tě. Tito. pekař ví, že trouba spotřebovává palivo a ví, jak trouba funguje. Nebo například nemůžeme nastavit teplotu trouby pod nebo nad určitou úroveň. Pokud nedodržíme princip zapouzdření, tak budeme muset troubě říct, aby zkontrolovala aktuální teplotu, bude to takto fungovat? Tito. Pekař zase ví o troubě příliš mnoho. Getters a setters jsou jazykové nástroje, které nám pomáhají snadno implementovat sledování změn stavu. Všechno. Pokud jsou getry a settery prázdné, tak by to na mé úrovni abstrakce mělo být. Gettery a settery nemohou zasahovat do implementace zapouzdření; návrhář/programátor může zapouzdření implementovat křivě.

V tomto příkladu je dobře zvolena úroveň abstrakce. Každý se stará o své věci, všechny tři pilíře OOP pracují pro slávu. Jakmile ale zvolím špatné abstrakce, začíná skutečná noční můra. A dokonce existují standardy kontrolního seznamu, které vám pomohou pochopit, zda jste abstrakce zvolili dobře a zda je váš rozklad správný ve směru, kterým jdete (SOLID).

Začali také přidávat abstrakci jako další pilíř OOP. Myslím, že je to pravděpodobně pravda, ale opravdu to zavání CEP.

Zaujaly mě také výroky o typizaci. S tím, se kterým z dědiců aktuálně spolupracujete, totiž problémy nejsou. Pokud je pro vás na současné úrovni abstrakce důležité používat troubu, pak je pro vás jedno, co to je. Pořídíte si sporák? Řešíte své problémy? To a to... Proč si myslíte, že se jedná o dynamické psaní, mi není jasné. Chtěli jste péct? Vzít to. Potřebujete elektrický? No pardon, plyn vám už nebude vyhovovat.

Zbývající příklady, které byly uvedeny v článku, který mě zaujal, jsou jen příklady nechutně zvolené abstrakce a analogie v rámci daného úkolu. Tečka.

Samostatně o DTO. DTO je vzor. Umožňuje vytvořit objekt, který přenese informace do jiné vrstvy, jiného systému, zkrátka někam něco přenese. Proč ho nemohu považovat za předmět, je mi obecně záhadou. Kde je ten rozpor? Je to pouze kontejner? No a co?? Jedná se o objekt v rámci mnou uvažovaného objektového modelu na dané úrovni abstrakce, kde DTO je objekt a součást rozkladu.

Také není jasné, co říci o jazycích. Mohu navrhovat software pomocí objektově orientovaného přístupu bez ohledu na jazyk. Ale pokud jazyk neimplementuje základní nástroje pro práci s objekty, pak pro mě bude velmi obtížné nebo nemožné implementovat systém, který jsem navrhl.

Také říkají, že některé věci nelze reprezentovat ve formě objektů a jejich interakcí. Jsem si jist, že tomu tak není. Stačí si vybrat správnou úroveň abstrakce. Ať už jde o implementaci protokolu, vrstvy pro přístup k databázi, propojovacích pluginů, správce úloh, obchodního procesu, systému návrhu obchodních procesů atd. cokoli může být reprezentováno jako objekty a jejich interakce. Vše lze implementovat jako objekty a interakce mezi nimi. Zda je to dobře nebo špatně, nejčastěji závisí pouze na vaší schopnosti objektivně myslet.

Shrnout. Pokud nerozumíte síle OOP, pak s největší pravděpodobností budete muset rozvíjet objektové myšlení.

P.S. V komentářích k minulému článku jsem při oslovování některých lidí zjevně zašel příliš daleko. Omlouvám se.

Událost v objektově orientovaném programování - Toto je zpráva, která se objeví na různých místech spustitelného kódu, když jsou splněny určité podmínky. Události jsou navrženy tak, aby bylo možné předvídat, jak bude software reagovat. K vyřešení tohoto problému jsou vytvořeny obslužné rutiny událostí: jakmile se program dostane do daného stavu, dojde k události, odešle se zpráva a obsluha tuto zprávu zachytí. V obecném případě není obsluze předáno nic nebo je předán odkaz na objekt, který inicioval (vytvořil) zpracovávanou událost. Ve zvláštních případech jsou hodnoty některých proměnných nebo odkazy na některé další objekty předány handleru, aby zpracování této události mohlo vzít v úvahu kontext události. Nejjednodušší událostí je událost, která signalizuje zahájení nebo dokončení nějaké procedury. Událost v podstatě hlásí změnu stavu nějakého objektu. Události jsou nejpřehledněji prezentovány v uživatelském rozhraní, kdy každá uživatelská akce generuje řetězec událostí, které jsou následně zpracovávány v aplikaci. V objektově orientované analýze je běžné používat stavový model k popisu dynamického chování objektů. Událost je přechod objektu z jednoho stavu do druhého. Interakce objektů se také provádí pomocí událostí: změna stavu jednoho objektu vede ke změně stavu jiného objektu a událost se ukazuje jako prostředek komunikace mezi objekty. Událost je toto. Dále jsou zvýrazněny čtyři aspekty události:

První řada příkladů událostí poskytuje skutečný životní cyklus objektu:

  • vytváření objektů;
  • zničení předmětu.

Složitější příklady událostí vznikají, když má objekt vnitřní stavy, které jsou popsány odpovídajícím přechodovým diagramem (z jednoho stavu do druhého).

Moderní objektově orientované programovací jazyky jsou C++ A Jáva. Od poloviny 90. let bylo implementováno mnoho objektově orientovaných jazyků vizuální programovací systémy, ve kterém je část rozhraní softwarového produktu vytvořena interaktivně, prakticky bez psaní programových příkazů. Objektově orientované systémy vizuálního designu zahrnují Visual Basic , Delphi , C++ Builder Visual C++. Jazyk VBA (Visual Basic for Applications) je jazykem aplikací Microsoft Office ( Vynikat , Slovo , Přístup , Power Point atd). VBA respektuje základní syntaxi jazyka a programovací pravidla Základní jazyky– dialekty, umožňuje vytvářet makra pro automatizaci provádění určitých operací a grafické uživatelské rozhraní, integraci mezi různými softwarovými produkty.

Cílem předmětu je poskytnout studentům pochopení základních principů objektově orientovaného programování v různých jazycích. Hlavním cílem kurzu je vychovat specialisty, kteří jsou zběhlí v moderních metodách a prostředcích vývoje algoritmů a programů, mají znalosti o moderní programovací technologie a ti, kteří jej umí aplikovat při řešení složitých aplikovaných problémů. Kurz přednášek je určen pro studenty s průpravou počítačová věda A programování v jazyce C.

Laboratorní práce

  1. Objektově orientované programování pro začátečníky
  2. Adobe Flash Lab 1: Kreslení a stínování
  3. Adobe Flash Lab 2: Symboly a jejich transformace
  4. Adobe Flash Lab 7: Framed Animation
  5. Adobe Flash Lab 9: Vložení objektu Flash do souboru HTML
  6. OOP v JavaScriptu. Laboratoř 1
    Základní pojmy a definice: objekt, metoda, vlastnosti, události
  7. OOP v JavaScriptu. Laboratoř 3. Formulář, tlačítko, textové pole
  8. OOP v JavaScriptu. Laboratoř 4. Datové typy. Proměnné. Aritmetické operace. Podmíněný provoz
  9. Úvod do rozhraní, objektů a nových funkcí MS Access 2007
  10. Laboratoř.2. Úprava databáze. Použití propojených tabulek. Vytváření formulářů a sestav

Literatura

  1. Bruno Babe. Jednoduché a jasné o Borland C++: Verze 4.0 a 4.5/Trans. z angličtiny -M.: BINOM, 1994. - 400 s.
  2. Buch G. „Objektově orientovaná analýza a návrh s příklady aplikací v C++“ Trans. z angličtiny - M.: Binom; Petrohrad: Něvský dialekt, 1999.
  3. . - M, 2000
  4. Gaisaryan S.S. „Objektově orientovaný design“ (http://www.mista.ru/oop_book/index.htm)
  5. Žukov A. „Studium C“ – Petrohrad: Peter, 2003.
  6. - Adobe Systems, 2010.
  7. Ishkova E. „C++ začátek programování“ - M.: Binom, 2001.
  8. Klochkov D.P., Pavlov D.A. Úvod do objektově orientovaného programování. / Vzdělávací a metodická příručka. - Ed. Nižegorsk Univerzita, 1995. - 70 s.
  9. Legalov A. „Výsledky expanze objektově orientovaného paradigmatu“ (http://www.softcraft.ru/paradigm/process/pr01.shtml
  10. Mukhortov V.V., Rylov V.Yu. (metodická příručka) - IMSO RAS, Novosibirsk, 2002
  11. Nemnyugin S., Perkolab L. „Učení TurboPascalu
  12. Pliskin M. „Evoluce programovacích jazyků“ (://2..cctpu../edu///lang/_09.)
  13. . - MEPhI, 2003
  14. Metodika objektově orientovaného programování (http://www.math.rsu.ru/smalltalk/sml-a.ru.html)
  15. Objektově orientované systémy: stav a perspektivy. Analytický přehled na základě materiálů OVUM. Recenze připravila A.G. Ivanov. (http://www.math.rsu.ru/smalltalk/obzornew.ru.html)
  16. Objektově orientované programovací jazyky. Srovnání s tradičními jazyky ​​(://.suvvbcourse/1.)
  17. Patrikeev Yu.N. „Objektově orientovaný design“ (http://www.object.newmail.ru/oop1.html)
  18. Patrikeev Yu.N. „Objektově orientované programování v Borland C++“ (http://www.object.newmail.ru/obj0.html)
  19. Principy objektově orientovaného programování - Přednášky o vizuálním objektově orientovaném návrhovém systému Delphi - Přednášky (http://blackman.wp-club.net/lection/visualprg.php)
  20. Styly programování (http://media.karelia.ru/~ftt/IVK/new2/Inflect/T_1_16.htm)
  21. Stroustrup B. Programovací jazyk C++(2. vyd.)./Přel. z angličtiny-M.: Radio and Communications, 1995. - 352 s.




Horní