Chcete-li změnit výchozí dokument, upravte soubor „blank.fb2“ ručně.

Předmluva 13

Java SE5 a SE6 14

Děkuji 14

Kapitola 1 Úvod do objektů 17

Rozvoj abstrakce 18

Objekt má rozhraní 20

Zařízení poskytuje služby 22

Skrytá implementace 23

Implementace opětovného použití 24

Dědictví 25

Zaměnitelné předměty a polymorfismus 29

Hierarchie jednoho kořene 33

Kontejnery 33

Parametrizované typy 35

Tvorba, použití předmětů a jejich životnost 36

Zpracování výjimek: Řešení chyb 38

Paralelní provedení 38

Java a internet 39

Kapitola 2. Vše je předmět 48

Všechny objekty musí být explicitně vytvořeny 49

Objekty se nikdy nemusí mazat 53

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

Metody, argumenty a návratové hodnoty 56

Vytvoření programu Java 58

Klíčové slovo statické 60

Náš první program Java 61

Komentáře a vložená dokumentace 64

Styl designu programu 70

Kapitola 3 Operátoři 71

Jednoduché tiskové příkazy 71

Java 72 prohlášení

Doslova 82

Java postrádá sizeof() 92

Obnovit 100

Kapitola 4 Ovládací struktury 101

Syntaxe foreach 105

přerušit a pokračovat 108

Špatný příkaz goto 109

Pokračovat 115

Kapitola 5 Inicializace a ukončení 116

Konstruktor zaručuje inicializaci 116

Přetížení metody 118

Úklid: dokončení a odvoz odpadu 130

Inicializace členů třídy 137

Inicializace konstruktoru 140

Inicializace pole 146

Pokračovat 151

Kapitola 6 Řízení přístupu 152

Balíček jako modul knihovny 153

Specifikátory přístupu Java 159

Rozhraní a implementace 163

Přístup do tříd 164

Pokračovat 167

Kapitola 7 Opětovné použití tříd 169

Syntaxe kompozice 170

Syntaxe dědičnosti 172

Delegace 176

Kombinace složení a dědičnosti 178

Složení versus dědictví 184

Převod typu nahoru 186

Konečné klíčové slovo 188

Pokračovat 197

Kapitola 8. Polymorfismus 198

Opět o vzestupné transformaci. . . > 199

Vlastnosti 201

Konstruktory a polymorfismus 208

Kovariance návratového typu 216

Vývoj s dědictvím 217

Pokračovat 220

Kapitola 9 Rozhraní 221

Abstraktní třídy a metody 221

Rozhraní 224

Oddělení rozhraní od implementace 227

Rozšíření rozhraní prostřednictvím dědičnosti 233

Rozhraní jako prostředek adaptace 236

Vnořená rozhraní 239

Rozhraní a továrny 242

Pokračovat 244

Kapitola 10 Vnitřní třídy 245

Vytváření vnitřních tříd 245

Komunikace s externí třídou 246

Konstrukce .this a .new 248

Vnitřní třídy a upcasting 249

Nejmenované interní třídy 253

Vnitřní třídy: proč? 261

Dědictví po vnitřních třídách 272

Je možné přepsat vnitřní třídu? 272

Místní vnitřní třídy 274

Pokračovat 276

Kapitola 11 Kolekce objektů 277

Parametrizované a typované kontejnery 277

Základní koncepty 280

Přidávání skupin prvků 281

Iterátory 288

Sada 294

Fronta 298

Prioritní fronta 299

Kolekce a iterátor 301

Idiom "metoda-adaptér" 306

Pokračovat 309

Kapitola 12 Řešení chyb a výjimek 310

Hlavní výjimky 310

Chytání 312 výjimek

Vytváření vlastních výjimek 314

Specifikace výjimek 319

Chytání svévolných výjimek 320

Java 328 standardní výjimky

Ukončení s konečně 330

Použití nakonec s návratem 334

Omezení při používání výjimek 336

Konstruktéři 339

Identifikace výjimky 343

Alternativní řešení 344

Pokračovat 351

Kapitola 13 Typové informace 352

Need for Dynamic Type Inference (RTTI) 352

Registrace továren 372

Reflexe: dynamické informace o třídě 376

Dynamickí mediátoři 380

Objekty s neurčitým stavem 384

Rozhraní a informace o typu 390

Pokračovat 394

Kapitola 14 Parametrizace 397

Jednoduchá parametrizace 398

Parametrizovaná rozhraní 404

Parametrizované metody 407

Stavba složitých modelů 419

Omezení 437

Metaznaky 440

Pokračovat 452

Kapitola 15 Pole 454

Vlastnosti polí 454

Pole jako objekt 456

Návrat pole 458

Vícerozměrná pole 460

Pole a parametrizace 463

Vytváření testovacích dat 465

Vytváření polí pomocí generátorů 470

Pole 474 Helper Toolkit

Pokračovat 482

Kapitola 16 Java I/O System 483

Soubor 484 tř

Vstup a výstup 489

Přidání atributů a rozhraní 491

Kurzy čtenářů a spisovatelů 494

RandomAccessFile: sám o sobě 497

Typické použití I/O toků 498

Čtečky a zapisovače souborů 505

Standardní I/O 507

Nový I/O (nio) 510

Komprese dat 531

Serializace objektů 536

Předvolby 553

Pokračovat 555

Kapitola 17 Paralelní provádění 557

Třída nití 559

Umělci 561

Sdílení zdrojů 578

Komunikace mezi vlákny 598

Vzájemné blokování 602

Nové komponenty knihovny 607

CountDownLatch 607

CyclicBarrier 609

PriorityBlockingQueue 614

Semafory 619

Modelování 624

Pokračovat 629

Abecední rejstřík 631

Úvod do objektů

Rozebíráme přírodu, transformujeme ji do pojmů a připisujeme jim význam, jak to děláme mnoha způsoby, protože jsme všichni účastníky dohody, která je platná ve společnosti svázané řečí a která je pevná ve struktuře jazyka. .. Nemůžeme komunikovat vůbec, s výjimkou souhlasu s organizací a klasifikací dat stanovenou touto dohodou.

Benjamin Lee Worf (1897-1941)

Za vznik počítačové revoluce vděčíme stroji. Proto se naše programovací jazyky snaží tomuto stroji přiblížit.

Počítače však zároveň nejsou ani tak mechanismy, jako spíše prostředky k zesílení myšlení („kola pro mysl“, jak rád říká Steve Jobs) a dalším prostředkem sebevyjádření. V důsledku toho se programovací nástroje přiklánějí méně ke strojům a více k naší mysli, stejně jako k jiným formám vyjádření lidských aspirací, jako je literatura, malba, sochařství, animace a kino. Objektově orientované programování (OOP) je součástí přeměny počítače na prostředek pro sebevyjádření.

Tato kapitola vás seznámí se základy OOP, včetně pohledu na hlavní metody vývoje softwaru. Tato a kniha obecně předpokládá, že máte zkušenosti s programováním v procedurálním jazyce, ne nutně v jazyce C. Pokud máte pocit, že vám před čtením této knihy chybí znalosti programování a syntaxe jazyka C, využijte multimediální seminář Thinking in C. který může stáhnout z webu

V březnu loňského roku se přihlásil na pobočku velké mezinárodní společnost v Samaře (ano. Od dětství mám hodně arogance a ctižádosti). V té době jsem znal html, css, java, javascript (základy), pascal, visualbasic6, mysql dotazy, php, hlavní myšlenka:c++. Javu jsem vůbec neznal. Nabídli mi práci designéra rozložení, ale odmítl jsem to. Pouze jako programátor! Pak mi dali seznam:

Bruce Eckel Thinking in Java (ruský překlad 2. vydání nebo originál 4. – čtěte oba)
-Steve McConnell - perfektní kód.
- Gang čtyř - Návrh vzoru. (toto je téměř ABC OOP)
-vysvětlete co nejjasněji rozdíl mezi j2se a j2ee.

v prosinci vyvstala potřeba. dostal práci v malém samarském webovém studiu. bylo okamžitě jasné, že se jedná o podvodníky, ale byla potřeba jakákoliv práce, kterou bych mohl ukázat budoucím zaměstnavatelům. nezaplatili platit (i když všechny uši byly sežrány sliby), ale kód byl uveden do konstrukčních standardů a hlavně naučili, kde hledat a co hledat v případě chyb, co málo věci se dají snadno minout.

Kromě literatury výše jsem absolvoval kurz intuit (teď chápu, že je svým rozsahem směšný, ale v zásadě tam základy jsou)

Na konci února jsem znovu zaslal svůj životopis a dostal pozvánku na pohovor. Rozhovorů bylo celkem 6 a trvaly 1,5 měsíce. Dvě z nich byly zadrženy prostřednictvím video spojení s Moskvou. Celý snímek připomínal film „Come Tomorrow“. Nakonec jsem ale dostal pracovní nabídku. Smlouva byla sepsána na částečný úvazek, protože. V té době jsem ještě neměl titul. Minulý měsíc jsem dostal diplom a smlouva byla obnovena na plný úvazek.

Současná pozice Soft-Engineer. Plat je více než uspokojivý. Včera ji v souvislosti s přechodem na plný úvazek zvedli o 30 %.

I v té podvodní kanceláři žádali o příklady práce. Prezentoval jsem svou práci na volné noze. Dokonce i práce v jiných jazycích jsou vždy mnohem lepší než žádná.

Ps: Modrý diplom z FYZY. Jsem úplný samouk, takže vše je ve vašich rukou. Zdarma mám pouze angličtinu ze školy (7 hodin týdně). ačkoli Američan, který k nám při své cestě kolem světa přijel, ho dobře nezná. Rozuměl jsem sotva polovině kvůli jeho přízvuku. ale v mém oddělení to není tak důležité. veškerá dokumentace v angličtině - naučíte se, i když jste nevěděli)))))

Zvláštní poděkování tomuto fóru. Vlastně jsem tady studoval- denně učil všechna témata, se kterými se setkáte)

KNIHOVNA PROGRAMŮ

Bruce Eckel

4. vydání

(^PPTER

Moskva - Petrohrad - Nižnij Novgorod - Voroněž Rostov na Donu - Jekatěrinburg - Samara - Novosibirsk Kyjev - Charkov - Minsk

BBK 32 973 2-018.1

Eckel B.

E38 Filosofie Java. Programátorská knihovna. 4. vyd. - Petrohrad: Petr, 2009. - 640 e.: nemocný. - (Série "Programátorská knihovna").

ISBN 978-5-388-00003-3

Javu nelze chápat tak, že se na ni díváme pouze jako na sbírku nějakých harakureshki - je nutné chápat úkoly tohoto jazyka jako konkrétní úkoly programování obecně. r3ia je kniha o problémech s programováním: proč se staly problémy a jaký přístup Java používá k jejich řešení. Vlastnosti jazyka probírané v každé kapitole jsou proto neoddělitelně spjaty s tím, jak se používají k řešení určitých problémů.

Tato kniha, která díky svému hlubokému a skutečně filozofickému podání složitosti jazyka odolala mnoha dotiskům v originále, je považována za jednu z nejlepších příruček pro programátory Java.

BBK 32.973.2-018.1 MDT 004.3

Publikační práva získaná po dohodě s Prentice Hall PTR.

Všechna práva vyhrazena. Žádná část této knihy nesmí být reprodukována v žádné formě bez písemného souhlasu držitelů autorských práv.

Informace obsažené v této knize byly získány ze zdrojů, které vydavatel považuje za spolehlivé. S ohledem na možné lidské nebo technické chyby však vydavatel nemůže zaručit absolutní správnost a úplnost poskytnutých informací a nenese odpovědnost za možné chyby související s používáním knihy.

ISBN 978-0131872486 © Prentice Hall PTR, 2006

ISBN 978-5-388-00003-3 © Překlad do ruštiny od Peter Press LLC, 2009

© Publikace v ruštině, design Piter Press LLC, 2009

Předmluva ................................13

Java SE5 a SE6 ..................................14

Poděkování ................................14

Kapitola 1 Úvod do objektů................................17

Vývoj abstrakce ........................18

Objekt má rozhraní................................20

Zařízení poskytuje služby ............................22

Skrytá implementace ................................23

Implementace Opětovné použití................................24

Dědictví ............................25

Zaměnitelné předměty a polymorfismus................................................29

Single Root Hierarchie ..................................33

Kontejnery ................................33

Parametrizované typy ................................35

Tvorba, použití předmětů a doba jejich života.......................36

Manipulace s výjimkami: Řešení chyb................................38

Paralelní provedení ........................38

Java a internet .............................39

Shrnutí................................47

Kapitola 2 Všechno je objekt................................48

Všechny objekty musí být vytvořeny explicitně.................................49

Objekty se nikdy nemusejí mazat................................53

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

Metody, argumenty a návratové hodnoty..................................56

Vytváření programu Java ...................................... 58

Klíčové slovo statické ..................................60

Náš první program v jazyce Java ................................. 61

Komentáře a vložená dokumentace................................................64

Styl programování ........................................70

Shrnutí.................................70

Kapitola 3. Operátoři........................71

Jednoduché tiskové příkazy ........................71

Příkazy Java............................72

Doslovy................................................82

Java postrádá sizeof() .................................................92

Resumé ............................100

Kapitola 4 Řídící struktury ...................101

Syntaxe foreach............................105

návrat, ...................................107

přerušit a pokračovat................................................108

Špatný příkaz goto ......................109

Shrnutí................................115

Kapitola 5. Inicializace a ukončení......................116

Inicializace záruk konstruktoru................................116

Přetížení metody ................................118

Úklid: Finalizace a odvoz odpadu................................130

Inicializace členů třídy .............................137

Inicializace konstruktoru ...................................140

Inicializace polí................................146

Shrnutí ............................151

Kapitola 6 Řízení přístupu ........................152

Balíček jako modul knihovny................................153

Specifikátory přístupu Java............................................159

Rozhraní a implementace................................163

Přístup k třídám ................................164

Shrnutí................................167

Kapitola 7 Opětovné použití tříd................................169

Syntaxe kompozice................................170

Syntaxe dědičnosti................................172

Delegace...................................176

Kombinace složení a dědičnosti............................178

Složení versus dědičnost...................................184

chráněný................................185

Konverze typu směrem nahoru...................................... 186

Konečné klíčové slovo................................188

Shrnutí................................197

Kapitola 8 Polymorfismus

Opět o vzestupné transformaci. . . >>................199

Vlastnosti................................201

Konstruktory a polymorfismus............................................208

Kovariance návratového typu......................................216

Navrhování s dědičností............................217

Pokračovat ................................220

Kapitola 9. Rozhraní......................221

Abstraktní třídy a metody......................................221

Rozhraní ................................224

Oddělení rozhraní od implementace............................................227

Rozšíření rozhraní prostřednictvím dědičnosti......................233

Rozhraní jako prostředek přizpůsobení................................236

Vnořená rozhraní................................239

Rozhraní a továrny................................242

Pokračovat ............................244

Kapitola 10 Vnitřní třídy................................245

Vytváření vnitřních tříd................................245

Komunikace s externí třídou................................246

.toto a .nové konstrukty................................248

Vnitřní třídy a vzestupná konverze......................249

Nejmenované vnitřní třídy......................253

Vnitřní třídy: proč? ................................... 261

Dědičnost po vnitřních třídách..................................272

Je možné přepsat vnitřní třídu?......................272

Místní vnitřní třídy ............................274

Shrnutí..................................276

Kapitola 11 Sbírky předmětů................................277

Parametrizované a typované kontejnery.................................277

Základní pojmy................................280

Přidání skupin prvků................................281

Seznam.................................285

Iterátory ............................288

LinkedList .............................291

Zásobník................................292

Mnoho................................................. 294

Mapa................................296

Fronta................................298

PriorityQueue............................................299

Kolekce a iterátor .............................301

Idiom "metoda-adaptér" ......................306

Pokračovat ............................309

Kapitola 12 Zacházení s chybami a výjimkami................310

Hlavní výjimky ..................................310

Výjimky chycení................................312

Vytváření vlastních výjimek................................314

Specifikace výjimek............................................319

Chytání svévolných výjimek................................320

Standardní výjimky Java .............................328

Končí s konečně ......................330

Použití nakonec s návratem........................334

Omezení použití výjimek................................336

Konstruktéři................................339

Identifikace výjimek................................343

Alternativní řešení................................344

Shrnutí................................351

Kapitola 13 Informace o typu................................352

Need for Dynamic Type Inference (RTTI) .........352

Registrace továrny ................................372

Reflexe: dynamické informace o třídě................................376

Dynamickí zprostředkovatelé................................380

Objekty s neurčitým stavem................................384

Rozhraní a informace o typu................................390

Pokračovat ............................394

Kapitola 14

Jednoduchá parametrizace.................................398

Parametrizovaná rozhraní................................404

Parametrizované metody...................407

Složité modely budov................................419

Omezení ................................437

Metaznaky ................................440

Pokračovat ................................452

Kapitola 15. Pole................................454

Vlastnosti pole................................454

Pole jako objekt................................456

Vrácení pole................................458

Vícerozměrná pole................................460

Pole a parametrizace................................463

Vytváření testovacích dat................................465

Vytváření polí pomocí generátorů......................470

Sada nástrojů Arrays Helper Toolkit...................474

Pokračovat ................................482

Kapitola 16 Systém Java I/O................................483

Třída souboru................................484

Vstup a výstup ................................489

Přidání atributů a rozhraní................................491

Třídy čtenářů a spisovatelů................................494

RandomAccessFile: sám o sobě......................497

Typické použití I/O toků................................498

Čtečky a zapisovače souborů............................................505

Pravděpodobně se nemýlím, když předpokládám, že většina studentů Javy to začala dělat s pomocí slavné knihy Bruce Eckela: „Myšlení v Javě“, známý v ruském vydání jako "Filozofie Jávy". Bohužel v v elektronické podobě(v ruštině) 2. vydání této knihy je nejrozšířenější a je založeno na verzi Java 1.1, která již dávno ztratila svůj význam. Inovace, které se objevily v dalších verzích Javy (a zejména v Javě SE5), byly velmi významné, což vedlo k vážné revizi knihy ve čtvrtém vydání (jejíž překlad vyšel v ruštině). Ve snadno čitelném (a co je nejdůležitější - pro rychlé vyhledávání) elektronickém formátu však ruská verze této publikace neexistovala. Proto jsem se rozhodl vyplnit tuto mezeru a vyrobit plnou verzi této oblíbené knihy ve formátu „wikibook“. Věřím, že tyto informace budou zajímavé a užitečné nejen pro studenty jazyků, ale také pro každého, kdo v Javě pracuje, díky obrovskému množství vynikajících příkladů ilustrujících téměř všechny aspekty programování v tomto jazyce. Zejména pokud jde o málo používané funkce Java.

wikikniha "Filozofie Jávy" zveřejněno na:

"Jaro v akci"

Knihy ze série ".....v akci"(obvykle ve formátu PDF a obvykle v angličtině) jsou v určitých kruzích zaslouženě oblíbené :) Mezi nimi jsou i prostorné Talmudy, jako např. "JSTL v akci"(snadno čtivé a se střední znalostí angličtiny, ale vhodné pro roli dobré reference k tématu), a skromnější řemesla, jako např. Vzpěry v akci("Není všechno zlato..."). Rezervovat "Jaro v akci" v tomto seznamu je stále z kategorie "těžkých vah", a to v každém smyslu toho slova. Číst to bez plynulé angličtiny asi není jednoduché. A nejde spíše o složitost předkládané látky (není složitá), ale o to, že to dopadlo - přehnaně "anglicko-umělecké", nebo co.... Plno lyrických odboček, okřídlených výrazů, slovních hříček a další bla bla bla, autoři jazyků, rychle změní čtení této příručky (v původním jazyce) na zdlouhavý proces. Ale na druhou stranu vám to umožňuje vědět, že to slovo "kreslit"(obvykle - "kreslit") lze použít ve významu "vyjmout z" (dosl. - "táhnout, táhnout"). V důsledku toho (s přihlédnutím k obecnému stylu prezentace přijatému v knize) pochopit přesný význam fráze jako: "...jaro čerpat tato data ...", děje se to současně – a není to snadné a je to nesmírně nutné. Čtenáři kapitol, které jsem nepřeložil, se proto budou muset sami rozhodnout, co autoři v takových případech chtěli: vyjádřit se poeticky ke vzniku (nahrávce) souboru, nebo hravě vyprávět o jeho čtení.

Tato kniha byla mnou převedena z PDF do wikibooku jako výslovný odkaz pro mé osobní použití. Překlad tedy není totální, ale jen místy – pro které bylo dost nadšení. Zbytek kapitol byl jednoduše uveden ve formě vhodné pro rychlé vyhledávání. Vychází, VŠECHNO ve formě - "jak je", a neměli byste vinit kvalitu ruského textu ... nejsem profesionální překladatel a neměl jsem literárního redaktora. Možná někoho zklamu tím, že jsem některá místa a kapitoly knihy nepřekládal (a překládat ani neplánuji), ale bylo potřeba nechat rezervu pro budoucí generace

wikikniha "Jaro v akci " zveřejněno na:

ÚVOD DO PŘEDMĚTŮ

Za vznik počítačové revoluce vděčíme stroji. Proto se naše programovací jazyky snaží tomuto stroji přiblížit.

Ale zároveň počítače nejsou ani tak mechanismy, ale prostředky k zesílení myšlení („kola pro mysl“, jak s oblibou říkával Steve Jobs) a další prostředek sebevyjádření. V důsledku toho se programovací nástroje přiklánějí méně ke strojům a více k naší mysli, stejně jako k jiným formám vyjádření lidských aspirací, jako je literatura, malba, sochařství, animace a kino. Objektově orientované programování (OOP) je součástí přeměny počítače na médium sebevyjádření.

Tato kapitola vás seznámí se základy OOP, včetně pohledu na základní techniky programování. To a kniha obecně předpokládá, že máte zkušenosti s programováním v procedurálním jazyce, ne nutně C.

Tato kapitola obsahuje přípravné a doplňkové materiály. Mnoho čtenářů si raději nejprve představí celkový obraz a teprve potom pochopí spletitost OOP. Proto mnoho myšlenek v této kapitole slouží k tomu, abyste správně porozuměli OOP. Mnoho lidí však nepochopí obecnou myšlenku, dokud konkrétně neuvidí, jak věci fungují; takoví lidé se často zaseknou v obecných pojmech, aniž by měli před sebou příklady. Pokud patříte k těm druhým a toužíte začít se základy jazyka, můžete přeskočit na další kapitolu – vynechání této nebude překážkou při psaní programů nebo učení se jazyka. K této kapitole byste se však měli vrátit později, abyste si rozšířili obzory a pochopili, proč jsou objekty tak důležité a kam se hodí do návrhu programu.

Vývoj abstrakce

Všechny programovací jazyky jsou postaveny na abstrakci. Možná, že obtížnost úkolů, které mají být řešeny, přímo závisí na typu a kvalitě abstrakce. "Typ" myslím: "Co přesně abstrahujeme?" Assembler je malá abstrakce od počítače, na kterém běží. Mnoho takzvaných „příkazových“ jazyků vytvořených po něm (např Fortran, ZÁKLADNÍ a C) byly abstrakce další úrovně. Tyto jazyky měly značnou výhodu oproti jazyku symbolických instrukcí, ale jejich základní abstrakce vás stále nutí přemýšlet o struktuře počítače spíše než o řešeném problému. Programátor musí vytvořit vztah mezi modelem stroje (v "prostoru řešení", který představuje místo, kde je řešení implementováno - například počítač) a modelem řešeného problému (v "prostoru problémů" , což je místo, kde problém existuje – například aplikovaná oblast). Navázání spojení vyžaduje úsilí oddělené od skutečného programovacího jazyka; výsledkem jsou programy, které se obtížně píší a obtížně udržují. Nejen to, vytvořilo také celé odvětví „programovacích metodologií“.

Alternativou k modelování stroje je modelování řešeného problému. Rané jazyky jako LISP a APL, zvolili speciální přístup k modelování okolního světa („Všechny problémy řeší seznamy“, resp. „Algoritmy řeší vše“). PROLOG zachází se všemi problémy jako s řetězci řešení. Jazyky byly vytvořeny pro programování založené na systému omezení a speciální jazyky, ve kterých bylo programování prováděno manipulací s grafickými strukturami (rozsah těchto se ukázal být příliš úzký). Každý z těchto přístupů je dobrý v určité oblasti problémů, které je třeba vyřešit, ale jakmile tuto oblast opustíte, je obtížné je používat.

Objektový přístup jde o krok dále tím, že poskytuje programátorovi prostředky k reprezentaci úkolu v jeho prostoru. Tento přístup je zcela obecný a neklade žádná omezení na typ řešeného problému. Prvky problémového prostoru a jejich reprezentace v prostoru řešení se nazývají „objekty“. (Pravděpodobně budete potřebovat další objekty, které nemají v problémovém prostoru žádné analogy.) Myšlenka je taková, že program se dokáže přizpůsobit specifikům problému vytvořením nových typů objektů, takže při čtení kódu, který problém řeší, budete současně viz slova, která ji popisují. Jedná se o flexibilnější a silnější abstrakci, která svými schopnostmi překonává vše, co dříve existovalo. Někteří návrháři jazyků se domnívají, že objektově orientované programování samo o sobě nestačí k vyřešení všech programovacích problémů, a obhajují kombinaci různých programovacích paradigmat v jednom jazyce. Takové jazyky se nazývají multi-paradigma(multiparadigmata). Viz knihu Timothyho Budda Multiparadigm Programming in Leda (Addison-Wesley, 1995).. OOP tedy umožňuje popsat úlohu v kontextu úlohy samotné, nikoli v kontextu počítače, na kterém bude řešení provedeno. Spojení s počítačem však zůstává zachováno. Každý objekt je jako malý počítač; má stav a operace, které umožňuje. Taková analogie dobře zapadá do vnějšího světa, který je „realitou danou nám v předmětech“, které mají vlastnosti a chování.

Alan Kay shrnul a odvodil pět hlavních rysů jazyka Pokec- první úspěšný objektově orientovaný jazyk, jeden z předchůdců Jáva. Tyto vlastnosti představují „čistý“, akademický přístup k objektově orientovanému programování:

• Všechno je objekt. Představte si objekt jako rafinovanou proměnnou; ukládá data, ale můžete se na objekt „dotazovat“ a požádat ho, aby na něm provedl operace. Teoreticky lze jako objekt reprezentovat naprosto jakoukoli složku řešeného problému (pes, budova, služba atd.).

• Program je skupina objektů, které si prostřednictvím zpráv říkají, co mají dělat. Chcete-li provést požadavek na objekt, "odešlete mu zprávu". Vizuálněji lze zprávu reprezentovat jako volání metody patřící konkrétnímu objektu.

• Každý objekt má svou vlastní „paměť“ sestávající z jiných objektů. Jinými slovy, tvoříte nový objekt vložením existujících objektů do něj. Je tak možné sestrojit libovolně složitý program, skrývající celkovou složitost za jednoduchost jednotlivých objektů.

• Každý objekt má svůj typ. Jinými slovy, každý objekt je instancí třídy, kde "class" je ekvivalentem slova "type". Nejdůležitější rozdíl mezi třídami spočívá právě v odpovědi na otázku: "Jaké zprávy lze odeslat objektu?"

• Všechny objekty určitého typu mohou přijímat stejné zprávy. Jak brzy uvidíme, jde o velmi důležitou okolnost. Protože objekt typu „kruh“ je také objekt typu „tvar“, je pravda, že „kruh“ je jistě schopen přijímat zprávy pro „tvar“. A to znamená, že můžete psát kód pro tvary a být si jisti, že bude fungovat pro vše, co spadá pod pojem tvar. Zaměnitelnost je jedním z nejsilnějších konceptů v OOP.

Booch nabídl ještě výstižnější popis objektu:

Objekt má stav, chování a osobnost.

Pointa je, že objekt může mít interní data (což je stav objektu), metody (které definují chování) a každý objekt lze jednoznačně odlišit od jakéhokoli jiného objektu – konkrétněji, každý objekt má jedinečnou adresu v mysl To platí s určitými omezeními, protože objekty mohou skutečně existovat na jiných počítačích a v různých adresových prostorech a mohou být také uloženy na disku. V těchto případech musí být identita objektu určena něčím jiným než adresou paměti..

Objekt má rozhraní

Je pravděpodobné, že Aristoteles byl první, kdo pečlivě studoval koncept typu; mluvil o „třídě ryb a třídě ptáků“. Koncept, že všechny objekty, přestože jsou jedinečné, jsou zároveň součástí třídy objektů s podobnými vlastnostmi a chováním, byl použit v prvním objektově orientovaném jazyce Simula-67 se zavedením základního klíčového slova třída , která do programu zavedla nový typ.

Jazyk Simula, jak už název napovídá, byl vytvořen za účelem vyvíjet a simulovat situace podobné klasickému problému „bankovní pokladny“. Máte skupiny pokladních, zákazníků, účtů, plateb a měn – spoustu „objektů“. Objekty, které jsou během běhu programu identické ve všech stavech kromě vnitřního, jsou seskupeny do „tříd objektů“. Odtud to přišlo klíčové slovo třída . Vytváření abstraktních datových typů je základním konceptem veškerého objektově orientovaného programování. Abstraktní datové typy fungují v podstatě stejným způsobem jako vestavěné typy: můžete vytvářet proměnné typu (nazývané objekty nebo instance v podmínkách OOP) a manipulovat s nimi (nazývané zasílání zpráv nebo dotazování; zadáte požadavek a objekt rozhodne, co s to.). Členové (prvky) každé třídy mají podobnosti: každý účet má zůstatek, každý pokladník přijímá vklady atd. Všichni členové se zároveň liší svým vnitřním stavem: každý účet má individuální zůstatek, každý pokladník má lidské jméno. Proto mohou být všichni pokladní, zákazníci, účty, převody atd. uvnitř reprezentováni jedinečnými entitami počítačový program. To je podstata objektu a každý objekt patří do určité třídy, která definuje jeho vlastnosti a chování.

I když tedy vytváříme nové datové typy v objektových jazycích, prakticky všechny tyto jazyky používají klíčové slovo „class“. Když vidíte slovo „typ“, myslete na „třída“ a naopak Někteří lidé rozlišují mezi těmito dvěma tím, že poukazují na to, že typ definuje rozhraní, zatímco třída je konkrétní implementace rozhraní..

Vzhledem k tomu, že třída definuje množinu objektů se shodnými charakteristikami (datovými členy) a chováním (funkčností), je třída vlastně datovým typem, protože například číslo s plovoucí desetinnou čárkou má také řadu charakteristik a chování. Rozdíl je v tom, že programátor definuje třídu, která představuje nějaký aspekt úlohy, namísto použití již existujícího typu, který představuje jednotku úložiště dat ve stroji. Programovací jazyk rozšíříte přidáním nových datových typů, aby vyhovovaly vašim potřebám. Programovací systém upřednostňuje nové třídy a věnuje jim přesně stejnou pozornost jako vestavěným typům.

Objektově orientovaný přístup není omezen na modely budov. Ať už souhlasíte nebo ne, že jakýkoli program je modelem vámi vyvinutého systému, použití technologie OOP snadno redukuje velký soubor problémů na jednoduché řešení.

Jakmile je nová třída definována, můžete vytvořit libovolný počet objektů této třídy a pak s nimi manipulovat, jako by byly součástí daného problému. Ve skutečnosti je jedním z hlavních problémů OOP vytvoření vzájemné korespondence mezi objekty v prostoru problému a objekty v prostoru řešení.

Ale jak přimět objekt, aby dělal to, co chcete? Musí existovat mechanismus pro odeslání požadavku objektu na provedení nějaké akce – dokončení transakce, kreslení na obrazovku atd. Každý objekt může provádět pouze určitý rozsah požadavků. Dotazy, které můžete odeslat na objekt, jsou určeny jeho rozhraním a rozhraní objektu je určeno jeho typem. Nejjednodušším příkladem by byla elektrická žárovka:

Light lt = new Light() ;
lt.on();

Rozhraní definuje, jaké požadavky můžete vznést na konkrétní objekt. Někde však musí existovat i kód, který dotazy provádí. Tento kód spolu se skrytými daty tvoří implementaci. Z hlediska procedurálního programování není to, co se děje, tak obtížné. Typ obsahuje metodu pro každý možný požadavek, a když je přijat konkrétní požadavek, je zavolána příslušná metoda. Proces je obvykle spojen do jednoho: „odeslání zprávy“ (předání požadavku) objektu a jeho zpracování objektem (provedení kódu).

V tomto příkladu je pojmenovaný typ (třída). světlo (lampa), betonový předmět typu světlo Se jménem To a třída podporuje různé objektové dotazy světlo : Vypněte žárovku, zapněte ji, zesvětlete ji nebo ji ztlumte. Vytvoříte objekt světlo , definováním „odkazu“ na něj ( To ) a zavolání operátorovi Nový vytvořit novou instanci tohoto typu. Chcete-li odeslat zprávu objektu, musíte zadat název objektu a přiřadit jej k požadovanému požadavku pomocí tečky. Z pohledu uživatele předdefinované třídy je to k provozu s jejími objekty docela dost.

Výše uvedený graf odpovídá formátu UML (Unified Modeling Language). Každá třída je reprezentována obdélníkem, všechna datová pole, která jsou popsána, jsou umístěna v jeho střední části a metody (funkce objektu, kterému posíláte zprávy) jsou uvedeny ve spodní části obdélníku.

Často na grafech UML je zobrazen pouze název třídy a veřejné metody a prostřední část chybí. Pokud vás zajímá pouze název třídy, můžete přeskočit i spodní část.

Zařízení poskytuje služby

Když se snažíte navrhnout nebo porozumět struktuře programu, často je užitečné myslet na objekty jako na „poskytovatele služeb“. Váš program poskytuje služby uživateli, a to prostřednictvím služeb poskytovaných jinými objekty. Vaším cílem je vytvořit (nebo ještě lépe najít v knihovnách tříd) sadu objektů, které budou optimální pro řešení vašeho problému.

Pro začátek se zeptejte sami sebe: „Kdybych mohl kouzlem odstranit předměty z klobouku, které by právě teď dokázaly vyřešit můj problém? Předpokládejme, že vyvíjíte účetní program. Lze si představit sadu objektů, které poskytují standardní okna pro zadávání účetních informací, další sadu objektů, které provádějí účetní výpočty, objekt, který tiskne šeky a faktury na různých tiskárnách. Možná některé z těchto objektů již existují a u jiných objektů stojí za to zjistit, jak by mohly vypadat. Jaké služby by tato zařízení mohla poskytovat a jaká zařízení by potřebovala ke své práci? Pokud budete takto pokračovat, dříve nebo později řeknete: „Tento objekt je natolik jednoduchý, že si ho můžeme sednout a zapsat“ nebo „Takový objekt už určitě existuje“. Toto je rozumný způsob, jak rozdělit řešení problému na samostatné objekty.

Zastupování objektu jako poskytovatel služeb má přidanou výhodu: pomáhá zlepšit konektivitu ( soudržnost) objekt. Dobrá konektivita - zásadní kvalitu softwarový produkt: to znamená, že různé aspekty softwarové komponenty (jako je objekt, ačkoli může také odkazovat na metodu nebo knihovnu objektů) do sebe dobře zapadají. Jeden z obyčejné chyby povoleno při navrhování objektu je přesycení velkým množstvím vlastností a schopností. Například při vývoji modulu, který tiskne šeky, můžete chtít, aby „věděl“ vše o formátování a tisku.

Když se nad tím zamyslíte, s největší pravděpodobností dojdete k závěru, že na jeden objekt je toho moc a půjdete na tři a více objektů. Jedním objektem bude katalog všech možných forem šeků a lze se dotazovat, jak má být šek vytištěn. Jiný objekt nebo množina objektů bude mít na starosti zobecněné tiskové rozhraní, které „ví“ vše o různých typech tiskáren (ale v účetnictví ničemu „nerozumí“ – je lepší si takový objekt koupit, než si jej vyvíjet sami). Nakonec třetí objekt jednoduše využije služeb popsaných objektů k dokončení úkolu. Každý objekt je tedy propojeným souborem služeb, které nabízí. V dobře naplánovaném objektově orientovaném projektu každý objekt dělá dobrou práci při provádění jednoho konkrétního úkolu, aniž by se snažil dělat víc, než potřebuje. Jak je znázorněno, umožňuje vám to nejen určit, které objekty si pořídit (objekt s tiskovým rozhraním), ale také skončit s objektem, který pak lze použít někde jinde (katalog účtenek).

Zastupování objektů jako poskytovatelů služeb tento úkol značně zjednodušuje. Je to užitečné nejen při vývoji, ale také když se někdo snaží porozumět vašemu kódu nebo znovu použít objekt - pak bude schopen adekvátně vyhodnotit objekt pro úroveň poskytovaných služeb, což výrazně zjednoduší jeho integraci do jiný projekt.

Skrytá implementace

Je užitečné rozdělit programátory na tvůrci třídy(ti, kteří vytvářejí nové datové typy) a klientské programátoryJsem vděčný za tento termín svému příteli Scottu Meyersovi.(spotřebitelé tříd, které ve svých aplikacích používají datové typy). Cílem druhého je shromáždit co nejvíce tříd, abyste se mohli zapojit do rychlého vývoje programů. Cílem tvůrce tříd je vybudovat třídu, která odhaluje pouze to, co klientský programátor potřebuje, a skrývá vše ostatní. Proč? Klientský programátor se ke skrytým částem nedostane, což znamená, že tvůrce tříd si vyhrazuje možnost je libovolně měnit bez obav, že to někomu ublíží. „Skrytá“ část je obvykle „nejkřehčí“ část objektu, kterou může snadno poškodit neopatrný nebo neznalý klientský programátor, takže skrytí implementace snižuje počet chyb v programech.

V každém vztahu je důležité mít nějaké hranice, které nikdo ze zúčastněných nepřekračuje. Vytvořením knihovny navážete vztah s klientským programátorem. Je to programátor jako vy, ale použije vaši knihovnu k vytvoření aplikace (a možná i knihovny vyšší úrovně). Pokud dáte přístup ke všem členům třídy komukoli, klientský programátor si může s třídou dělat, co chce, a neexistuje způsob, jak ji přimět „hrát podle pravidel“. I když později potřebujete omezit přístup k určitým členům vaší třídy, nelze to provést bez mechanismu řízení přístupu. Celá struktura třídy je otevřena všem příchozím.

Prvním důvodem pro omezení přístupu je tedy nutnost chránit před klientským programátorem „křehké“ detaily – části vnitřní „kuchyně“, které nejsou součástí rozhraní, se kterým uživatelé řeší své problémy. Ve skutečnosti je to užitečné i pro uživatele – hned uvidí, co je pro ně důležité a co mohou ignorovat.

Druhým důvodem, proč se objevuje omezení přístupu, je touha umožnit vývojáři knihovny změnit vnitřní mechanismy třídy bez obav, jak to ovlivní klientského programátora. Můžete například implementovat určitou třídu ve spěchu, abyste urychlili vývoj programu, a poté ji přepsat, abyste zvýšili rychlost. Pokud jste správně oddělili a ochránili rozhraní a implementaci, nemělo by to být vůbec obtížné.

Jáva používá tři explicitní klíčová slova charakterizující úroveň přístupu: veřejné, soukromé a chráněný . Jejich účel a použití je velmi jednoduché. Tyto specifikátory přístupu určují, kdo má právo používat definice, které po nich následují. Slovo veřejnost znamená, že následující definice jsou dostupné všem. Naopak slovo soukromé znamená, že následující klauzule jsou dostupné pouze pro tvůrce typu uvnitř jeho metod. Období soukromé - "pevnostní zeď" mezi vámi a programátorem-klientem. Pokud se někdo pokusí použít soukromé -členové, bude zastaven chybou kompilace. specifikátor chráněný působí podobně jako soukromé , s jednou výjimkou - odvozené třídy mají přístup k členům označeny chráněný ale nemají přístup soukromé -členové (dědictví brzy pokryjeme).

V Jáva existuje také "výchozí" přístup použitý v nepřítomnosti některého z uvedených specifikátorů. Někdy se mu také říká přístup v rámci balíčku ( přístup k balíčku), protože třídy mohou používat členy přátel z jiných tříd ve svém balíčku, ale mimo balíček získají status stejní členové přátel soukromé .

Implementace Opětovné použití

Vygenerovaná a otestovaná třída by (v ideálním případě) měla být užitečným blokem kódu. Ukazuje se však, že dosažení tohoto cíle je mnohem obtížnější, než si mnoho lidí myslí; vývoj opakovaně použitelných předmětů vyžaduje zkušenost a pochopení podstaty věci. Ale jakmile to uděláte správně dobrá konstrukce, bude jednoduše žádat o implementaci v jiných programech. Opětovné použití kódu je jednou z nejpůsobivějších výhod objektově orientovaných jazyků.

Nejjednodušší způsob, jak znovu použít třídu, je přímo vytvořit její objekt, ale můžete také umístit objekt této třídy do nové třídy. Říkáme tomu vkládání objektů (vytváření členských objektů). Nová třída může obsahovat libovolný počet objektů jiných typů, v libovolné kombinaci, která je nezbytná pro dosažení požadované funkčnosti. Vzhledem k tomu, že kompilujeme nová třída z již existujících tříd se tato metoda volá složení(když se kompozice provádí dynamicky, je obvykle pojmenována agregace). Složení je často označováno jako vztah „má“ ( má), jako například ve větě "Auto má motor."

(V UML diagramech je složení naznačeno vyplněným kosočtvercem, který například ukazuje, že existuje pouze jedno auto. Obvykle používám obecnější formu vztahu: pouze čáry, žádný kosočtverec, což znamená asociaci (odkaz). To obvykle stačí pro většinu grafů, kde pro vás rozdíl mezi složením a agregací není významný.)

Kompozice je velmi flexibilní nástroj. Členské objekty vaší nové třídy jsou obvykle deklarovány jako soukromé ( soukromé ), což je činí nepřístupnými pro klientské programátory používající třídu. To umožňuje provádět změny v těchto členských objektech bez úpravy existujícího kódu klienta. Tyto členy můžete také změnit za běhu, abyste dynamicky řídili chování vašeho programu. Níže popsaná dědičnost tuto flexibilitu nemá, protože kompilátor ukládá určitá omezení na třídy vytvořené pomocí dědičnosti.

Dědičnost hraje v objektově orientovaném programování důležitou roli, proto je jí často věnována velká pozornost a začátečník by si mohl myslet, že by se dědičnost měla uplatňovat všude. A to je plné vytváření neohrabaných a zbytečně složitých řešení. Místo toho byste při vytváření nových tříd měli nejprve vyhodnotit možnost kompozice, protože je jednodušší a flexibilnější. Pokud přijmete doporučený přístup, vaše programovací konstrukce budou mnohem jasnější. A jak získáte praktické zkušenosti, nebude těžké pochopit, kde by se mělo dědictví použít.

Dědictví

Samotná myšlenka předmětu je mimořádně pohodlná. Objekt vám umožňuje kombinovat data a funkčnost na koncepční úrovni, to znamená, že můžete reprezentovat požadovaný koncept z prostoru úkolu namísto jeho konkretizace pomocí dialektu stroje. Tyto pojmy tvoří základní jednotky programovacího jazyka, popsané klíčovým slovem class.

Ale musíte uznat, že by byla škoda vytvořit nějakou třídu a pak dělat všechnu práci znovu pro podobnou třídu. Mnohem racionálnější je vzít hotovou třídu, „naklonovat“ ji a poté do výsledného klonu přidávat doplňky a aktualizace. To je přesně to, co získáte jako výsledek dědičnosti, s jedinou výjimkou - pokud se původní třída (nazývaná také základní * třída, nadtřída nebo rodičovská třída) změní, pak se všechny změny projeví v jejím "klonu" (tzv. odvozená třída , zděděná třída, podtřída nebo podtřída).

(Šipka (prázdný trojúhelník) v diagramu UML ukazuje z odvozené třídy na základní třídu. Jak brzy uvidíte, může existovat více než jedna odvozená třída.)

Typ definuje více než jen vlastnosti skupiny objektů; je spojena i s jinými typy. Tyto dva typy mohou sdílet podobnosti a chování, ale liší se počtem charakteristik a také schopností zpracovat více zpráv (nebo je zpracovat odlišně). K vyjádření této shodnosti typů používá dědičnost koncept základních a odvozených typů. Základní typ obsahuje všechny vlastnosti a akce společné všem typům od něj odvozeným. Vytvoříte základní typ, který bude představovat základ vašeho chápání některých objektů ve vašem systému. Od základního typu jsou odvozeny další typy, vyjadřující další implementace této entity.

Například recyklační stroj třídí odpad. Základním typem bude „odpad“ a každý kus odpadu má váhu, cenu atd. a lze jej rozdrtit, roztavit nebo rozložit. Na základě toho se dědí specifičtější typy odpadků, které mají další vlastnosti (láhev má barvu) nebo rysy chování ( hliníková plechovka lze rozdrtit, ocelová plechovka je přitahována magnetem). Kromě toho se některé chování může lišit (cena papíru závisí na jeho typu a stavu). Dědičnost umožňuje vytvořit hierarchii typů, která popisuje řešený problém v kontextu jeho typů.

Druhý příklad je klasický příklad s geometrické tvary. Základním typem je zde „tvar“ a každý tvar má svou velikost, barvu, umístění atd. Každý tvar lze kreslit, mazat, přesouvat, malovat atd. Dále se vyrábějí (dědí) specifické typy tvarů: kruh, čtverec, trojúhelník atd., z nichž každý má své vlastní další vlastnosti a chování. Některé tvary například podporují operaci zrcadlení. Jednotlivé rysy chování se mohou lišit, jako v případě výpočtu plochy postavy. Hierarchie typů ztělesňuje jak podobné, tak odlišné vlastnosti tvarů.

Redukovat řešení na koncepty použité v příkladu je mimořádně pohodlné, protože nepotřebujete mnoho mezimodelů, které spojují popis řešení s popisem problému. Při práci s objekty se hierarchie typů stává primárním modelem, takže přejdete od přímého popisu systému v reálném světě k popisu systému v kódu. Ve skutečnosti je jednou z obtíží objektově orientovaného plánování to, že je pro vás velmi snadné přejít od začátku problému až ke konci řešení. Mysl vycvičená pro komplexní řešení se často zasekne při použití jednoduchých přístupů.

Děděním z existujícího typu vytváříte nový typ. Tento nový typ obsahuje nejen všechny členy stávajícího typu (ačkoli členy označené jako soukromé , skrytý a nepřístupný), ale co je důležitější, opakuje rozhraní základní třídy. To znamená, že všechny zprávy, které můžete odeslat do základní třídy, můžete také odeslat do odvozené třídy. A protože rozlišujeme typy tříd podle sady zpráv, které jim můžeme poslat, znamená to, že odvozená třída je speciální případ základní třídy. V předchozím příkladu „kruh je obrazec“. Ekvivalence typů dosažená dědičností je jednou ze základních podmínek pro pochopení významu objektově orientovaného programování.

Protože základní i odvozené třídy mají stejné hlavní rozhraní, musí existovat implementace pro toto rozhraní. Jinými slovy, někde musí existovat kód, který se provede, když objekt obdrží konkrétní zprávu. Pokud jste jednoduše zdědili třídu a neudělali nic jiného, ​​metody z rozhraní základní třídy přejdou do odvozené třídy beze změny. To znamená, že objekty odvozené třídy jsou nejen stejného typu, ale mají i stejné chování a přitom samotná dědičnost ztrácí smysl.

Existují dva způsoby, jak změnit novou třídu ze základní třídy. První je poměrně zřejmý: do odvozené třídy jsou přidány zcela nové metody. Již nejsou součástí rozhraní základní třídy. Základní třída zjevně neudělala vše, co úkol vyžadoval, takže jste přidali několik metod. Takový jednoduchý a primitivní přístup k dědictví se však někdy ukazuje jako ideální řešení problému. Jedna věc, kterou je však třeba pečlivě zvážit, je, že základní třída může také potřebovat tyto přidané metody. Proces identifikace vzorů a revize architektury je v objektově orientovaném programování každodenní rutinou.

Zatímco dědičnost někdy naznačuje, že rozhraní bude rozšířeno o nové metody (zejména v Jáva, kde je dědičnost označena klíčovým slovem rozšiřuje , tedy "rozbalit"), to není vůbec nutné. Druhým, důležitějším způsobem, jak upravit třídu, je změna chování již stávající metody základní třída. To se nazývá přepsání (nebo přepsání) metody.

Chcete-li přepsat metodu, jednoduše vytvořte novou definici této metody v odvozené třídě. Říkáte si "Používám stejnou metodu rozhraní, ale chci, aby pro můj nový typ dělala jiné věci."

Při použití dědičnosti vyvstává zřejmá otázka: měla by dědičnost potlačit metody pouze základní třída (a nepřidávat nové metody, které v základní třídě neexistují)? To by znamenalo, že odvozená třída by byla přesně stejného typu jako základní třída, protože mají stejné rozhraní. V důsledku toho můžete volně nahradit objekty základní třídy objekty odvozených tříd. Můžete mluvit o úplné výměně a často se tomu říká substituční princip. V jistém smyslu je tento způsob dědění ideální. Tento druh vztahu mezi základní třídou a odvozenou třídou se často nazývá vztah. "je něco", protože se dá říci „kruh je postava“. K určení, jak vhodná bude dědičnost, stačí zkontrolovat, zda existuje vztah „je“ mezi třídami a jak je oprávněný.

V ostatních případech je rozhraní odvozené třídy doplněno o nové prvky, což vede k jeho rozšíření. Nový typ lze stále používat místo základního typu, ale nyní tato náhrada není ideální, protože nové metody nejsou ze základního typu dostupné. Takové spojení je popsáno výrazem „podobný“ (toto je můj termín); nový typ obsahuje rozhraní starého typu, ale zahrnuje také nové metody a nelze říci, že tyto typy jsou úplně stejné. Vezměme si jako příklad klimatizaci.

Předpokládejme, že váš dům je vybaven vším potřebné vybavení k řízení procesu chlazení. Představte si nyní, že se klimatizace porouchala a vy jste ji nahradili ohřívačem schopným topit i chladit. Topení je „jako“ klimatizace, ale umí víc. Protože řídicí systém vašeho domova může řídit pouze chlazení, je omezený v komunikaci s chladicí částí nového zařízení. Rozhraní nového objektu bylo rozšířeno a stávající systém nepozná nic jiného než původní rozhraní.

Při pohledu na tuto hierarchii je samozřejmě jasné, že základní třída „chladící systém“ není dostatečně flexibilní; měl by se přejmenovat na "systém regulace teploty", aby zahrnoval i vytápění - a poté bude fungovat princip substituce. Tento diagram však poskytuje příklad toho, co se může stát ve skutečnosti.

Po seznámení s principem substituce by člověk mohl nabýt dojmu, že tento přístup (plná náhrada) je jedinou cestou k rozvoji. Obecně řečeno, pokud vaše hierarchie typů fungují tímto způsobem, je to opravdu dobré. Ale v některých situacích je naprosto nezbytné přidat nové metody do rozhraní odvozené třídy. Při bližším zkoumání se oba případy zdají celkem zřejmé.

Zaměnitelné objekty a polymorfismus

Při použití hierarchií typů je často nutné považovat objekt určitého typu za základní typ. To vám umožňuje psát kód, který nezávisí na konkrétních typech. V příkladu tvarů tedy metody jednoduše manipulují s tvary, bez ohledu na to, zda se jedná o kruhy, obdélníky, trojúhelníky nebo některé dosud nedefinované tvary. Všechny tvary lze kreslit, mazat a přesouvat a metody jednoduše posílají zprávy do objektu tvaru; je jim jedno, jak objekt se zprávou naloží.

Takový kód nezávisí na přidávání nových typů a přidávání nových typů je nejběžnějším způsobem, jak rozšířit objektově orientované programy, aby zvládly nové situace. Můžete například vytvořit novou podtřídu tvaru (pentagon) beze změny metod, které pracují pouze s obecnými tvary. Schopnost snadno rozšířit program zavedením nových odvozených typů je velmi důležitá, protože výrazně zlepšuje architekturu programu a zároveň snižuje náklady na údržbu softwaru.

Při pokusu o označení objektů odvozených typů jako základních typů (kruhy jako postava, kolo jako vozidlo, kormorán jako pták atd.) však nastává jeden problém. Pokud metoda řekne obecnému obrázku, aby se nakreslil sám, nebo vozidlu, aby sledovalo určitý kurz nebo ptákovi, aby létal, kompilátor nemůže přesně vědět, která část kódu bude provedena. To je celý smysl – když je odeslána zpráva, programátor nechce vědět, jaký kód se provádí; metodu kreslení lze aplikovat na kruh, obdélník a trojúhelník se stejným úspěchem a objekt provede správný kód v závislosti na jeho charakteristickém typu.

Pokud nepotřebujete vědět, která část kódu se provádí, pak když přidáte nový podtyp, jeho implementační kód se může lišit, aniž by bylo nutné měnit metodu, ze které byl volán. Pokud kompilátor přesně neví, jaký kód má spustit, co udělá?

V následující příklad objekt BirdController (kontrola ptáků) může pracovat pouze s obecnými objekty pták (pták), nezná jejich přesný typ. Z pohledu BirdController to je výhodné, protože nemusíte psát speciální kód pro kontrolu typu objektu, který je pro něj použit pták , zvládnout nějaké zvláštní chování. Jak se to stane, že když zavoláte metodu move (), aniž byste zadali přesný typ pták , je provedena správná akce - objekt husa (husa) běží, létá nebo plave a předmět Tučňák (tučňák) běh nebo plavání?

Odpověď je vysvětlena hlavní rys objektově orientované programování: kompilátor nemůže volat takové funkce tradičním způsobem. Při volání funkcí vytvořených kompilátorem, který není OOP, použijte časná vazba- mnozí tento pojem neznají jednoduše proto, že si jinou možnost nepředstavují. S včasnou vazbou kompilátor generuje volání funkce s křestní jméno a linker sváže toto volání s absolutní adresou kódu, který má být proveden. V OOP není program schopen určit adresu kódu až za běhu, takže při odesílání zprávy na objekt musí fungovat jiný mechanismus.

K vyřešení tohoto problému používají objektově orientované programovací jazyky koncept pozdní vazba. Když odešlete zprávu objektu, volaný kód není až do běhu znám. Kompilátor se pouze ujistí, že metoda existuje, zkontroluje typy pro její parametry a návratovou hodnotu, ale netuší, jaký druh kódu bude proveden.

Chcete-li implementovat pozdní vazbu, Jáva používá speciální úryvky kódu místo absolutního volání. Tento kód vypočítá adresu těla metody na základě informací uložených v objektu (proces je velmi podrobně popsán v kapitole 7 o polymorfismu). Každý objekt se tedy může chovat odlišně v závislosti na obsahu tohoto speciálního kódu. Když odešlete zprávu, objekt ve skutečnosti rozhodne, co s ní udělá.

Některé jazyky vyžadují, abyste výslovně uvedli, že metoda by měla používat flexibilní mechanismus pozdní vazby (v C++ existuje pro to klíčové slovo virtuální). V těchto jazycích nejsou metody ve výchozím nastavení dynamicky propojeny. V Jáva pozdní vazba se provádí ve výchozím nastavení a nemusíte si pamatovat přidání jakýchkoli klíčových slov, abyste zajistili polymorfismus.

Připomeňte si příklad s tvary. Rodina tříd (založených na stejném rozhraní) byla znázorněna v diagramu dříve v této kapitole. Abychom demonstrovali polymorfismus, napíšeme úryvek kódu, který ignoruje specifika typu a funguje pouze se základní třídou. Tento kód je oddělen od typových specifik, takže je jednodušší ho napsat a pochopit. A pokud je nový typ (například šestiúhelník) přidán prostřednictvím dědění, pak kód, který napíšete pro nový typ obrázku, bude fungovat stejně dobře jako kód pro stávající typy. Tím se program stává rozšiřitelným.

Řekněme, že jsi napsal Jáva následující metoda (brzy se naučíte, jak to udělat):

void doSomething (tvar tvaru) (
tvar.erase(); // vymazat
//...
tvar.kresli(); // kreslit
}

Metoda pracuje se zobecněným obrazcem ( tvar ), to znamená, že nezávisí na konkrétním typu objektu, který se kreslí nebo maže. Nyní použijeme volání metody dělej něco() v další části programu:

Circle circle = new Circle() ; // kruh
Trojúhelníkový trojúhelník = new Triangle() ; // trojúhelník
Line line = new Line(); // řádek
doSomething(kruh) ;
doSomething(trojúhelník) ;
doSomething(řádek);

Volání metody dělej něco() automaticky pracovat správně, bez ohledu na skutečný typ objektu.

To je vlastně docela důležitý fakt. Zvažte řádek:

doSomething(kruh) ;

Zde se stane následující: k metodě, která očekává objekt tvar , je předán objekt „kruh“ ( Kruh ). Od kruhu ( Kruh ) je zároveň postava ( tvar ), pak metoda dělej něco() a zachází s ní jako s postavou. Jinými slovy, jakákoli zpráva, kterou může metoda odeslat tvar , je také přijímán Kruh . Tato akce je zcela bezpečná a stejně logická.

Tento proces nakládání s odvozeným typem označujeme, jako by to byl základní typ. upcasting. Slovo proměna znamená, že se s objektem zachází jako s objektem jiného typu a vzestupně je to proto, že v diagramech dědičnosti jsou základní třídy obvykle nahoře a odvozené třídy jsou rozprostřeny dole. To znamená, že převod na základní typ je pohyb nahoru po diagramu, a proto je „nahoru“.

Objektově orientovaný program téměř vždy obsahuje upcast, protože se tak zbavíte potřeby znát přesný typ objektu, se kterým pracujete. Podívejte se na tělo metody dělej něco() :

tvar.erase();
// ...
tvar.kresli();

Všimněte si, že to neříká „pokud jste objekt Kruh , udělejte to, a pokud jste objekt Náměstí udělej to a to." Takový kód se samostatnými akcemi pro každý možný typ tvar bude matoucí a bude se muset změnit pokaždé, když se přidá nový podtyp tvar . A tak jen řeknete: "Jsi postava a já vím, že se umíš kreslit a mazat, no, udělej to a postarej se o detaily sám."

V kódu metody dělej něco() Zajímavé je, že vše funguje tak, jak má. Při zavolání kreslit() pro objekt Kruh provede se jiný kód, nikoli ten, který funguje při volání kreslit() pro předměty Náměstí nebo čára , a kdy kreslit() aplikován na neznámou postavu tvar , správné chování je zajištěno použitím typu real tvar . je to v nejvyšší stupeň zajímavé, protože, jak bylo uvedeno o něco dříve, když kompilátor generuje kód dělej něco() , neví přesně, s jakými typy pracuje. Podle toho by se dalo očekávat, že budou volány verze metody kreslit() a vymazat() ze základní třídy tvar , nikoli jejich varianty z konkrétních tříd Kruh , Náměstí nebo čára . A přesto vše funguje správně díky polymorfismu. Kompilátor a runtime systém se starají o všechny detaily; vše, co potřebujete vědět, je, že se to stane... a co je důležitější, jak vytvářet programy pomocí tohoto přístupu. Když odešlete zprávu objektu, objekt zvolí správné chování pomocí upcastu.

Jediná kořenová hierarchie

Krátce po vystoupení C++ začala se aktivně diskutovat otázka z OOP - měly by být všechny třídy nutně zděděny z jediné základní třídy? V Jáva(stejně jako téměř ve všech ostatních jazycích OOP s výjimkou C++) Tato otázka byla zodpovězena kladně. Celá hierarchie typů je založena na jediné základní třídě Objekt . Ukázalo se, že jednokořenová hierarchie má mnoho výhod.

Všechny objekty v hierarchii s jedním kořenem sdílejí určité společné rozhraní, takže je lze celkově považovat za jeden základní typ. V C++ byla zvolena jiná možnost - společný předek v tomto jazyce neexistuje. Z hlediska kompatibility se starým kódem je tento model více v souladu s tradicí. C a možná si myslíte, že je to méně omezené. Jakmile ale vznikne potřeba plnohodnotného objektově orientovaného programování, budete si muset vytvořit vlastní hierarchii tříd, abyste získali stejné výhody, jaké jsou zabudovány do jiných jazyků OOP. A v každé nové knihovně tříd můžete narazit na nějaké nekompatibilní rozhraní. Začlenění těchto nových rozhraní do architektury vašeho programu bude vyžadovat zvláštní úsilí (a možná i vícenásobnou dědičnost). Vyplatí se ta „flexibilita“ navíc? C++ podobné náklady? Pokud to potřebujete (např. velké investice k vývoji kódu C), pak nebudete poražení. Pokud vývoj začíná od nuly, přístup Jáva vypadá produktivněji.

U všech objektů v jedné kořenové hierarchii je zaručeno, že budou sdílet některé společné funkce. Víte, že určité základní operace lze provádět na jakémkoli objektu v systému. Všechny objekty se snadno vytvářejí na dynamické hromadě a předávání argumentů je výrazně zjednodušeno.

Jediná kořenová hierarchie výrazně usnadňuje implementaci garbage collection – jedno z nejdůležitějších vylepšení Jáva ve srovnání s C++. Vzhledem k tomu, že je zaručeno, že informace o typu budou za běhu přítomny v libovolném z objektů, v systému nikdy nebude objekt, jehož typ nelze určit. To je důležité zejména při provádění systémových operací, jako je zpracování výjimek, a pro větší flexibilitu programování.

Kontejnery

Často není předem známo, kolik objektů bude potřeba k vyřešení určitého problému a jak dlouho budou existovat. Není také jasné, jak takové předměty skladovat. Kolik paměti by mělo být přiděleno pro uložení těchto objektů? Není známo, protože tyto informace budou dostupné pouze za běhu programu.

Mnoho problémů v objektově orientovaném programování je vyřešeno jednoduchá akce: Vytváříte jiný typ objektu. Nový typ objektu, který řeší tento konkrétní problém, obsahuje odkazy na jiné objekty. Tuto roli samozřejmě mohou hrát i pole, která jsou podporována ve většině jazyků. Nicméně, nový objekt, obvykle tzv kontejner(nebo sbírka, ale v Jáva termín se používá v jiném smyslu) se nezbytně rozšíří, aby vyhovoval všemu, co do něj vložíte. Nebudete tedy muset dopředu vědět, pro kolik objektů je kapacita kontejneru určena. Stačí vytvořit kontejner a ten se postará o detaily.

Naštěstí dobrý jazyk OOP přichází se sadou hotových kontejnerů. V C++ je součástí standardní knihovny C++, někdy nazývaná knihovna standardní šablony (Standard Template Library, STL). Pokec přichází s velmi širokou škálou nádob. Jáva také obsahuje kontejnery ve své standardní knihovně. Pro některé knihovny se považuje za dostatečné mít jeden jediný kontejner pro všechny potřeby, ale v jiných (např. Jáva) existují různé kontejnery pro všechny příležitosti: několik různých typů seznamů Seznam (pro ukládání sekvencí prvků), mapy Mapa (také známé jako asociativní pole, umožňují přidružit objekty k jiným objektům), stejně jako množiny soubor (poskytování jedinečných hodnot pro každý typ). Knihovny kontejnerů mohou také obsahovat fronty, stromy, zásobníky a tak dále.

Z hlediska designu opravdu potřebujete pouze kontejner, který může vyřešit váš problém. Pokud jeden typ kontejneru splňuje všechny potřeby, není důvod používat jiné typy. Existují dva důvody, proč si z dostupných kontejnerů musíte vybrat. Za prvé, kontejnery poskytují řadu rozhraní a interakcí. Chování a rozhraní zásobníku se liší od chování a rozhraní fronty, která se chová jinak než sada nebo seznam. Jeden z těchto kontejnerů je schopen poskytnout více než efektivní řešení váš úkol ve srovnání se zbytkem. Za druhé, různé kontejnery provádějí stejné operace různými způsoby. nejlepší příklad- tohle je ArrayList a Spojový seznam . Obě jsou jednoduché sekvence, které mohou mít identická rozhraní a chování. Některé operace se však výrazně liší v době provádění. Řekněme dobu vzorkování libovolného prvku v ArrayList zůstává vždy stejný bez ohledu na to, který prvek je vybrán. Nicméně, v Spojový seznam nevýhodná je práce s náhodným přístupem - čím níže je prvek v seznamu, tím větší zpoždění způsobuje jeho vyhledávání. Na druhou stranu, pokud potřebujete vložit prvek doprostřed seznamu, Spojový seznam udělej to rychleji než ArrayList . Tyto a další operace jsou rozdílná účinnost záleží na vnitřní struktura kontejner. Ve fázi plánování programu si můžete vybrat seznam Spojový seznam a poté během procesu optimalizace přepněte na ArrayList . Vzhledem k abstraktní povaze rozhraní Seznam takový přechod bude vyžadovat minimální změny v kódu.

Parametrizované typy (generika)

Před vydáním Jáva SE5 kontejnery mohly ukládat pouze data Objekt - jediný univerzální typ Jáva. Jednoduchá kořenová hierarchie znamená, že jakýkoli objekt lze považovat za Objekt , tedy kontejner s prvky Objekt vhodné pro skladování jakýchkoliv předmětů Primitivní typy nelze skladovat v kontejnerech, ale díky mechanismu automatické balení(autobox) Java SE5 toto omezení není podstatné. Toto téma bude podrobněji rozebráno později v knize..

Při práci s takovým kontejnerem do něj jednoduše vložíte odkazy na objekty a později je získáte. Ale pokud je kontejner schopen pouze skladování Objekt , pak když je v něm umístěn odkaz na objekt jiného typu, převod na Objekt , tedy ztráta „individuality“ objektu. Při načítání zpět dostanete odkaz Objekt , nikoli odkaz na typ, který byl umístěn v kontejneru. Jak jej převést na konkrétní typ objektu umístěného v kontejneru?

Problém je vyřešen konverzí stejného typu, ale tentokrát nepoužijete upcast (po hierarchii dědičnosti až po základní typ). Nyní používáte metodu převodu hierarchie dědičnosti dolů (na podřízený typ). Tato metoda volala konverze směrem dolů. V případě upcastu je známo, že kruh je figura, takže převod je známý jako bezpečný, ale v případě obráceného obsazení (na dětský typ) nelze předem říci, zda instance představuje Objekt objekt Kruh nebo tvar , takže downcasting je bezpečný pouze v případě, že přesně znáte typ objektu.

Nebezpečí však není tak velké – downcasting na nesprávný typ bude mít za následek tzv. runtime error výjimka(viz. níže). Ale když získáváte odkazy na objekty z kontejneru, musíte si nějakým způsobem zapamatovat skutečný typ jejich objektů, abyste mohli provést správný downcast.

Downcasting a kontrola typu runtime vyžadují od programátora čas a úsilí navíc. Nebo můžete nějakým způsobem vytvořit kontejner, který zná typ uložených objektů, a tím eliminuje potřebu konverze typu a potenciální chyby? Řešení se nazývá mechanismus typová parametrizace. Parametrizované typy jsou třídy, které může kompilátor automaticky přizpůsobit pro práci s určitými typy. Kompilátor může například nakonfigurovat parametrizovaný kontejner pro ukládání a načítání pouze tvarů ( tvar ).

Jedna z nejdůležitějších změn Jáva SE5 je podpora pro parametrizované typy ( generika). Parametrizované typy jsou snadno rozpoznatelné podle lomených závorek, které uzavírají názvy typů parametrů; např. kontejner ArrayList , určený k ukládání předmětů tvar , je vytvořen takto:

ArrayList< Shape >tvary = nový ArrayList< Shape > () ;

Mnoho standardních komponent knihovny bylo také upraveno tak, aby používaly generické typy. Jak brzy uvidíte, v mnoha vzorových programech v této knize se objevují obecné typy.

Tvorba, použití předmětů a jejich životnost

Jeden z kritické aspekty práce s předměty - organizace jejich vzniku a ničení. Pro existenci každého objektu jsou potřeba nějaké zdroje, především paměť. Když objekt již není potřeba, musí být zničen, aby zdroje, které zabírá, mohly být zpřístupněny ostatním. V jednoduchých situacích se úkol nezdá obtížný: vytvoříte objekt, budete jej používat tak dlouho, jak je potřeba, a poté jej zničíte. V praxi však často nastávají složitější situace.

Řekněme, že například vyvíjíte systém pro řízení letového provozu. (Stejný model platí i pro tárování ve skladu, nebo videopůjčovnu nebo boudu toulavých zvířat.) Zpočátku se vše zdá jednoduché: vytvoří se kontejner letadla, pak se postaví nové letadlo, které se umístí do kontejner určité oblasti řízení letového provozu . Pokud jde o uvolnění zdrojů, odpovídající objekt je jednoduše zničen, když letadlo opustí sledovací zónu.

Možná ale existuje jiný systém registrace letadel a tato data nevyžadují takovou pozornost jako hlavní funkceřízení. Možná jsou to záznamy letového plánu všech malých letadel opouštějících letiště. Tak se jeví druhý kontejner pro malá letadla; pokaždé, když je v systému vytvořen nový objekt letadla, je také zahrnut do druhého kontejneru, pokud je letadlo malé. Dále nějaký proces na pozadí pracuje s objekty v tomto kontejneru ve chvílích minimálního vytížení.

Nyní se úkol stává komplikovanějším: jak víte, kdy objekty odstranit? I když jste s objektem skončili, je možné, že s ním stále interaguje jiný systém. Stejná otázka vyvstává v řadě dalších situací a v softwarových systémech, kde je nutné objekty po ukončení práce výslovně mazat (např. C++), je to docela složité.

Kde jsou uložena objektová data a jak se určuje jejich životnost? V C++ Efektivita je na prvním místě, takže programátor má na výběr. Za úspěch nejvyšší rychlost místo provádění a životnost lze určit v době psaní programu. V tomto případě jsou objekty vloženy do zásobníku (takové proměnné se nazývají automatický) nebo do statického úložného prostoru. Hlavním faktorem je tedy rychlost vytváření a ničení objektů a ta může být v některých situacích neocenitelná. To je však za cenu flexibility, protože počet objektů, jejich životnost a typy musí být přesně známy ve fázi návrhu programu. Při řešení problémů širšího profilu - vývoj počítačově podporovaných konstrukčních systémů
(CAD), řízení zásob nebo řízení letového provozu – tento přístup může být příliš omezený.

Druhým způsobem je dynamické vytváření objektů v oblasti paměti zvané „hromada“ ( halda). V tomto případě zůstává počet objektů, jejich přesné typy a životnost až do spuštění programu neznámé. To vše se zjišťuje „za běhu“ za běhu programu. Pokud potřebujete nový objekt, v případě potřeby jej jednoduše vytvoříte na hromadě. Protože je halda spravována dynamicky, alokace paměti z haldy během provádění programu trvá mnohem déle než při alokaci paměti na zásobníku. (Alokace paměti na zásobníku vyžaduje pouze jednu strojovou instrukci, přesunutí ukazatele zásobníku dolů a jeho uvolnění se provede posunutím tohoto ukazatele nahoru. Čas potřebný k alokaci paměti na hromadě závisí na struktuře úložiště.)

Dynamický přístup předpokládá, že objekty jsou velké a složité, takže čas navíc potřebný k alokaci a uvolnění paměti nebude mít významný dopad na proces jejich vytváření. Další flexibilita je pak velmi důležitá pro řešení základních problémů s programováním.

V Jáva používá se pouze druhý přístup Speciálním případem jsou primitivní typy, o kterých bude řeč dále.. Klíčové slovo se používá při každém vytvoření objektu. Nový k vytvoření dynamické instance.

Je tu však ještě jeden faktor, a to životnost objektu. V jazycích, které podporují vytváření objektů v zásobníku, kompilátor určuje, jak dlouho je objekt používán, a může jej automaticky zničit. Když je však objekt vytvořen na haldě, kompilátor nemá žádnou představu o životnosti objektu. V jazycích jako C++, zničení objektu musí být v programu výslovně zarámováno; pokud tak neučiníte, dojde k nevracení paměti (běžný problém v programech C++). V Jáva existuje mechanismus tzv sběr odpadků; automaticky detekuje, když se objekt již nepoužívá, a zničí jej. Garbage collector je velmi šikovný, protože ušetří programátorovi spoustu starostí. Ještě důležitější je, že garbage collector vám dává mnohem větší jistotu, že se do vašeho programu nevloudil zákeřný problém s únikem paměti (což přineslo více než jeden projekt v C++).

V Jáva garbage collector je navržen tak, aby si dokázal poradit s problémem uvolnění paměti sám (to neovlivňuje ostatní aspekty konce životnosti objektu). Garbage Collector "ví", když objekt již není používán, a využívá své znalosti k automatickému uvolnění paměti. Vzhledem k této skutečnosti (spolu s tím, že všechny objekty dědí z jediné základní třídy Objekt a jsou vytvořeny pouze na hromadě) Jáva mnohem jednodušší než programování C++. Developer musí vzít méně rozhodnutí a překonat méně překážek.

Zpracování výjimek: Řešení chyb

Od počátků programovacích jazyků bylo zpracování chyb jedním z nejsložitějších témat. Je velmi obtížné vyvinout dobrý mechanismus zpracování chyb, takže mnoho jazyků tento problém jednoduše ignoruje a nechává to na vývojářích softwarových knihoven. Ty poskytují poloviční řešení, která fungují v mnoha situacích, ale často je lze jednoduše obejít (obvykle tím, že jim prostě nevěnujete pozornost). Hlavním problémem mnoha mechanismů zpracování výjimek je to, že spoléhají na programátorovo svědomité dodržování pravidel, která jazyk nevynucuje. Pokud je programátor neopatrný – a to se často stává, když práce spěchá – může na tyto mechanismy snadno zapomenout.

Mechanismus zpracování výjimek zabuduje zpracování chyb přímo do programovacího jazyka nebo dokonce do něj operační systém. Výjimkou je objekt, který je vyvolán na místě chyby, kterou pak může „chytit“ příslušný obslužný program výjimky určený pro určité typy chyb. Zdá se, že zpracování výjimek definuje cestu paralelního provádění programu, která se projeví, když něco nejde podle plánu. A protože definuje samostatnou cestu provádění, kód zpracování chyb se neplete s normálním kódem. To zjednodušuje psaní programů, protože nemusíte neustále kontrolovat možné chyby. Kromě toho výjimka není jako číselný kód chyby vrácený metodou nebo příznak nastavený v případě problémové situace, kterou lze ignorovat. Výjimku nelze ignorovat, ta se zaručeně někde vyřídí. Konečně výjimky umožňují obnovit normální provoz programu po nesprávné operaci. Místo pouhého ukončení programu můžete situaci napravit a pokračovat v jeho spuštění; čímž se zvyšuje spolehlivost programu.

Mechanismus zpracování výjimek v Jáva se odlišuje od ostatních jazyků, protože byl zabudován do jazyka od samého začátku a je odpovědností vývojáře, aby jej používal. Toto je jediný přijatelný způsob hlášení chyb. Pokud nenapíšete kód pro správné zpracování výjimek, dostanete při kompilaci chybu. Takový konzistentní přístup někdy značně zjednodušuje zpracování chyb.

Stojí za zmínku, že zpracování výjimek není funkcí objektově orientovaného jazyka, i když v těchto jazycích je výjimka obvykle reprezentována objektem. Takový mechanismus existoval ještě před příchodem objektově orientovaných jazyků.

Paralelní programování

Jedním ze základních konceptů programování je myšlenka dělat více věcí současně. Mnoho úloh vyžaduje, aby program přerušil svou aktuální práci, vyřešil nějakou jinou úlohu a poté se vrátil k hlavnímu procesu. Problém byl vyřešen různými způsoby.
Nejprve programátoři, kteří znali architekturu stroje, psali procedury zpracování přerušení, to znamená, že pozastavení hlavního procesu bylo prováděno na hardwarové úrovni. Toto řešení fungovalo dobře, ale bylo složité a nemobilní, což značně ztěžovalo portování takových programů na nové typy počítačů.

Někdy jsou přerušení skutečně nezbytná pro zpracování operací časově kritických úloh, ale existuje celá třída úloh, kde stačí rozdělit úlohu na několik samostatně prováděných částí, aby program rychleji reagoval na vnější vlivy. Tyto samostatně prováděné části programu jsou volány proudy, a celý princip se nazývá konkurence(souběh), popř paralelní počítání. Běžným příkladem souběžnosti je uživatelské rozhraní. V programu s vlákny může uživatel stisknout tlačítko a získat rychlou odpověď, aniž by čekal, až program dokončí aktuální operaci.

Obvykle vlákna pouze definují, jak je přidělen čas jednoho procesoru. Pokud však operační systém podporuje více procesorů, každé vlákno může být přiřazeno samostatnému procesoru; takto je dosaženo skutečného paralelismu. Jednou z příjemných vlastností paralelismu na jazykové úrovni je, že programátor nemusí vědět, zda je v systému jeden nebo více procesorů. Program je logicky rozdělen do vláken a pokud má stroj více procesorů, běží rychleji bez speciálního nastavování.

To vše vytváří dojem, že se streamy používají velmi snadno. Má to ale háček: sdílené zdroje. Pokud se více vláken pokouší o přístup ke stejnému prostředku současně, nastanou problémy. Například dva procesy nemohou současně odesílat informace do tiskárny. Aby se předešlo konfliktu, měly by být sdílené prostředky (například tiskárna) při používání uzamčeny. Vlákno uzamkne prostředek, dokončí svou operaci a poté uvolní zámek, aby k prostředku mohl přistupovat někdo jiný.

Podpora souběžnosti zabudovaná do jazyka Jáva a s výstupem Jáva SE5 přidal významnou podporu na úrovni knihoven.

Jáva a internetu

Pokud Jáva je další programovací jazyk, nabízí se otázka: proč je tak důležitý a proč je prezentován jako revoluční krok ve vývoji softwaru? Z pohledu tradičních programovacích úloh není odpověď hned zřejmá. I když jazyk Jáva užitečné při vytváření samostatných aplikací, jeho nejdůležitější aplikací bylo a zůstává programování pro síť Celosvětová Síť.

co je web?

Na první pohled vypadá web poněkud tajemně kvůli množství nových výrazů jako „surfování“, „přítomnost“ a „domovské stránky“. Abychom pochopili, co to je, je užitečné porozumět celkovému obrazu - ale nejprve musíte porozumět interakci klient / server systémů, které jsou jedním z nejvíce náročné úkoly počítačová výpočetní technika.

Klient/Server Computing

Základní myšlenkou systémů klient/server je, že máte centralizované úložiště informací – obvykle ve formě databáze – a tyto informace jsou dodávány na žádost nějaké skupiny lidí nebo počítačů. V systému klient/server hraje klíčovou roli centralizované úložiště informací, které obvykle umožňuje modifikovat data takovým způsobem, aby se tyto změny rozšířily k uživatelům informací. Vše dohromady: úložiště informací, software, který distribuuje informace, a počítač (počítače), na kterém je software a data uložena, se nazývá server. Software na počítači uživatele, který komunikuje se serverem, přijímá informace, zpracovává je a poté je vhodně zobrazuje, se nazývá klient.

Takže základní koncept počítání klient/server není tak složitý. Problémy vznikají, protože jeden server se snaží obsluhovat mnoho klientů současně. Obvykle je do řešení zapojen systém správy databází a vývojář se snaží „optimalizovat“ datovou strukturu distribucí do tabulek. Kromě toho systém často umožňuje klientovi přidávat na server nové informace. A to znamená, že nové informace klienta musí být chráněny před ztrátou při ukládání do databáze a také před možností jejich přepsání daty od jiného klienta. (Tomu se říká zpracování transakcí.) Když změníte klientský software, musíte jej nejen zkompilovat a otestovat, ale také nainstalovat na klientské počítače, což může být mnohem obtížnější a nákladnější, než si myslíte. Obzvláště obtížné je organizovat podporu pro mnoho různých operačních systémů a počítačových architektur. Nakonec je třeba vzít v úvahu nejdůležitějším faktorem výkon: server může přijímat stovky požadavků současně a sebemenší zpoždění hrozí s vážnými následky. Aby se snížila latence, programátoři se snaží distribuovat výpočty, často i na klientském počítači, a někdy je přenášet na další serverové stroje pomocí tzv. middleware (middleware). (Programy proxy také usnadňují údržbu programů.)

Jednoduchá myšlenka šíření informací mezi lidmi má při implementaci tolik úrovní složitosti, že se její řešení obecně zdá nedosažitelné. A přesto je životně důležitý: je na něm založena asi polovina všech programovacích úloh. Podílí se na řešení problémů od zpracování objednávek a transakcí kreditními kartami až po šíření všech druhů dat – vědeckých, vládních, kurzů akcií... seznam je nekonečný. V minulosti jste museli pro každý nový úkol vytvořit samostatné řešení. Tato řešení není snadné vytvořit, o to složitější je použití a uživatel se s každým novým programem musel naučit nové rozhraní. Úloha klient/server počítání vyžaduje širší přístup.

Web je jako obří server

Ve skutečnosti je web jeden obrovský systém klient/server. To však není vše: jediná síť všechny servery a klienti koexistují současně. Tato skutečnost by vás však neměla zajímat, protože se obvykle připojujete a komunikujete pouze s jedním serverem (i když ho musíte hledat po celém světě).

Nejprve se využívala jednoduchá jednosměrná výměna informací. Zadali jste požadavek na server, ten vám poslal soubor, který pro vás váš prohlížeč (tedy klient) zpracoval. Brzy však pouhé získání statických stránek ze serveru nestačilo. Uživatelé chtěli plně využít systém klient/server, odesílat informace z klienta na server, aby mohli například procházet databázi serveru, přidávat na server nové informace nebo zadávat objednávky (což vyžadovalo speciální bezpečnostní opatření) . Tyto změny neustále sledujeme v procesu vývoje webu.

Nástroje pro prohlížení webu (prohlížeče) byly velkým krokem vpřed: zavedly koncept informací, které se zobrazují stejným způsobem na jakémkoli typu počítače. První prohlížeče však byly stále primitivní a rychle přestaly splňovat požadavky. Ukázalo se, že nejsou nijak zvlášť interaktivní a zpomalovaly práci jak serverů, tak internetu jako celku – pro jakoukoli akci, která vyžadovala programování, bylo nutné odeslat informace na server a počkat, až je zpracuje. Někdy jste museli čekat několik minut, abyste zjistili, že jste v žádosti vynechali jeden dopis. Vzhledem k tomu, že prohlížeč byl pouze prohlížeč, nemohl provádět ani ty nejjednodušší programovací úkoly. (Na druhou stranu to zaručovalo bezpečnost - uživatel byl chráněn před spuštěnými programy obsahujícími viry nebo chyby.)

K řešení těchto problémů byly přijaty různé přístupy. Pro začátek byly vylepšeny standardy grafického zobrazení, takže prohlížeče mohou zobrazovat animace a videa. Zbývající úlohy vyžadovaly schopnost spouštět programy na klientském počítači v prohlížeči. Tomu se říká programování na straně klienta.

Programování na straně klienta

Zpočátku byl systém interakce server-prohlížeč navržen pro interaktivní obsah, ale podpora této interaktivity byla zcela svěřena serveru. Server vygeneroval statické stránky pro prohlížeč klienta, který je jednoduše zpracoval a zobrazil. Standard HTML podporuje nejjednodušší vstupy: textová pole, přepínače, zaškrtávací políčka, seznamy a rozevírací seznamy spolu s tlačítky, která mohou provádět pouze dvě věci: resetovat data formuláře a odeslat je na server. Odeslané informace zpracovává rozhraní CGI (Common Gateway Interface), podporované všemi webovými servery. Text požadavku označuje CGI jak s daty zacházet. Nejčastěji se na vyžádání spouští program z adresáře cgi-bin na serveru. (V řádku s adresou stránky v prohlížeči můžete po odeslání údajů formuláře občas vidět podřetězec ve změti znaků cgi-bin.) Takové programy lze psát téměř ve všech jazycích. Běžně používané Perl, protože je textově orientovaný a také interpretovaný jazyk, lze jej tedy použít na jakémkoli serveru bez ohledu na typ procesoru nebo operačního systému. Nicméně jazyk Krajta(můj oblíbený jazyk - jít na www.Python.org) si od něj svou silou a jednoduchostí postupně získává zpět „území“.

Mnoho výkonných webových serverů dnes funguje výhradně na CGI; v zásadě vám tato technologie umožňuje vyřešit téměř jakýkoli problém. Webové servery však stavěly na CGI programy se obtížně udržují a mají problémy s odezvou. Doba odezvy CGI-program závisí na množství odesílaných informací a také na zatížení serveru a sítě. (Kvůli všem zmíněným spuštěním CGI program může trvat dlouho). První návrháři webu nepředpokládali, jak rychle budou zdroje systému vyčerpány, protože byl používán v různých aplikacích. Například je téměř nemožné v něm zobrazovat grafy v reálném čase, protože při jakékoli změně situace je nutné sestavit nový soubor GIF a přenést jej na klienta. Nepochybně jste zažili své vlastní trpké zkušenosti – například z pouhého odeslání údajů z formuláře. Stisknutím tlačítka odešlete informace; server se spustí CGI- program, který zjistí chybu, vygeneruje HTML- stránka, která vám o tom řekne, a poté pošle tuto stránku vaším směrem; musíte znovu zadat data a zkusit to znovu. Nejen, že je to pomalé, je to jednoduše nevkusné.

Problém je řešen programováním na straně klienta. Prohlížeče zpravidla běží na výkonných počítačích schopných řešit širokou škálu úkolů a se standardním přístupem HTML počítač jednoduše čeká na doručení další stránky. Díky programování na straně klienta dostává prohlížeč veškerou práci, kterou může udělat, a pro uživatele se to promítá do rychlejšího procházení webu a lepší interaktivity.

Diskuse o klientském programování se však příliš neliší od diskusí o programování obecně. Podmínky jsou stejné, ale platformy se liší: prohlížeč připomíná silně osekaný operační systém. Stejně musíte programovat, takže programování na straně klienta vytváří závratnou řadu problémů a řešení. Tato část končí přehledem některých problémů a přístupů, které jsou vlastní programování na straně klienta.

Rozšiřující moduly

Jednou z nejdůležitějších oblastí klientského programování se stal vývoj rozšiřujících modulů ( zásuvné moduly). Tento přístup umožňuje programátorovi přidat do prohlížeče nové funkce stažením malého programu, který je zabudován do prohlížeče. Ve skutečnosti od tohoto okamžiku prohlížeč získává nové funkce. (Rozšiřující modul se načte pouze jednou.) Pluginy poskytly prohlížečům řadu rychlých a výkonných inovací, ale napsat takový modul není snadný úkol a je nepravděpodobné, že byste chtěli vytvářet rozšíření pokaždé, když vytváříte nový web. Hodnota zásuvných modulů pro klientské programování spočívá v tom, že umožňují zkušenému programátorovi přidávat do prohlížeče nové funkce, aniž by žádal o povolení jeho tvůrce. Rozšiřující moduly tedy poskytují „zadní vrátka“ pro integraci nových programovacích jazyků na straně klienta (ačkoli ne všechny jazyky jsou v takových modulech implementovány).

Skriptovací jazyky

Vývoj zásuvných modulů dal vzniknout mnoha skriptovacím jazykům. Pomocí skriptovacího jazyka vložíte klientský program přímo do HTML-page a modul, který zpracovává tento jazyk, se automaticky aktivuje při jeho prohlížení. Skriptovací jazyky se obvykle učí poměrně snadno; v podstatě je kód skriptu text, který je součástí HTML-pages, takže se načte velmi rychle jako součást jednoho požadavku na server během načítání stránky. Cena za to je, že kdokoli může zobrazit (a ukrást) váš kód. Je však nepravděpodobné, že byste ve skriptovacích jazycích napsali něco emulovaného a sofistikovaného, ​​takže problém s kopírováním kódu není tak hrozný.

Skriptovací jazyk, který je podporován téměř každým prohlížečem bez instalace dalších modulů, je JavaScript(má velmi málo společného Jáva; jméno bylo použito za účelem "ukořistit" kus úspěchu Jáva na trhu). Bohužel původní realizace JavaScript v různých prohlížečích byly navzájem zcela odlišné a dokonce i mezi různými verzemi stejného prohlížeče. Standardizace JavaScript ve tvaru ECMAScript byla užitečná, ale chvíli trvalo, než se její podpora objevila ve všech prohlížečích (navíc spol Microsoft aktivně propagovali svůj vlastní jazyk VBScript, nejasně připomínající JavaScript). V obecném případě se developer musí omezit na minimum možností JavaScript takže kód bude zaručeně fungovat ve všech prohlížečích. Ohledně zpracování chyb a ladění kódu JavaScript, pak je to přinejlepším obtížný úkol. Teprve nedávno byli vývojáři schopni vytvořit skutečně komplexní systém zapsáno v JavaScript(společnost Google, servis Gmail), a to vyžadovalo nejvyšší nadšení a zkušenosti.

To ukazuje, že skriptovací jazyky používané v prohlížečích byly navrženy pro řadu specifických úkolů, zejména pro vytvoření bohatšího a interaktivnějšího grafického uživatelského rozhraní ( GUI). Skriptovací jazyk však lze použít pro 80 % úloh klientského programování. Váš úkol může být právě v těch 80%. Protože skriptovací jazyky usnadňují a urychlují tvorbu programovací kód, měli byste nejprve zvážit právě takový jazyk, než přejdete ke složitějším technologickým řešením, jako je Jáva.

Jáva

Jestliže skriptovací jazyky převezmou 80 % úloh klientského programování, kdo pak zvládne zbývajících 20 %? Pro ně je dnes nejoblíbenější řešení Jáva. Nejen, že je to výkonný programovací jazyk navržený s ohledem na bezpečnost, kompatibilitu platforem a internacionalizaci, ale je to také neustále se vyvíjející nástroj s novými funkcemi a knihovnami, které elegantně zapadají do tradičně složitých programovacích úloh: multitasking, přístup k databázi, síťové programování a distribuované počítání. Klientské programování Jáva záleží na vývoji apletů a také na použití balíčku Java Web Start.

Applet je miniprogram, který lze spustit pouze v prohlížeči. Applety se automaticky načítají jako součást webové stránky (stejným způsobem, jako se načítá například grafika). Když je aplet aktivován, spustí program. To je jedna z výhod apletu - umožňuje automaticky distribuovat programy klientům ze serveru přesně tehdy, když uživatel tyto programy potřebuje, a ne dříve. Uživatel obdrží nejnovější verzi klientského programu, a to bez problémů a potíží spojených s přeinstalací. Podle ideologie Jáva, programátor vytvoří pouze jeden program, který se automaticky spustí na všech počítačích, které mají prohlížeče s vestavěným interpretem Jáva. (To platí téměř pro všechny počítače.) Od Jáva je kompletní programovací jazyk, co nejvíce práce by mělo být provedeno na straně klienta před (nebo po) volání serveru. Například nemusíte posílat požadavek přes internet, abyste zjistili, že došlo k chybě v přijatých datech nebo některých parametrech, a klientský počítač může rychle nakreslit nějaký druh grafu, aniž by čekal, až to server udělá a poslat zpět soubor obrázku. Toto schéma nejenže poskytuje okamžitou výhodu rychlosti a odezvy, ale také snižuje zatížení hlavního síťového přenosu a serverů a zabraňuje zpomalení celkového internetového zážitku.

Alternativy

Abych byl upřímný, applety Jáva neospravedlňovalo počáteční nadšení. Při prvním vystoupení Jáva všichni byli velmi nadšeni applety, protože umožňovaly seriózní programování na straně klienta, zvýšenou odezvu a sníženou šířku pásma pro internetové aplikace. Předpovídalo se, že applety budou mít velkou budoucnost.

Na webu lze skutečně nalézt řadu velmi zajímavých appletů. A přesto hromadný přechod na applety neproběhl. Asi hlavním problémem bylo stažení 10 MB balíčku pro instalaci prostředí Java Runtime Environment (JRE) příliš děsivé pro běžného uživatele. Skutečnost, že společnost Microsoft nezapnul JRE v dodávce internet Explorer, nakonec rozhodl o osudu appletů. Každopádně applety Jáva nebyly široce používány.

Nicméně applety a aplikace Java Web Start jsou v některých situacích velmi užitečné. Pokud je konfigurace počítačů koncových uživatelů pod kontrolou (například v organizacích), je použití těchto technologií k distribuci a aktualizaci klientských aplikací zcela oprávněné; šetří to spoustu času, práce a peněz (zejména při častých aktualizacích).

.NET a C#

Po nějakou dobu hlavní uchazeč Jáva-aplety byly považovány za komponenty ActiveX od společnosti Microsoft, ačkoli pro svou práci vyžadovali přítomnost na stroji klienta Okna. Nyní Microsoft protichůdný Jáva plnohodnotní konkurenti: je to platforma .SÍŤ a programovacím jazykem Z#. Plošina .SÍŤ je zhruba stejný jako virtuální stroj Jáva(JVM) a knihovny Jáva a jazyk Z# má jasnou podobnost s jazykem Jáva. Bezpochyby jde o to nejlepší, co Microsoft v oblasti programovacích jazyků a prostředí vytvořil. Samozřejmě, že vývojáři Microsoft měl nějakou výhodu; viděli to v Jáva uspěl a co ne, a mohl na těchto faktech stavět, ale výsledek se ukázal být docela hodný. Poprvé od jeho narození, Jáva byl tam skutečný konkurent. Vývojáři z slunce se musel podívat Z#, zjistěte, proč by programátoři mohli chtít přejít na tento jazyk, a vynaložit veškeré úsilí na výrazné zlepšení Jáva v Jáva SE5.

V tento moment hlavní otázkou je, zda Microsoft umožní úplné přenesení .SÍŤ na jiné platformy. V Microsoft tvrdí, že v tom není žádný problém, a projekt mono() poskytuje částečnou realizaci .SÍŤ pro linux. Vzhledem k tomu, že tato implementace je zatím neúplná Microsoft se nerozhodne vyhodit žádnou jeho část, vsadit .SÍŤ jako multiplatformní technologie je stále brzy.

Internet a intranet

Web poskytuje nejobecnější řešení pro úlohy klient/server, takže má smysl používat stejnou technologii k řešení konkrétních problémů; to platí zejména pro klasickou interakci klient/server v rámci společnosti. Tradiční přístup klient/server má problémy s rozdíly v typech klientských počítačů, což k nim přidává potíže při instalaci nových programů pro klienty; oba problémy řeší prohlížeče a programování na straně klienta. Když se webová technologie používá k vytvoření informační sítě v rámci společnosti, nazývá se taková síť intranet. Intranet poskytuje mnohem větší zabezpečení než internet, protože můžete fyzicky řídit přístup k serverům vaší společnosti. Pokud jde o učení, pro někoho, kdo rozumí konceptu prohlížeče, je mnohem snazší porozumět různým stránkám a apletům, takže se zkrátí čas na zvládnutí nových systémů.

Problematika bezpečnosti nás přivádí k jednomu ze směrů, který při programování klientů automaticky vzniká. Pokud váš program běží na internetu, pak nevíte, na jaké platformě poběží. Je třeba věnovat zvláštní pozornost tomu, aby se zabránilo šíření nesprávného kódu. Zde potřebujeme multiplatformní a bezpečná řešení, např Jáva nebo skriptovací jazyk.

Intranet má další omezení. Poměrně často všechny stroje v síti běží na platformě Intel/Windows. Na intranetu jste odpovědní za kvalitu svého kódu a můžete opravit chyby, jakmile se najdou. Kromě toho již můžete mít sadu řešení, která prokazatelně fungují v tradičnějších systémech klient/server, zatímco nový software je nutné ručně nainstalovat na klientský počítač při každém upgradu. Čas strávený aktualizacemi je nejsilnějším argumentem ve prospěch technologií prohlížečů, kde se aktualizace provádějí neviditelně a automaticky (totéž lze Java Web Start). Pokud se podílíte na údržbě intranetu, je moudřejší jít cestou, která vám umožní využít to, co již máte, aniž byste museli přepisovat programy do nových jazyků.

Když čelíte obrovskému množství úloh klientského programování, které mohou zarazit každého návrháře, je nejlepší je zhodnotit z hlediska poměru nákladů a přínosů. Zvažte omezení svého problému a zkuste si představit nejkratší cestu, jak jej vyřešit. Protože klientské programování je stále programování, jsou vždy relevantní vývojové technologie, které slibují nejrychlejší řešení. Tento proaktivní přístup vám dá příležitost připravit se na nevyhnutelné problémy programování.

Programování na straně serveru

Naše diskuse obešla téma programování na straně serveru, které mnozí považují za nejvíce silný bod Jáva. Co se stane, když odešlete požadavek na server? Častěji než ne, požadavek sestává z jednoduchého požadavku „odešlete mi tento soubor“. Prohlížeč pak soubor náležitě zpracuje: jako HTML-stránka jako obrázek jako Jáva-applet, jako skript atd.

Složitější požadavek na server obvykle zahrnuje přístup k databázi. V nejběžnějším případě je požadováno komplexní prohledávání databáze, jehož výsledky jsou následně serverem převedeny do HTML-stránku a odešle vám. (Samozřejmě, pokud je klient schopen provést nějakou akci pomocí Jáva nebo skriptovací jazyk, data může zpracovávat on sám, což bude rychlejší a sníží zatížení serveru.) Nebo se možná budete muset zaregistrovat do databáze při vstupu do skupiny nebo pokladny, což bude vyžadovat změny v databázi. Takové požadavky musí být zpracovány nějakým kódem na serveru; obecně se tomu říká programování na straně serveru. Programování serveru se tradičně provádělo na Perl, Python, C++ nebo jiný jazyk, který umožňuje vytvářet programy CGI, ale existují zajímavější možnosti. Patří mezi ně ty založené na Jáva webové servery, které umožňují programování na straně serveru Jáva pomocí tzv. servletů. Servleti a jejich potomci JSP, jsou dva hlavní důvody, proč společnosti s webovým obsahem přecházejí Jáva, hlavně proto, že řeší problémy s nekompatibilitou mezi různými prohlížeči.

Přes všechny ty řeči Jáva jako internetový programovací jazyk, Jáva ve skutečnosti jde o plnohodnotný programovací jazyk schopný řešit téměř všechny problémy řešené v jiných jazycích. Výhody Jáva nejsou omezeny na dobrou přenositelnost: je to vhodnost pro řešení problémů s programováním, odolnost proti chybám a velká standardní knihovna a četné vývojové trendy třetích stran – existující i neustále se objevující.

souhrn

Víte, jak vypadá procedurální program: definice dat a volání funkcí. Zjištění účelu takového programu vyžaduje úsilí tím, že se podíváte na funkce a vytvoříte si ve své mysli velký obrázek. Z tohoto důvodu vyžaduje tvorba takových programů použití zprostředkujících nástrojů - samy o sobě jsou více orientovány na počítač, nikoli na řešený úkol.

Protože OOP přidává mnoho nových konceptů k těm, které jsou již k dispozici v procedurálních jazycích, je přirozené předpokládat, že kód Jáva bude mnohem složitější než podobná metoda v procedurálním jazyce. Zde na vás ale čeká příjemné překvapení: dobře napsaný program v Jáva obvykle mnohem snáze pochopitelný než jeho procesní protějšek. Vše, co vidíte, jsou definice objektů, které představují koncepty rozhodovacího prostoru (nikoli koncepty implementace počítače), a zprávy odeslané těmto objektům, které představují akce v tomto prostoru. Jednou z výhod OOP je, že dobře navržený program lze pochopit jednoduše pohledem na zdrojový kód. Kromě toho obvykle musíte psát mnohem méně kódu, protože mnoho úloh lze již snadno vyřešit. existující knihovny třídy.

Objektově orientované programování a jazyk Jáva nejsou vhodné pro každého. Je velmi důležité nejprve zjistit své potřeby, abyste se mohli rozhodnout, zda přejít na Jáva nebo je lepší zvolit jiný programovací systém (včetně toho, který právě používáte). Pokud víte, že v dohledné době budete čelit velmi specifickým potřebám nebo bude vaše práce podléhat omezením, která Jáva nezvládá, je lepší zvážit jiné možnosti (zejména doporučuji se blíže podívat na jazyk Krajta,). Výběr Jáva, musíte pochopit, jaké další možnosti jsou k dispozici a proč jste zvolili tuto cestu.

Výměna zpráv:

Pošlete přímo této straně: http://website/javabooks/Thinking_in_Java_4th_edition.html Zašlete BB kódy: Thinking_in_Java_4th_edition
html zpráva: