Da biste promijenili zadani dokument, ručno uredite datoteku "blank.fb2".

Predgovor 13

Java SE5 i SE6 14

hvala 14

Poglavlje 1 Uvod u objekte 17

Razvoj apstrakcije 18

Objekt ima sučelje 20

Ustanova pruža usluge 22

Skrivena implementacija 23

Implementacija ponovne upotrebe 24

Nasljeđe 25

Zamjenjivi objekti i polimorfizam 29

Jednokorijenska hijerarhija 33

Kontejneri 33

Parametrizirani tipovi 35

Nastanak, uporaba predmeta i njihov životni vijek 36

Rukovanje iznimkama: rješavanje grešaka 38

Paralelno izvođenje 38

Java i Internet 39

Poglavlje 2. Sve je objekt 48

Svi objekti moraju biti eksplicitno kreirani 49

Objekti se nikada ne moraju brisati 53

Stvaranje novih tipova podataka 54

Metode, argumenti i povratne vrijednosti 56

Izrada Java 58 programa

Ključna riječ statična 60

Naš prvi program Java 61

Komentari i ugrađena dokumentacija 64

Stil dizajna programa 70

Poglavlje 3 Operatori 71

Jednostavne naredbe za ispis 71

Java 72 izjave

Literali 82

Javi nedostaje sizeof() 92

Životopis 100

Poglavlje 4 Kontrolne strukture 101

Sintaksa foreach 105

pauza i nastavak 108

Loša naredba idi na 109

Životopis 115

Poglavlje 5 Inicijalizacija i prekid 116

Konstruktor jamči inicijalizaciju 116

Preopterećenje metode 118

Čišćenje: finalizacija i odvoz smeća 130

Inicijaliziranje članova klase 137

Inicijalizacija konstruktora 140

Inicijalizacija polja 146

Životopis 151

Poglavlje 6 Kontrola pristupa 152

Paket kao knjižnični modul 153

Java Specifikatori pristupa 159

Sučelje i implementacija 163

Pristup nastavi 164

Životopis 167

Poglavlje 7 Ponovno korištenje klasa 169

Sintaksa kompozicije 170

Sintaksa nasljeđivanja 172

Delegacija 176

Kombiniranje sastava i nasljeđivanja 178

Sastav nasuprot nasljeđivanju 184

Pretvorba tipa prema gore 186

Ključna riječ final 188

Životopis 197

Poglavlje 8. Polimorfizam 198

Opet o transformaciji prema gore. . . > 199

Značajke 201

Konstruktori i polimorfizam 208

Kovarijanca tipa povrata 216

Razvoj s nasljeđivanjem 217

Životopis 220

Poglavlje 9 Sučelja 221

Apstraktne klase i metode 221

Sučelja 224

Odvajanje sučelja od implementacije 227

Proširenje sučelja putem nasljeđivanja 233

Sučelja kao sredstvo prilagodbe 236

Ugniježđena sučelja 239

Sučelja i tvornice 242

Životopis 244

Poglavlje 10 Unutarnje klase 245

Stvaranje unutarnjih klasa 245

Komunikacija s vanjskom klasom 246

Konstrukti .this i .new 248

Unutarnje klase i preobrazba 249

Neimenovane interne klase 253

Interni razredi: zašto? 261

Nasljeđe od unutarnjih klasa 272

Je li moguće nadjačati unutarnju klasu? 272

Lokalne unutarnje klase 274

Životopis 276

Poglavlje 11 Zbirke objekata 277

Parametrirani i tipizirani spremnici 277

Temeljni koncepti 280

Dodavanje grupa elemenata 281

Iteratori 288

Skup 294

Red 298

PriorityQueue 299

Kolekcija i iterator 301

Idiom "metod-adapter" 306

Životopis 309

Poglavlje 12. Rukovanje pogreškama i iznimkama 310

Glavne iznimke 310

Hvatanje 312 iznimaka

Stvaranje vlastitih izuzetaka 314

Specifikacije izuzetaka 319

Hvatanje proizvoljnih iznimaka 320

Standardne iznimke Java 328

Prekid s konačno 330

Korištenje finally s povratkom 334

Ograničenja pri korištenju iznimaka 336

Konstruktori 339

Identifikacija iznimke 343

Alternativna rješenja 344

Životopis 351

Poglavlje 13 Podaci o vrsti 352

Potreba za zaključivanjem dinamičkog tipa (RTTI) 352

Registracija tvornica 372

Refleksija: informacije o dinamičkoj klasi 376

Dinamički posrednici 380

Objekti neodređenog stanja 384

Sučelja i informacije o vrsti 390

Životopis 394

Poglavlje 14 Parametriranje 397

Jednostavna parametrizacija 398

Parametrizirana sučelja 404

Parametrizirane metode 407

Modeli kompleksa zgrada 419

Ograničenja 437

Metaznakovi 440

Životopis 452

Poglavlje 15 Nizovi 454

Značajke nizova 454

Niz kao objekt 456

Povratak polja 458

Višedimenzionalni nizovi 460

Nizovi i parametrizacija 463

Stvaranje testnih podataka 465

Stvaranje nizova pomoću generatora 470

Arrays 474 Helper Toolkit

Životopis 482

Poglavlje 16 Java I/O sustav 483

Datoteka 484 klase

Ulaz i izlaz 489

Dodavanje atributa i sučelja 491

Razredi čitača i pisaca 494

RandomAccessFile: sam po sebi 497

Uobičajena upotreba I/O tokova 498

Čitači i zapisivači datoteka 505

Standardni I/O 507

Novi I/O (nio) 510

Kompresija podataka 531

Serijalizacija objekata 536

Postavke 553

Životopis 555

Poglavlje 17 Paralelno izvođenje 557

Klasa navoja 559

Umjetnici 561

Dijeljenje resursa 578

Komunikacija između niti 598

Međusobno blokiranje 602

Nove komponente knjižnice 607

Zasun odbrojavanja 607

CyclicBarrier 609

PriorityBlockingQueue 614

Semafori 619

Modeliranje 624

Životopis 629

Abecedno kazalo 631

Uvod u objekte

Raščlanjujemo prirodu, pretvaramo je u pojmove i pripisujemo im značenje, kao što to činimo na mnogo načina, jer smo svi strane u sporazumu koji vrijedi u društvu vezanom govorom, a koji je fiksiran u strukturi jezika. .. Ne možemo uopće komunicirati, osim pristankom na organizaciju i klasifikaciju podataka utvrđenu ovim ugovorom.

Benjamin Lee Worf (1897.-1941.)

Pojavu računalne revolucije dugujemo stroju. Stoga naši programski jezici pokušavaju biti bliži ovom stroju.

Ali u isto vrijeme, računala nisu toliko mehanizmi koliko su sredstva za pojačavanje misli ("bicikli za um", kako voli reći Steve Jobs), i još jedno sredstvo samoizražavanja. Kao rezultat toga, alati za programiranje manje se oslanjaju na strojeve, a više na naš um, kao i na druge oblike izražavanja ljudskih težnji, poput književnosti, slikarstva, kiparstva, animacije i filma. Objektno orijentirano programiranje (OOP) dio je pretvaranja računala u vozilo za samoizražavanje.

Ovo poglavlje će vas upoznati s osnovama OOP-a, uključujući pogled na glavne metode razvoja softvera. Ona, kao i knjiga općenito, pretpostavlja da imate iskustva u programiranju na proceduralnom jeziku, ne nužno C. Ako smatrate da vam prije čitanja ove knjige nedostaje znanja o programiranju i C sintaksi, upotrijebite multimedijski seminar Thinking in C. koji može preuzeti s web stranice

U ožujku prošle godine prijavio se u podružnicu velike međunarodna tvrtka u Samari (da. Od djetinjstva imam mnogo arogancije i ambicije). U to vrijeme znao sam html, css, java, javascript (osnove), pascal, visualbasic6, mysql upite, php, Generalna ideja:c++. Javu uopće nisam poznavao. Nudili su mi posao layout dizajnera, ali sam ga odbio. Samo kao programer! Onda su mi dali popis:

Bruce Eckel Razmišljanje u Javi (ruski prijevod 2. izdanja ili izvornik 4. - pročitajte oba)
-Steve McConnell - savršen kod.
- Grupa od četiri - Dizajn uzorka. (ovo je skoro ABC OOP-a)
-biti što jasniji u vezi s razlikom između j2se i j2ee.

prosinca ukazala se potreba. dobio posao u malom samarskom web-studiju. odmah je bilo jasno da se radi o prevarantima, ali svaki rad koji sam mogao pokazati budućim poslodavcima je bio potreban. nisu platili (iako su sve uši pojedene obećanjima), ali su doveli kod prema standardima dizajna, i što je najvažnije, naučili su gdje tražiti i što tražiti u slučaju pogrešaka, koje su male stvari jednostavne nedostajati.

Uz gornju literaturu, pohađao sam intuit tečaj (sad shvaćam da je smiješan u svom opsegu, ali u principu ima tu osnova)

Krajem veljače ponovno sam poslala životopis i dobila poziv na razgovor. Ukupno je bilo 6 intervjua koji su trajali 1,5 mjesec. Dva su održana putem videoveze s Moskvom. Cijela slika podsjećala je na film “Dođi sutra”. Ali na kraju sam dobio ponudu za posao. Ugovor je sastavljen za nepuno radno vrijeme, jer. U to vrijeme nisam imao diplomu. Prošlog mjeseca sam dobio diplomu i ugovor je obnovljen za puno radno vrijeme.

Trenutna pozicija Soft-Engineer. Plaća je više nego zadovoljavajuća. Jučer su ga, vezano uz prelazak na puno radno vrijeme, podigli za 30%.

Čak su i u uredu tog prevaranta tražili primjere rada. Prezentirala sam posao koji sam radila kao slobodnjak. Čak su i djela na drugim jezicima uvijek mnogo bolja nego nikakva.

Ps: diploma plava iz FIZIKE. Potpuno sam samouk, tako da je sve u vašim rukama. Imam samo engleski iz škole Besplatno (7 sati tjedno). iako ga Amerikanac koji je došao k nama tijekom svog putovanja oko svijeta ne poznaje dobro. Jedva sam pola razumjela zbog njegova naglaska. ali to nije toliko kritično u mom odjelu. sva dokumentacija na engleskom - naučit ćete i ako niste znali)))))

Posebno hvala ovom forumu. Zapravo sam studirao ovdje- svakodnevno podučava sve teme koje naiđu)

KNJIŽNICA PROGRAMERA

Bruce Eckel

4. izdanje

(^PPTER

Moskva - Sankt Peterburg - Nižnji Novgorod - Voronjež Rostov na Donu - Jekaterinburg - Samara - Novosibirsk Kijev - Harkov - Minsk

BBK 32.973 2-018.1

Eckel B.

E38 Java filozofija. Programerska biblioteka. 4. izd. - St. Petersburg: Peter, 2009. - 640 e.: ilustr. - (Serija "Programerska biblioteka").

ISBN 978-5-388-00003-3

Java se ne može razumjeti promatrajući je samo kao skup nekih harakureški - potrebno je shvatiti zadatke ovog jezika kao posebne probleme programiranja općenito. r3ia je knjiga o programskim problemima: zašto su postali problemi i koji pristup koristi Java da ih riješi. Stoga su značajke jezika o kojima se govori u svakom poglavlju neraskidivo povezane s načinom na koji se koriste za rješavanje određenih problema.

Ova knjiga, koja je izdržala mnoga pretiska u izvorniku, zbog svoje duboke i istinski filozofske prezentacije zamršenosti jezika, smatra se jednim od najboljih priručnika za Java programere.

BBK 32.973.2-018.1 UDK 004.3

Prava na objavljivanje dobivena ugovorom s Prentice Hall PTR.

Sva prava pridržana. Nijedan dio ove knjige ne smije se reproducirati u bilo kojem obliku bez pismenog dopuštenja nositelja autorskih prava.

Podaci sadržani u ovoj knjizi dobiveni su iz izvora za koje izdavač vjeruje da su pouzdani. Međutim, s obzirom na moguće ljudske ili tehničke pogreške, izdavač ne može jamčiti apsolutnu točnost i potpunost navedenih informacija i nije odgovoran za moguće greške vezano uz korištenje knjige.

ISBN 978-0131872486 © Prentice Hall PTR, 2006.

ISBN 978-5-388-00003-3 © Prijevod na ruski Peter Press LLC, 2009.

© Publikacija na ruskom, dizajn Piter Press LLC, 2009

Predgovor.................................13

Java SE5 i SE6 ............................14

Zahvale.................................14

Poglavlje 1 Uvod u objekte.....................................17

Razvoj apstrakcije .........................18

Objekt ima sučelje.................................20

U objektu se pružaju usluge............................22

Skrivena implementacija.................................23

Ponovna upotreba implementacije.....................................24

Nasljeđe.....................................25

Zamjenjivi objekti i polimorfizam.................................29

Jednokorijenska hijerarhija............................33

Spremnici.................................33

Parametrizirani tipovi............................35

Nastanak, uporaba predmeta i vrijeme njihova života............................36

Rukovanje iznimkama: rješavanje grešaka.................................38

Paralelno izvođenje................................38

Java i Internet.....................................39

Sažetak.....................................47

Poglavlje 2 Sve je objekt................................................48

Svi objekti moraju biti eksplicitno kreirani.................................49

Objekti se nikada ne moraju brisati.................................53

Stvaranje novih tipova podataka................................54

Metode, argumenti i povratne vrijednosti............................................56

Izrada Java programa................................................58

Ključna riječ statična............................60

Naš prvi Java program............................................61

Komentari i ugrađena dokumentacija.....................................64

Stil programiranja ............................................70

Sažetak.....................................70

Poglavlje 3. Operatori.....................................71

Jednostavne naredbe za ispis.....................................71

Java naredbe.............................72

Literali.....................................82

Javi nedostaje sizeof() ............................................92

Životopis.............................100

Poglavlje 4 Kontrolne strukture .................101

Sintaksa foreach.............................105

povratak, ...................................107

pauza i nastavak.....................................108

Loša goto naredba .........................109

Sažetak.....................................115

Poglavlje 5. Inicijalizacija i prekid......................116

Inicijalizacija jamstava konstruktora.................................116

Preopterećenje metode.................................118

Čišćenje: finalizacija i sakupljanje smeća.................................130

Inicijaliziranje članova klase.................................137

Inicijalizacija konstruktora ................................140

Inicijaliziranje nizova.................................146

Sažetak.................................151

Poglavlje 6 Kontrola pristupa ............................152

Paket kao modul knjižnice.............................153

Java specifikatori pristupa.................................159

Sučelje i implementacija.................................163

Pristup nastavi.....................................164

Sažetak.....................................167

Poglavlje 7 Ponovno korištenje klasa.....................................169

Sintaksa sastava............................170

Sintaksa nasljeđivanja............................172

Delegiranje.....................................176

Kombiniranje sastava i nasljeđivanja............................178

Kompozicija nasuprot nasljeđivanju.................................184

zaštićeno.................................185

Pretvorba tipa prema gore.....................................186

Konačna ključna riječ.................................188

Sažetak.....................................197

Poglavlje 8 Polimorfizam

Opet o transformaciji prema gore. . . >................199

Značajke...................................201

Konstruktori i polimorfizam.................................208

Kovarijanca tipa povrata.....................................216

Projektiranje s nasljeđivanjem............................217

Životopis.................................220

Poglavlje 9. Sučelja.....................221

Apstraktne klase i metode.....................................221

Sučelja.....................................224

Odvajanje sučelja od implementacije.................................227

Proširenje sučelja putem nasljeđivanja.....................233

Sučelja kao sredstvo prilagodbe............................................236

Ugniježđena sučelja.................................239

Sučelja i tvornice.................................242

Životopis............................244

Poglavlje 10. Unutarnje klase.................................245

Stvaranje unutarnjih klasa.................................245

Komunikacija s vanjskim razredom.................................246

Konstrukti .this i .new............................248

Unutarnje klase i pretvorba prema gore.....................249

Neimenovane unutarnje klase.....................253

Unutarnje klase: zašto? .............................. 261

Nasljeđe iz unutarnjih klasa.................................272

Je li moguće nadjačati unutarnju klasu?.....................272

Lokalne unutarnje klase.................................274

Sažetak.....................................276

Poglavlje 11. Zbirke predmeta.................................277

Parametrirani i tipizirani spremnici.....................277

Osnovni pojmovi.................................280

Dodavanje grupa elemenata.................................281

Popis.................................285

Iteratori.....................................288

Povezani popis.................................291

Stog.................................292

Puno................................................. 294

Zemljovid.................................296

Red čekanja.................................298

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

Kolekcija i iterator............................301

Idiom "metoda-adapter" .........................306

Životopis................................309

Poglavlje 12. Rukovanje pogreškama i iznimkama...................310

Veliki izuzeci.....................................310

Hvatanje iznimaka............................312

Stvaranje vlastitih iznimaka............................314

Specifikacije izuzetaka.................................319

Hvatanje proizvoljnih iznimaka............................320

Standardne Java iznimke.................................328

Završava s konačno.................................330

Korištenje konačno s povratkom............................334

Ograničenja korištenja iznimaka............................336

Konstruktori................................339

Identifikacija iznimaka.................................343

Alternativna rješenja............................344

Sažetak.....................................351

Poglavlje 13 Informacije o tipu.....................................352

Potreba za zaključivanjem dinamičkog tipa (RTTI) .........352

Registracija tvornice ................................372

Refleksija: dinamička informacija o razredu............................376

Dinamički posrednici............................380

Objekti s neodređenim stanjem............................384

Sučelja i informacije o vrsti.............................390

Životopis................................394

Poglavlje 14

Jednostavna parametrizacija............................398

Parametrirana sučelja............................404

Parametrizirane metode...................407

Modeli kompleksa zgrada............................419

Ograničenja............................437

Metaznakovi................................440

Životopis................................452

Poglavlje 15. Nizovi................................454

Značajke niza................................454

Niz kao objekt............................456

Vraćanje niza................................458

Višedimenzionalni nizovi............................460

Nizovi i parametrizacija............................463

Stvaranje testnih podataka................................465

Stvaranje nizova pomoću generatora.....................470

Arrays Helper Toolkit............................474

Životopis................................482

Poglavlje 16 Java I/O sustav.................................483

Razred datoteke.................................484

Ulaz i izlaz.................................489

Dodavanje atributa i sučelja............................491

Razredi čitača i pisaca.....................................494

RandomAccessFile: sam po sebi.....................497

Tipična upotreba I/O tokova.................................498

Čitači i zapisivači datoteka.....................................505

Vjerojatno ne griješim ako pretpostavim da je većina učenika Jave počela to raditi uz pomoć poznate knjige Brucea Eckela: "Razmišljanje u Javi", u ruskom izdanju poznat kao "Filozofija Jave". Nažalost u u elektroničkom obliku(na ruskom) 2. izdanje ove knjige je najšire distribuirano, temeljeno na verziji Jave 1.1, koja je odavno izgubila svoju važnost. Inovacije koje su se pojavile u sljedećim verzijama Jave (a posebno u Javi SE5) bile su vrlo značajne, što je dovelo do ozbiljne revizije knjige u njezinom četvrtom izdanju (čiji je prijevod objavljen na ruskom). Međutim, u elektronskom formatu koji je jednostavan za čitanje (i što je najvažnije - za brzo pretraživanje), ruska verzija ove publikacije nije postojala. Stoga sam odlučio popuniti ovu prazninu i izraditi punu verziju ove popularne knjige u "wikibook" formatu. Vjerujem da će ove informacije biti zanimljive i korisne ne samo za učenike jezika, već i za sve koji rade na Javi zbog ogromnog broja odličnih primjera koji ilustriraju gotovo sve aspekte programiranja u ovom jeziku. Pogotovo kada su u pitanju Java značajke koje se rijetko koriste.

wikiknjiga "Filozofija Jave" objavljeno na:

"Proljeće na djelu"

Knjige iz serije ".....u akciji"(obično u PDF formatu i obično na engleskom) zasluženo su popularni u određenim krugovima :) Među njima ima i prostranih Talmuda, kao npr. "JSTL na djelu"(lako čitljiv i sa osrednjim znanjem engleskog, ali pogodan za ulogu dobrog referenta na temu), te skromniji zanati, npr. Opruge na djelu("Nije sve zlato..."). Knjiga "Proljeće na djelu" na ovom popisu je još uvijek iz kategorije "teškaša", i to u svakom smislu te riječi. Čitanje bez tečnog engleskog vjerojatno nije lako. I nije poanta u kompleksnosti prezentiranog materijala (nije kompliciran), već u činjenici da je ispao – pretjerano „englesko-umjetnički“, ili tako nešto... Pun lirskih digresija, doskočica, kalambura i ostalog bla bla bla, jezični autori, čitanje ovog vodiča (na izvornom jeziku) brzo pretvara u zamoran proces. Ali s druge strane, to vam omogućuje da znate da riječ "crtati"(obično - "crtati") može se koristiti u značenju "izvadak iz" (lit. - "povući, povući"). Kao rezultat (uzimajući u obzir opći stil prezentacije usvojen u knjizi) razumjeti točno značenje fraze poput: "...proljeće nacrtaj ove podatke ...", to se događa u isto vrijeme - i to nije lako, i to je iznimno potrebno. Stoga će čitatelji poglavlja koja nisam preveo morati sami odlučiti što su autori htjeli u takvim slučajevima: poetski se izraziti o nastanku (snimanju) datoteke ili šaljivo ispričati o čitanju.

Ovu sam knjigu pretvorio iz PDF-a u wikiknjigu kao izričitu referencu za svoju osobnu upotrebu. Dakle, prijevod nije totalan, već samo mjestimično – za što je bilo dovoljno entuzijazma. Ostala poglavlja su jednostavno dana u obliku pogodnom za brzo pretraživanje. Objavljeno je, SVE u obliku - "kako jest", i ne treba kriviti kvalitetu ruskog teksta ... Nisam profesionalni prevoditelj, a nisam imao književnog urednika. Možda ću nekoga razočarati činjenicom da neka mjesta i poglavlja knjige nisam preveo (a niti ne planiram prevoditi), ali je trebalo ostaviti rezervu za buduće generacije

wikiknjiga "Proljeće u akciji " objavljeno na:

UPOZNAVANJE S OBJEKTIMA

Pojavu računalne revolucije dugujemo stroju. Stoga naši programski jezici pokušavaju biti bliži ovom stroju.

Ali u isto vrijeme, računala nisu toliko mehanizmi koliko su sredstva za pojačavanje misli ("bicikli za um", kako je volio reći Steve Jobs), i još jedno sredstvo samoizražavanja. Kao rezultat toga, alati za programiranje manje se oslanjaju na strojeve, a više na naš um, kao i na druge oblike izražavanja ljudskih težnji, kao što su književnost, slikarstvo, kiparstvo, animacija i kinematografija. Objektno orijentirano programiranje (OOP) dio je pretvaranja računala u medij samoizražavanja.

Ovo poglavlje će vas upoznati s osnovama OOP-a, uključujući pogled na osnovne tehnike programiranja. Ona, i knjiga općenito, pretpostavljaju da imate iskustva u programiranju na proceduralnom jeziku, ne nužno C.

Ovo poglavlje sadrži pripremne i dodatni materijali. Mnogi čitatelji radije prvo zamišljaju širu sliku, a tek onda razumiju zamršenost OOP-a. Stoga mnoge ideje u ovom poglavlju služe da vam daju solidno razumijevanje OOP-a. Međutim, mnogi ljudi ne shvate opću ideju dok ne vide konkretno kako stvari funkcioniraju; takvi ljudi često zapnu u općim crtama, bez primjera pred sobom. Ako ste jedan od potonjih i nestrpljivi ste da počnete s osnovama jezika, možete prijeći na sljedeće poglavlje - preskakanje ovog neće biti prepreka pisanju programa ili učenju jezika. Međutim, kasnije biste se trebali vratiti na ovo poglavlje kako biste proširili svoje horizonte i razumjeli zašto su objekti toliko važni i gdje se uklapaju u dizajn programa.

Razvoj apstrakcije

Svi programski jezici izgrađeni su na apstrakciji. Možda težina zadataka koje treba riješiti izravno ovisi o vrsti i kvaliteti apstrakcije. Pod "vrstom" mislim: "Što točno apstrahiramo?" Asemblerski jezik je mala apstrakcija računala na kojem se izvodi. Mnogi takozvani "naredbeni" jezici stvoreni nakon njega (kao što je Fortran, BASIC i C) bile su apstrakcije sljedeće razine. Ti su jezici imali značajnu prednost u odnosu na asemblerski jezik, ali njihova osnovna apstrakcija i dalje vas tjera da razmišljate o strukturi računala, a ne o problemu koji se rješava. Programer mora uspostaviti odnos između modela stroja (u "prostoru rješenja", koji predstavlja mjesto gdje se rješenje implementira - npr. računalo) i modela problema koji treba riješiti (u "prostoru problema" , što je mjesto gdje postoji problem - na primjer, primijenjeno područje). Uspostavljanje veze zahtijeva napor odvojen od stvarnog programskog jezika; rezultat su programi koje je teško napisati i koje je teško održavati. I ne samo to, također je stvorio čitavu industriju "metodologija programiranja".

Alternativa modeliranju stroja je modeliranje problema koji se rješava. Rani jezici poput LISP i APL, odabrali su poseban pristup modeliranju svijeta oko sebe („Svi problemi se rješavaju popisima” ili „Algoritmi rješavaju sve”). PROLOG sve probleme tretira kao niz rješenja. Stvoreni su jezici za programiranje temeljeni na sustavu ograničenja i posebni jezici u kojima se programiranje provodilo manipuliranjem grafičkim strukturama (opseg potonjeg se pokazao preuskim). Svaki od ovih pristupa je dobar u određenom području problema koje treba riješiti, ali kada napustite ovo područje, postaje ih teško koristiti.

Objektni pristup ide korak dalje pružajući programeru sredstva za predstavljanje zadatka u njegovom prostoru. Ovaj pristup je prilično općenit i ne nameće ograničenja na vrstu problema koji se rješava. Elementi prostora problema i njihove reprezentacije u prostoru rješenja nazivaju se "objekti". (Vjerojatno ćete trebati druge objekte koji nemaju analogije u prostoru problema.) Ideja je da se program može prilagoditi specifičnostima problema stvaranjem novih tipova objekata tako da dok čitate kod koji rješava problem, vi istovremeno vidi riječi koje je opisuju. Ovo je fleksibilnija i moćnija apstrakcija, koja svojim mogućnostima nadilazi sve što je postojalo prije. Neki dizajneri jezika vjeruju da objektno orijentirano programiranje samo po sebi nije dovoljno za rješavanje svih programskih problema i zagovaraju kombinaciju različitih programskih paradigmi u jednom jeziku. Takvi se jezici nazivaju multi-paradigma(multiparadigme). Vidi knjigu Timothyja Budda Multiparadigm Programming in Leda (Addison-Wesley, 1995).. Dakle, OOP vam omogućuje da opišete zadatak u kontekstu samog zadatka, a ne u kontekstu računala na kojem će se rješenje izvršiti. Međutim, veza s računalom je i dalje očuvana. Svaki predmet je poput malog računala; ima stanje i operacije koje dopušta. Takva se analogija dobro uklapa s vanjskim svijetom, koji je "stvarnost koja nam je dana u objektima" koji imaju karakteristike i ponašanje.

Alan Kay sažeo je i izveo pet glavnih značajki jezika Čavrljanje- prvi uspješni objektno orijentirani jezik, jedan od prethodnika Java. Ove karakteristike predstavljaju "čisti", akademski pristup objektno orijentiranom programiranju:

• Sve je objekt. Zamislite objekt kao pročišćenu varijablu; pohranjuje podatke, ali možete "upitati" objekt, tražeći od njega da izvrši operacije na sebi. Teoretski, apsolutno bilo koja komponenta problema koji se rješava (pas, zgrada, usluga itd.) može se predstaviti kao objekt.

• Program je grupa objekata koji govore jedni drugima što da rade putem poruka. Da biste uputili zahtjev objektu, "pošaljite mu poruku". Vizualnije, poruka se može prikazati kao poziv metode koja pripada određenom objektu.

• Svaki objekt ima vlastitu "memoriju" koja se sastoji od drugih objekata. Drugim riječima, vi stvarate novi objekt ugradnjom postojećih objekata u njega. Stoga je moguće konstruirati proizvoljno složen program, skrivajući ukupnu složenost iza jednostavnosti pojedinačnih objekata.

• Svaki objekt ima tip. Drugim riječima, svaki objekt je instanca klase, gdje je "klasa" ekvivalent riječi "tip". Najvažnija razlika između klasa leži upravo u odgovoru na pitanje: “Koje se poruke mogu slati objektu?”

• Svi objekti određene vrste mogu primati iste poruke. Kako ćemo uskoro vidjeti, to je vrlo važna okolnost. Budući da je objekt tipa "krug" također objekt tipa "oblik", istina je da je "krug" sigurno sposoban primati poruke za "oblik". A to znači da možete napisati kod za oblike i biti sigurni da će raditi za sve što spada pod koncept oblika. Zamjenjivost je jedan od najmoćnijih koncepata u OOP-u.

Booch je ponudio još sažetiji opis objekta:

Objekt ima stanje, ponašanje i osobnost.

Suština je da objekt može imati interne podatke (što je stanje objekta), metode (koje definiraju ponašanje) i svaki se objekt može jedinstveno razlikovati od bilo kojeg drugog objekta - točnije, svaki objekt ima jedinstvenu adresu u um Ovo je istina uz neka ograničenja, budući da objekti mogu stvarno postojati na drugim strojevima iu različitim adresnim prostorima, a također mogu biti pohranjeni na disku. U tim slučajevima, identitet objekta mora biti određen nečim drugim osim memorijske adrese..

Objekt ima sučelje

Vjerojatno je Aristotel bio prvi koji je pažljivo proučavao pojam tipa; govorio je o "klasi riba i klasi ptica". Koncept da su svi objekti, iako jedinstveni, u isto vrijeme dio klase objekata sa sličnim karakteristikama i ponašanjima, korišten je u prvom objektno orijentiranom jeziku, Simula-67, s uvođenjem temeljne ključne riječi razreda , koji je u program uveo novu vrstu.

Jezik Simula, kao što mu ime govori, stvoren je za razvoj i simulaciju situacija sličnih klasičnom problemu "bankarskog blagajnika". Imate grupe blagajnika, kupaca, računa, plaćanja i valuta - mnogo "objekata". Objekti koji su identični u svim osim unutarnjeg stanja dok se program izvodi grupiraju se u "klase objekata". Odavde je došlo ključna riječ razreda . Stvaranje apstraktnih tipova podataka temeljni je koncept u cijelom objektno orijentiranom programiranju. Apstraktni tipovi podataka djeluju na isti način kao i ugrađeni tipovi: možete stvoriti varijable tipa (koje se nazivaju objekti ili instance u terminima OOP-a) i manipulirati njima (koje se naziva slanje poruka ili upit; vi postavite zahtjev, a objekt odlučuje što će učiniti s ono. ). Članovi (elementi) svake klase imaju sličnosti: svaki račun ima stanje, svaki blagajnik prima depozite itd. U isto vrijeme, svi se članovi razlikuju po svom unutarnjem stanju: svaki račun ima individualni saldo, svaki blagajnik ima ljudsko ime. Stoga, svi blagajnici, klijenti, računi, prijenosi itd. mogu biti predstavljeni jedinstvenim entitetima unutar kompjuterski program. To je bit objekta, a svaki objekt pripada određenoj klasi koja definira njegove karakteristike i ponašanje.

Dakle, iako stvaramo nove tipove podataka u objektnim jezicima, gotovo svi ti jezici koriste ključnu riječ "class". Kada vidite riječ "tip", pomislite na "klasu", i obrnuto Neki ljudi razlikuju to dvoje ističući da tip definira sučelje, dok je klasa konkretna implementacija sučelja..

Budući da klasa definira skup objekata s identičnim karakteristikama (članovi podataka) i ponašanjem (funkcionalnost), klasa je zapravo tip podataka, jer, na primjer, broj s pomičnim zarezom također ima niz karakteristika i ponašanja. Razlika je u tome što programer definira klasu koja predstavlja neki aspekt zadatka, umjesto da koristi već postojeći tip koji predstavlja jedinicu pohrane podataka u stroju. Programski jezik proširujete dodavanjem novih tipova podataka koji odgovaraju vašim potrebama. Sustav programiranja daje prednost novim klasama i posvećuje im istu pozornost kao i ugrađenim tipovima.

Objektno orijentirani pristup nije ograničen na izgradnju modela. Bilo da se slažete ili ne da je bilo koji program model sustava koji razvijate, korištenje OOP tehnologije lako smanjuje veliki skup problema na jednostavno rješenje.

Nakon što je definirana nova klasa, možete kreirati bilo koji broj objekata te klase i zatim njima manipulirati kao da su dio problema koji je pri ruci. Zapravo, jedna od glavnih poteškoća u OOP-u je uspostavljanje korespondencije jedan-na-jedan između objekata u prostoru problema i objekata u prostoru rješenja.

Ali kako natjerati objekt da radi ono što vi želite? Mora postojati mehanizam za slanje zahtjeva objektu da izvrši neku radnju - dovršetak transakcije, crtanje na ekranu itd. Svaki objekt može izvršiti samo određeni raspon zahtjeva. Upiti koje možete poslati objektu određeni su njegovim sučeljem, a sučelje objekta određeno je njegovim tipom. Najjednostavniji primjer bi bila električna žarulja:

Svjetlo lt = novo Svjetlo() ;
lt.on();

Sučelje definira koje zahtjeve možete uputiti određenom objektu. Međutim, kôd koji izvršava upite također mora postojati negdje. Ovaj kod, zajedno sa skrivenim podacima, čini implementaciju. Sa stajališta proceduralnog programiranja, ono što se događa nije tako teško. Tip sadrži metodu za svaki mogući zahtjev, a kada se primi određeni zahtjev, poziva se odgovarajuća metoda. Proces se obično kombinira u jedan: "slanje poruke" (prijenos zahtjeva) objektu i obrada od strane objekta (izvršavanje koda).

U ovom primjeru postoji tip (klasa) imenovan svjetlo (svjetiljka), betonski objekt vrste svjetlo Sa imenom To , a klasa podržava razne objektne upite svjetlo : Isključite žarulju, uključite je, pojačajte ili prigušite. Vi stvarate objekt svjetlo , definirajući "referencu" na njega ( To ) i pozivanje operatera novi za stvaranje nove instance tog tipa. Da biste poslali poruku objektu, morate navesti naziv objekta i točkom ga povezati sa željenim zahtjevom. Sa stajališta korisnika unaprijed definirane klase, to je sasvim dovoljno za rad na njezinim objektima.

Gore prikazani grafikon slijedi format UML (Unified Modeling Language). Svaka klasa je predstavljena pravokutnikom, sva podatkovna polja koja su opisana nalaze se u njegovom središnjem dijelu, a metode (funkcije objekta kojem šaljete poruke) su navedene na dnu pravokutnika.

Često na top listama UML prikazano je samo ime klase i javne metode, a srednji dio nedostaje. Ako vas zanima samo naziv klase, možete preskočiti i donji dio.

Objekt pruža usluge

Kada pokušavate dizajnirati ili razumjeti strukturu programa, često je korisno zamisliti objekte kao "davatelje usluga". Vaš program pruža usluge korisniku, a to čini putem usluga koje pružaju drugi objekti. Vaš cilj je proizvesti (ili još bolje pronaći u bibliotekama klasa) skup objekata koji će biti optimalan za rješavanje vašeg problema.

Za početak, zapitajte se: "Kad bih mogao magijom ukloniti predmete iz šešira, koji bi od njih sada mogli riješiti moj problem?" Pretpostavimo da razvijate računovodstveni program. Može se zamisliti skup objekata koji pružaju standardne prozore za unos računovodstvenih informacija, drugi skup objekata koji izvode računovodstvene kalkulacije, objekt koji ispisuje čekove i fakture na raznim pisačima. Možda neki od tih objekata već postoje, a za druge objekte vrijedi otkriti kako bi mogli izgledati. Koje usluge bi ti objekti mogli pružiti i koji bi im objekti bili potrebni za obavljanje posla? Nastavite li ovako, prije ili kasnije ćete reći: "Ovaj objekt je dovoljno jednostavan da možemo sjesti i zapisati ga", ili "Takav objekt sigurno već postoji." Ovo je razuman način da se rješenje problema rasporedi na zasebne objekte.

Predstavljanje objekta kao pružatelj usluga ima dodatna korist: pomaže poboljšati povezanost ( kohezivnost) objekt. Dobra povezanost - bitna kvaliteta softverski proizvod: znači da se različiti aspekti softverske komponente (kao što je objekt, iako se također može odnositi na metodu ili biblioteku objekata) dobro uklapaju. Jedan od uobičajene pogreške dopušteno pri projektiranju objekta je prezasićenje velikim brojem svojstava i mogućnosti. Na primjer, kada razvijate modul koji ispisuje čekove, možda biste željeli da "zna" sve o formatiranju i ispisu.

Ako bolje razmislite, najvjerojatnije ćete doći do zaključka da je to previše za jedan objekt, a otići ćete na tri ili više objekata. Jedan objekt će biti katalog svih mogućih oblika čekova i moći će se upitati kako treba ispisati ček. Drugi objekt ili skup objekata bit će odgovoran za generalizirano sučelje za ispis koje "zna" sve o različitim vrstama pisača (ali ne "razumi" ništa u računovodstvu - bolje je kupiti takav objekt nego ga sami razvijati). Konačno, treći objekt će jednostavno koristiti usluge opisanih objekata kako bi izvršio zadatak. Dakle, svaki objekt je povezan skup usluga koje nudi. U dobro isplaniranom objektno orijentiranom projektu, svaki objekt dobro radi jedan određeni zadatak bez pokušaja da učini više nego što treba. Kao što je prikazano, ovo ne samo da vam omogućuje da odredite koje objekte vrijedi kupiti (objekt sa sučeljem za ispis), već vam također omogućuje da završite s objektom koji se zatim može koristiti negdje drugdje (katalog računa).

Predstavljanje objekata kao pružatelja usluga uvelike pojednostavljuje zadatak. Korisno je ne samo tijekom razvoja, već i kada netko pokuša razumjeti vaš kod ili ponovno upotrijebiti objekt - tada može adekvatno procijeniti objekt za razinu pružene usluge, a to će uvelike pojednostaviti integraciju potonjeg u drugi projekt.

Skrivena implementacija

Korisno je programere podijeliti na kreatori razreda(oni koji stvaraju nove tipove podataka) i klijentski programeriZahvalan sam na ovom mandatu svom prijatelju Scottu Meyersu.(potrošači klasa koje koriste tipove podataka u svojim aplikacijama). Cilj drugog je prikupiti što više razreda kako bi se krenulo u brzi razvoj programa. Cilj kreatora klase je izgraditi klasu koja izlaže samo ono što klijent programer treba i skriva sve ostalo. Zašto? Klijent programer neće moći pristupiti skrivenim dijelovima, što znači da kreator klasa zadržava mogućnost da ih proizvoljno mijenja bez straha da će nekoga povrijediti. "Skriveni" dio je obično "najkrhkiji" dio objekta, koji lako može oštetiti neoprezni ili neupućeni programer klijenta, tako da skrivanje implementacije smanjuje broj grešaka u programima.

U svakoj vezi važno je imati neke granice koje nitko od sudionika ne prelazi. Stvaranjem knjižnice uspostavljate odnos s klijentskim programerom. On je programer baš kao i vi, ali će koristiti vašu biblioteku za izradu aplikacije (i možda biblioteke više razine). Ako svakome date pristup svim članovima klase, programer klijent može s klasom raditi što god želi i ne postoji način na koji ga možete natjerati da "igra po pravilima". Čak i ako kasnije trebate ograničiti pristup određenim članovima vašeg razreda, to se ne može učiniti bez mehanizma kontrole pristupa. Cjelokupna struktura nastave otvorena je za sve zainteresirane.

Dakle, prvi razlog za ograničavanje pristupa je potreba zaštite "krhkih" detalja od klijentskog programera - dijelova interne "kuhinje" koji nisu sastavni dijelovi sučelja s kojim korisnici rješavaju svoje probleme. Zapravo, ovo je korisno i za korisnike - odmah će vidjeti što im je važno, a što mogu zanemariti.

Drugi razlog za pojavu ograničenja pristupa je želja da se programeru knjižnice omogući promjena internih mehanizama klase bez brige o tome kako će to utjecati na programera klijenta. Na primjer, možete implementirati određenu klasu u žurbi kako biste ubrzali razvoj programa, a zatim je prepisati kako biste poboljšali brzinu. Ako ste pravilno razdvojili i zaštitili sučelje i implementaciju, ovo uopće ne bi trebalo biti teško.

Java koristi tri eksplicitne ključne riječi koje karakteriziraju razinu pristupa: javno, privatno i zaštićen . Njihova namjena i uporaba je vrlo jednostavna. Ovi specifikatori pristupa određuju tko ima pravo koristiti definicije koje ih prate. Riječ javnost znači da su sljedeće definicije dostupne svima. Naprotiv, riječ privatni znači da su klauzule koje slijede dostupne samo kreatoru tipa, unutar njegovih metoda. Termin privatni - "zid tvrđave" između vas i programera-klijenta. Ako netko pokuša koristiti privatni -članovi, zaustavit će ga greška kompilacije. specifikator zaštićen djeluje slično privatni , uz jednu iznimku - izvedene klase imaju pristup označenim članovima zaštićen ali nemaju pristup privatni -članovi (uskoro ćemo obraditi nasljeđe).

NA Java postoji i "zadani" pristup koji se koristi u odsutnosti bilo kojeg od navedenih specifičara. Ponekad se naziva i pristup unutar paketa ( pristup paketu) jer klase mogu koristiti članove prijatelja drugih klasa u svom paketu, ali izvan paketa, isti članovi prijatelja stječu status privatni .

Ponovno korištenje implementacije

Generirana i testirana klasa trebala bi (idealno) biti koristan blok koda. Međutim, pokazalo se da je postizanje tog cilja mnogo teže nego što mnogi misle; razvoj višekratnih predmeta zahtijeva iskustvo i razumijevanje suštine stvari. Ali jednom kad to dobro shvatiš dobra gradnja, jednostavno će tražiti implementaciju u drugim programima. Ponovno korištenje koda jedna je od najimpresivnijih prednosti objektno orijentiranih jezika.

Najlakši način za ponovnu upotrebu klase je izravnim stvaranjem njenog objekta, ali također možete smjestiti objekt te klase unutar nove klase. To zovemo ubacivanje objekta (stvaranje objekta člana). Nova klasa može sadržavati bilo koji broj objekata drugih tipova, u bilo kojoj kombinaciji koja je potrebna za postizanje tražene funkcionalnosti. Budući da sastavljamo nova klasa iz već postojećih klasa, poziva se ova metoda sastav(kada se skladba izvodi dinamički, obično se imenuje agregacija). Sastav se često naziva odnosom "ima" ( ima), kao, na primjer, u rečenici "Automobil ima motor."

(U UML dijagramima kompozicija je označena ispunjenim dijamantom, pokazujući, na primjer, da postoji samo jedan automobil. Obično koristim općenitiji oblik odnosa: samo linije, bez dijamanta, što znači asocijacija (veza). To je obično dovoljno za većinu grafikona gdje vam razlika između sastava i agregacije nije značajna.)

Sastav je vrlo fleksibilan alat. Objekti članovi vaše nove klase obično se proglašavaju privatnima ( privatni ), što ih čini nedostupnima klijentskim programerima koji koriste klasu. Ovo dopušta izmjene ovih objekata članova bez modificiranja postojećeg koda klijenta. Također možete promijeniti te članove tijekom izvođenja kako biste dinamički kontrolirali ponašanje svog programa. Nasljeđivanje opisano u nastavku nema ovu fleksibilnost jer prevodilac nameće određena ograničenja na klase stvorene korištenjem nasljeđivanja.

Nasljeđivanje igra važnu ulogu u objektno orijentiranom programiranju, pa mu se često pridaje puno pozornosti, a početnik bi mogao pomisliti da bi nasljeđivanje trebalo primijeniti posvuda. A to je prepuno stvaranja nespretnih i nepotrebno složenih rješenja. Umjesto toga, kada stvarate nove klase, prvo biste trebali procijeniti mogućnost kompozicije jer je jednostavnija i fleksibilnija. Ako usvojite preporučeni pristup, vaše će programske konstrukcije postati mnogo jasnije. A kako budete stjecali praktično iskustvo, neće vam biti teško razumjeti gdje se treba koristiti nasljeđivanje.

Nasljedstvo

Sama po sebi, ideja objekta je izuzetno zgodna. Objekt vam omogućuje kombiniranje podataka i funkcionalnosti na konceptualnoj razini, odnosno možete prikazati željeni koncept iz prostora zadatka umjesto da ga konkretizirate pomoću dijalekta stroja. Ovi koncepti čine temeljne jedinice programskog jezika, opisane ključnom riječi class.

Ali, priznajte, bila bi šteta napraviti nekakvu klasu, a onda opet raditi sav posao za sličnu klasu. Mnogo je racionalnije uzeti gotovu klasu, "klonirati" je, a zatim dodati i ažurirati rezultirajući klon. To je upravo ono što dobivate kao rezultat nasljeđivanja, s jednom iznimkom - ako se izvorna klasa (koja se također naziva bazna * klasa, superklasa ili roditeljska klasa) promijeni, tada se sve promjene odražavaju na njezin "klon" (koji se naziva izvedena klasa , naslijeđena klasa, podklasa ili podklasa).

(Strelica (prazan trokut) u UML dijagramu pokazuje od izvedene klase do osnovne klase. Kao što ćete uskoro vidjeti, može postojati više od jedne izvedene klase.)

Tip definira više od samo svojstava grupe objekata; povezuje se i s drugim vrstama. Dvije vrste mogu dijeliti sličnosti i ponašanja, ali se razlikuju u broju karakteristika, kao i sposobnosti da obrade više poruka (ili da ih obrade drugačije). Da bi se izrazila ova zajednička pripadnost tipova, nasljeđivanje koristi koncept osnovnih i izvedenih tipova. Osnovni tip sadrži sve karakteristike i radnje zajedničke za sve tipove izvedene iz njega. Kreirate osnovni tip koji predstavlja osnovu vašeg razumijevanja nekih objekata u vašem sustavu. Ostali tipovi su izvedeni iz osnovnog tipa, izražavajući druge implementacije ovog entiteta.

Na primjer, stroj za recikliranje razvrstava otpad. Osnovna vrsta bit će "smeće", a svaki komad smeća ima težinu, cijenu itd. i može se zdrobiti, otopiti ili razgraditi. Na temelju toga se nasljeđuju specifičnije vrste smeća koje imaju dodatne karakteristike (boca ima boju) ili osobine ponašanja ( aluminijska limenka može se zdrobiti, čeličnu limenku privlači magnet). Osim toga, neka ponašanja mogu varirati (cijena papira ovisi o njegovoj vrsti i stanju). Nasljeđivanje vam omogućuje stvaranje hijerarhije tipova koja opisuje problem koji se rješava u kontekstu njegovih tipova.

Drugi primjer je klasičan primjer sa geometrijski oblici. Osnovni tip ovdje je "oblik", a svaki oblik ima veličinu, boju, mjesto itd. Svaki oblik se može crtati, brisati, pomicati, bojati itd. Zatim se proizvode (nasljeđuju) određene vrste oblika: krug, kvadrat, trokut itd., od kojih svaki ima svoje dodatne karakteristike i ponašanja. Na primjer, neki oblici podržavaju operaciju zrcaljenja. Pojedinačne značajke ponašanja mogu se razlikovati, kao u slučaju izračunavanja površine figure. Hijerarhija tipova utjelovljuje i slična i različita svojstva oblika.

Svođenje rješenja na koncepte korištene u primjeru je izuzetno zgodno, jer vam nisu potrebni mnogi međumodeli koji povezuju opis rješenja s opisom problema. Kada radite s objektima, hijerarhija tipova postaje primarni model, tako da prelazite s opisivanja sustava u stvarnom svijetu izravno na opisivanje sustava u kodu. Zapravo, jedna od poteškoća u objektno orijentiranom planiranju je to što vam je vrlo lako ići od početka problema do kraja rješenja. Um uvježban za složena rješenja često zapne pri korištenju jednostavnih pristupa.

Nasljeđivanjem postojećeg tipa stvarate novi tip. Ovaj novi tip ne samo da sadrži sve članove postojećeg tipa (iako su članovi označeni kao privatni , skriven i nedostupan), ali, što je još važnije, ponavlja sučelje osnovne klase. To znači da sve poruke koje možete poslati osnovnoj klasi, možete poslati i izvedenoj klasi. A budući da tipove klasa razlikujemo prema skupu poruka koje im možemo poslati, to znači da izvedena klasa je poseban slučaj osnovne klase. U prethodnom primjeru, "krug je figura." Ekvivalencija tipova postignuta nasljeđivanjem jedan je od temeljnih uvjeta za razumijevanje značenja objektno orijentiranog programiranja.

Budući da i osnovna i izvedena klasa imaju isto glavno sučelje, mora postojati implementacija za to sučelje. Drugim riječima, negdje mora postojati kod koji se izvršava kada objekt primi određenu poruku. Ako ste jednostavno naslijedili klasu i niste učinili ništa drugo, metode iz sučelja osnovne klase preći će u izvedenu klasu nepromijenjene. To znači da su objekti izvedene klase ne samo istog tipa, već imaju i isto ponašanje, a pritom samo nasljeđivanje gubi smisao.

Postoje dva načina za promjenu nove klase iz osnovne klase. Prvi je prilično očit: potpuno nove metode dodaju se izvedenoj klasi. Oni više nisu dio sučelja osnovne klase. Očigledno osnovna klasa nije učinila sve što je zadatak zahtijevao, pa ste dodali nekoliko metoda. Međutim, takav jednostavan i primitivan pristup nasljeđivanju ponekad se pokaže idealnim rješenjem problema. Međutim, jedna stvar koju treba pažljivo razmotriti je da osnovna klasa također može trebati ove dodane metode. Proces identificiranja obrazaca i revizije arhitekture je svakodnevna rutina u objektno orijentiranom programiranju.

Dok nasljeđivanje ponekad sugerira da će sučelje biti prošireno novim metodama (osobito u Java, gdje je nasljeđivanje označeno ključnom riječi proteže se , odnosno "proširiti"), to uopće nije potrebno. Drugi, važniji način modificiranja klase je promijeniti ponašanje već postojeće metode osnovna klasa. To se zove nadjačavanje (ili nadjačavanje) metode.

Da biste nadjačali metodu, jednostavno kreirate novu definiciju te metode u izvedenoj klasi. Vi na neki način kažete "Koristim istu metodu sučelja, ali želim da radi različite stvari za moj novi tip."

Kada se koristi nasljeđivanje, postavlja se očito pitanje: treba li nasljeđivanje nadjačati metode samo osnovna klasa (a ne dodavati nove metode koje ne postoje u osnovnoj klasi)? To bi značilo da bi izvedena klasa bila točno istog tipa kao osnovna klasa, budući da imaju isto sučelje. Kao rezultat toga, objekte osnovne klase možete slobodno zamijeniti objektima izvedenih klasa. Možete govoriti o potpunoj zamjeni, a to se često naziva princip supstitucije. U određenom smislu, ovaj način nasljeđivanja je idealan. Ova vrsta odnosa između osnovne klase i izvedene klase često se naziva odnos. "je nesto", jer se može reći "krug je figura". Da bi se utvrdilo koliko će nasljeđivanje biti prikladno, dovoljno je provjeriti postoji li odnos "jest" među klasama i koliko je on opravdan.

U drugim slučajevima, sučelje izvedene klase se nadopunjuje novim elementima, što dovodi do njegovog proširenja. Novi tip se i dalje može koristiti umjesto osnovnog tipa, ali sada ova zamjena nije idealna jer nove metode nisu dostupne iz osnovnog tipa. Takva se veza opisuje izrazom "slično" (ovo je moj izraz); novi tip sadrži sučelje starog tipa, ali uključuje i nove metode, a za te se tipove ne može reći da su potpuno isti. Uzmimo za primjer klima uređaj.

Pretpostavimo da je vaša kuća opremljena svime potrebna oprema za kontrolu procesa hlađenja. Zamislite sada da se klima uređaj pokvario i da ste ga zamijenili grijačem koji može grijati i hladiti. Grijalica je "kao" klima uređaj, ali može više. Budući da kontrolni sustav vašeg doma može kontrolirati samo hlađenje, ograničen je u komunikaciji s rashladnim dijelom novog objekta. Sučelje novog objekta je prošireno, a postojeći sustav ne prepoznaje ništa osim originalnog sučelja.

Naravno, gledajući ovu hijerarhiju, postaje jasno da osnovna klasa "sustava hlađenja" nije dovoljno fleksibilna; treba ga preimenovati u "sustav kontrole temperature" tako da uključuje i grijanje - a nakon toga će funkcionirati princip supstitucije. Međutim, ovaj dijagram daje primjer onoga što se može dogoditi u stvarnosti.

Nakon upoznavanja s principom supstitucije, mogao bi se steći dojam da je ovakav pristup (puna zamjena) jedini put razvoja. Općenito govoreći, ako vaše hijerarhije tipova funkcioniraju na ovaj način, to je stvarno dobro. Ali u nekim je situacijama apsolutno neophodno dodati nove metode sučelju izvedene klase. Kad se pomnije ispita, oba slučaja čine se prilično očitima.

Zamjenjivi objekti i polimorfizam

Kada se koriste hijerarhije tipova, često je potrebno tretirati objekt određenog tipa kao osnovni tip. To vam omogućuje pisanje koda koji ne ovisi o konkretnim tipovima. Dakle, u primjeru oblika, metode jednostavno manipuliraju oblicima, bez obzira jesu li krugovi, pravokutnici, trokuti ili neki još nedefinirani oblici. Svi se oblici mogu crtati, brisati i pomicati, a metode jednostavno šalju poruke objektu oblika; nije ih briga kako objekt obrađuje poruku.

Takav kod ne ovisi o dodavanju novih tipova, a dodavanje novih tipova je najčešći način proširenja objektno orijentiranih programa za rukovanje novim situacijama. Na primjer, možete stvoriti novu podklasu oblika (peterokut) bez mijenjanja metoda koje rade samo s generičkim oblicima. Sposobnost jednostavnog proširenja programa uvođenjem novih izvedenih tipova vrlo je važna jer uvelike poboljšava arhitekturu programa, dok u isto vrijeme smanjuje troškove održavanja softvera.

Međutim, kada se objekti izvedenih tipova pokušavaju označiti kao osnovni tipovi (krugovi kao figura, bicikl kao vozilo, kormoran kao ptica itd.), javlja se jedan problem. Ako će metoda reći generičkoj figuri da sama sebe nacrta, ili vozilu da slijedi određeni kurs, ili ptici da leti, prevodilac ne može točno znati koji će dio koda biti izvršen. To je cijela poanta - kada se poruka pošalje, programer ne želi znati koji se kod izvršava; metoda crtanja može se s jednakim uspjehom primijeniti na krug, pravokutnik i trokut, a objekt će izvršiti točan kod, ovisno o svojoj karakterističnoj vrsti.

Ako ne trebate znati koji se dio koda izvodi, tada kada dodate novi podtip, njegov implementacijski kod može biti drugačiji bez potrebe za promjenama metode iz koje je pozvan. Ako kompajler ne zna točno koji kod treba izvršiti, što radi?

NA sljedeći primjer objekt BirdController (kontrola ptica) može raditi samo s generičkim objektima ptica (ptica), ne znajući njihovu točnu vrstu. S gledišta BirdController ovo je zgodno jer ne morate pisati poseban kod za provjeru tipa objekta koji se za to koristi ptica , za rješavanje nekog posebnog ponašanja. Kako se događa da kada pozovete metodu move (), bez navođenja točne vrste ptica , vrši se ispravna radnja - objekt guska (guska) trči, leti ili pliva, a predmet Pingvin (pingvin) trčanje ili plivanje?

Odgovor je objašnjen glavna značajka objektno orijentirano programiranje: prevoditelj ne može pozivati ​​takve funkcije na tradicionalan način. Kada pozivate funkcije stvorene ne-OOP kompajlerom, koristite rano uvezivanje- mnogi ne znaju ovaj pojam jednostavno zato što ne zamišljaju drugu opciju. S ranim vezanjem, prevodilac generira poziv funkcije s dati ime, a povezivač povezuje ovaj poziv s apsolutnom adresom koda koji se treba izvršiti. U OOP-u, program ne može odrediti adresu koda do vremena izvođenja, tako da prilikom slanja poruke objektu mora raditi drugačiji mehanizam.

Da bi riješili ovaj problem, objektno orijentirani programski jezici koriste koncept kasni uvez. Kada pošaljete poruku objektu, kod koji se poziva nije poznat do vremena izvođenja. Prevodilac samo osigurava da metoda postoji, provjerava tipove za njene parametre i povratnu vrijednost, ali nema pojma kakav će se kod izvesti.

Za implementaciju kasnog povezivanja, Java koristi posebne isječke koda umjesto apsolutnog poziva. Ovaj kod izračunava adresu tijela metode na temelju informacija pohranjenih u objektu (proces je detaljno objašnjen u Poglavlju 7 o polimorfizmu). Stoga se svaki objekt može ponašati drugačije, ovisno o sadržaju ovog posebnog dijela koda. Kada pošaljete poruku, objekt zapravo odlučuje što će učiniti s njom.

Neki jezici zahtijevaju da izričito odredite da metoda treba koristiti fleksibilni mehanizam kasnog vezivanja (u C++ postoji ključna riječ za ovo virtualan). U ovim jezicima metode nisu dinamički povezane prema zadanim postavkama. NA Java kasno vezanje se izvodi prema zadanim postavkama i ne morate se sjetiti dodavanja ključnih riječi da biste osigurali polimorfizam.

Prisjetite se primjera s oblicima. Obitelj klasa (temeljenih na istom sučelju) prikazana je u dijagramu ranije u ovom poglavlju. Kako bismo demonstrirali polimorfizam, napisat ćemo isječak koda koji zanemaruje specifičnosti tipa i radi samo na osnovnoj klasi. Ovaj kod je odvojen od specifičnosti tipa, tako da ga je lakše napisati i razumjeti. A ako se novi tip (na primjer, šesterokut) doda putem nasljeđivanja, tada će kôd koji napišete za novi tip oblika raditi jednako dobro kao i kod za postojeće tipove. Time program postaje proširiv.

Recimo da ste napisali Java sljedeću metodu (uskoro ćete naučiti kako to učiniti):

void doSomething(oblik oblika) (
oblik.brisanje(); // izbrisati
//...
shape.draw(); // crtati
}

Metoda radi s generaliziranom figurom ( oblik ), odnosno ne ovisi o određenoj vrsti predmeta koji se crta ili briše. Sada koristimo poziv metode učini nešto() u drugom dijelu programa:

Krug krug = novi Krug() ; // krug
Trokut trokut = novi Trokut() ; // trokut
Linija linija = nova linija(); // crta
učini Nešto(zaokruži) ;
učiniti nešto(trokut) ;
učiniti nešto (linija);

Pozivi metoda učini nešto() automatski rade ispravno, bez obzira na stvarnu vrstu objekta.

Ovo je zapravo vrlo važna činjenica. Razmotrimo liniju:

učini Nešto(zaokruži) ;

Ovdje se događa sljedeće: metodi koja očekuje objekt oblik , prosljeđuje se objekt “krug” ( Krug ). Budući da je krug ( Krug ) je istovremeno figura ( oblik ), zatim metoda učini nešto() i tretira je kao lik. Drugim riječima, svaka poruka koju metoda može poslati oblik , također se prihvaća Krug . Ova radnja je potpuno sigurna i jednako logična.

Ovaj proces postupanja s izvedenim tipom nazivamo kao da je osnovni tip. upcasting. Riječ transformacija znači da se objekt tretira kao da pripada drugom tipu, i uzlazni to je zato što su u dijagramima nasljeđivanja osnovne klase obično na vrhu, a izvedene klase lepezasto su raspoređene na dnu. To znači da je pretvorba u osnovni tip kretanje prema gore duž dijagrama, pa je stoga "prema gore".

Objektno orijentirani program gotovo uvijek sadrži upcast, jer se tako oslobađate potrebe da znate točan tip objekta s kojim radite. Pogledajte tijelo metode učini nešto() :

oblik.brisanje();
// ...
shape.draw();

Imajte na umu da ne kaže "ako ste objekt Krug , učinite to, a ako ste objekt Kvadrat učini to i to." Takav kod s zasebnim akcijama za svaku moguću vrstu oblik bit će zbunjujuće i morat će se mijenjati svaki put kada se doda nova podvrsta oblik . I tako, samo kažeš: “Ti si figura, a ja znam da možeš sam sebe crtati i brisati, dobro, učini to, a za detalje se pobrini sam.”

U kodu metode učini nešto() Ono što je zanimljivo je da sve funkcionira kako treba. Na poziv crtati() za objekt Krug izvršava se drugi kod, a ne onaj koji radi kada se pozove crtati() za objekte Kvadrat ili crta , i kada crtati() primijenjen na nepoznatu figuru oblik , ispravno ponašanje osigurano je korištenjem stvarnog tipa oblik . Unutra je najviši stupanj zanimljivo, jer, kao što je navedeno malo ranije, kada prevodilac generira kod učini nešto() , ne zna točno s kojim vrstama radi. Sukladno tome, moglo bi se očekivati ​​da se pozivaju verzije metode crtati() i obrisati() iz osnovne klase oblik , a ne njihove varijante iz konkretnih razreda Krug , Kvadrat ili crta . Pa ipak sve radi ispravno zahvaljujući polimorfizmu. Kompajler i runtime sustav vode računa o svim detaljima; sve što trebate znati je da će se to dogoditi... i još važnije, kako izgraditi programe pomoću ovog pristupa. Kada pošaljete poruku objektu, objekt će odabrati ispravno ponašanje koristeći upcast.

Hijerarhija s jednim korijenom

Ubrzo nakon pojave C++ počelo se aktivno raspravljati o pitanju iz OOP-a - trebaju li sve klase nužno biti naslijeđene od jedne osnovne klase? NA Java(kao u gotovo svim drugim OOP jezicima osim C++) Na ovo pitanje je odgovoreno potvrdno. Cijela hijerarhija tipova temelji se na jednoj osnovnoj klasi Objekt . Pokazalo se da jednokorijenska hijerarhija ima mnogo prednosti.

Svi objekti u hijerarhiji s jednim korijenom dijele neko zajedničko sučelje, tako da se uglavnom svi mogu smatrati jednim temeljnim tipom. NA C++ odabrana je druga opcija - zajednički predak ne postoji u ovom jeziku. Što se tiče kompatibilnosti sa starim kodom, ovaj model je više u skladu s tradicijom. C, a možda mislite da je manje ograničen. Ali čim se pojavi potreba za potpunim objektno orijentiranim programiranjem, morat ćete stvoriti vlastitu hijerarhiju klasa kako biste dobili iste prednosti koje su ugrađene u druge OOP jezike. A u bilo kojoj novoj biblioteci klasa možete naići na neko nekompatibilno sučelje. Uključivanje ovih novih sučelja u arhitekturu vašeg programa zahtijevat će dodatni napor (i moguće višestruko nasljeđivanje). Isplati li se dodatna "fleksibilnost"? C++ slični troškovi? Ako vam treba (npr. velike investicije za razvoj koda C), onda nećeš biti gubitnik. Ako razvoj krene od nule, pristup Java izgleda produktivnije.

Zajamčeno je da svi objekti u jednoj korijenskoj hijerarhiji dijele neke zajedničke funkcije. Znate da se određene osnovne operacije mogu izvesti na bilo kojem objektu u sustavu. Svi se objekti lako kreiraju na dinamičkoj gomili, a prosljeđivanje argumenata je uvelike pojednostavljeno.

Jednokorijenska hijerarhija znatno olakšava implementaciju skupljanja smeća - jedno od najvažnijih poboljšanja Java u usporedbi sa C++. Budući da je zajamčeno da će informacija o tipu biti prisutna u bilo kojem objektu u vrijeme izvođenja, nikada neće postojati objekt u sustavu čiji se tip ne može odrediti. Ovo je posebno važno pri izvođenju sistemskih operacija kao što je rukovanje iznimkama i za veću fleksibilnost programiranja.

Kontejneri

Često se unaprijed ne zna koliko će objekata biti potrebno za rješavanje određenog problema i koliko dugo će postojati. Također je nejasno kako pohraniti takve predmete. Koliko memorije treba dodijeliti za pohranjivanje ovih objekata? Nije poznato jer će ove informacije biti dostupne samo dok je program pokrenut.

Mnogi problemi u objektno orijentiranom programiranju su riješeni jednostavna radnja: Stvarate drugu vrstu objekta. Novi tip objekta koji rješava ovaj određeni problem sadrži reference na druge objekte. Naravno, nizovi, koji su podržani u većini jezika, također mogu igrati tu ulogu. Međutim, novi objekt, obično tzv spremnik(ili zbirka, ali u Java pojam se koristi u drugačijem smislu) nužno će se proširiti kako bi primio sve što u njega stavite. Stoga nećete morati unaprijed znati za koliko je objekata predviđen kapacitet spremnika. Samo stvorite spremnik i on će se pobrinuti za detalje.

Srećom, dobar OOP jezik dolazi sa skupom gotovih spremnika. NA C++ to je dio standardne knjižnice C++, koja se ponekad naziva knjižnicom standardni predlošci (Standardna biblioteka predložaka, STL). Čavrljanje dolazi s vrlo širokim rasponom spremnika. Java također sadrži spremnike u svojoj standardnoj biblioteci. Za neke se knjižnice smatra dovoljnim imati jedan spremnik za sve potrebe, no u drugima (npr. Java) postoje razni spremnici za sve prilike: nekoliko različitih vrsta lista Popis (za pohranjivanje nizova elemenata), karte Karta (također poznati kao asocijativni nizovi, omogućuju vam pridruživanje objekata drugim objektima), kao i skupove postaviti (pružanje jedinstvenih vrijednosti za svaku vrstu). Knjižnice spremnika također mogu sadržavati redove, stabla, hrpe i tako dalje.

Sa stajališta dizajna, sve što stvarno trebate je spremnik koji može riješiti vaš problem. Ako jedna vrsta spremnika zadovoljava sve potrebe, nema razloga za korištenje drugih vrsta. Postoje dva razloga zašto morate birati između dostupnih spremnika. Prvo, spremnici pružaju različita sučelja i interakcije. Ponašanje i sučelje hrpa razlikuje se od ponašanja reda čekanja, koji se ponaša drugačije od skupa ili popisa. Jedan od ovih spremnika može pružiti više od učinkovito rješenje vaš zadatak u usporedbi s ostalima. Drugo, različiti spremnici izvode iste operacije na različite načine. najbolji primjer- ovo je ArrayList i LinkedList . Obje su jednostavne sekvence koje mogu imati identična sučelja i ponašanja. Ali neke se operacije značajno razlikuju u vremenu izvršenja. Recimo vrijeme uzorkovanja proizvoljnog elementa u ArrayList uvijek ostaje isti bez obzira koji je element odabran. Međutim, u LinkedList nepovoljno je raditi s nasumičnim pristupom - što je element niže na popisu, to veće kašnjenje uzrokuje njegovo pretraživanje. S druge strane, ako trebate umetnuti element u sredinu popisa, LinkedList učini to brže od ArrayList . Ove i druge operacije su različita učinkovitost ovisno o unutarnja struktura spremnik. U fazi planiranja programa možete odabrati popis LinkedList , a zatim tijekom procesa optimizacije prijeđite na ArrayList . Zbog apstraktne prirode sučelja Popis takav će prijelaz zahtijevati minimalne promjene u kodu.

Parametrizirani tipovi (generički)

Prije puštanja na slobodu Java SE5 spremnici mogu samo pohranjivati ​​podatke Objekt - jedini univerzalni tip Java. Jednokorijenska hijerarhija znači da se bilo koji objekt može smatrati Objekt , dakle spremnik s elementima Objekt pogodan za skladištenje bilo kakvih predmeta Primitivni tipovi ne mogu se pohraniti u spremnike, ali zahvaljujući mehanizmu automatsko pakiranje(autoboxing) Java SE5 ovo ograničenje nije bitno. O ovoj će temi biti više riječi kasnije u knjizi..

Kada radite s takvim spremnikom, jednostavno stavljate reference objekata u njega, a kasnije ih dohvaćate. Ali ako je spremnik sposoban samo za pohranu Objekt , onda kada se u njega postavi referenca na objekt druge vrste, konverzija u Objekt , odnosno gubitak "individualnosti" objekta. Kada ga dohvaćate natrag, dobivate referencu na Objekt , a ne referenca na tip koji je stavljen u spremnik. Kako ga pretvoriti u određenu vrstu objekta smještenog u spremnik?

Problem je riješen istom konverzijom tipa, ali ovaj put ne koristite upcast (prema hijerarhiji nasljeđivanja prema osnovnom tipu). Sada koristite metodu pretvaranja niz hijerarhiju nasljeđivanja (u podređeni tip). Ova metoda nazvao pretvorba prema dolje. U slučaju uspona, poznato je da je krug figura, tako da je poznato da je pretvorba sigurna, ali u obrnutom obliku (na podređeni tip), nemoguće je unaprijed reći predstavlja li instanca Objekt objekt Krug ili oblik , tako da je nižanje sigurno samo ako znate točno vrstu objekta.

Međutim, opasnost nije tako velika - snižavanje na pogrešan tip rezultirat će pogreškom vremena izvođenja koja se zove izuzetak(Pogledaj ispod). Ali kada dohvaćate reference objekata iz spremnika, morate nekako zapamtiti stvarni tip njihovih objekata kako biste izvršili ispravno downcast.

Smanjenje i provjera tipa tijekom izvođenja zahtijevaju dodatno vrijeme i dodatni napor od programera. Ili možda možete nekako stvoriti spremnik koji poznaje vrstu pohranjenih objekata i tako eliminira potrebu za pretvorbom tipa i mogućim pogreškama? Rješenje se naziva mehanizam parametrizacija tipa. Parametrirani tipovi su klase koje prevoditelj može automatski prilagoditi za rad s određenim tipovima. Na primjer, kompajler može konfigurirati parametrizirani spremnik za pohranjivanje i dohvaćanje samo oblika ( oblik ).

Jedna od najvažnijih promjena Java SE5 je podrška za parametrizirane tipove ( generici). Parametrizirani tipovi lako su prepoznatljivi po uglastim zagradama koje zatvaraju nazive tipova parametara; npr. kontejner ArrayList , dizajniran za pohranu predmeta oblik , kreira se ovako:

ArrayList< Shape >oblici = novi ArrayList< Shape > () ;

Mnoge komponente standardne knjižnice također su modificirane za korištenje generičkih tipova. Kao što ćete uskoro vidjeti, generički tipovi pojavljuju se u mnogim oglednim programima u ovoj knjizi.

Nastanak, uporaba predmeta i njihov životni vijek

Jedan od kritički aspekti rad s predmetima – organizacija njihova stvaranja i uništavanja. Za postojanje svakog objekta potrebni su neki resursi, prvenstveno memorija. Kada objekt više nije potreban, mora se uništiti kako bi resursi koje zauzima mogli biti dostupni drugima. U jednostavnim situacijama zadatak se ne čini teškim: stvorite objekt, koristite ga koliko god je potrebno, a zatim ga uništite. Međutim, u praksi se često javljaju složenije situacije.

Recimo, na primjer, da razvijate sustav za upravljanje zračnim prometom. (Isti model vrijedi i za upravljanje kontejnerima u skladištu, ili sustav za iznajmljivanje videa, ili uzgajivačnicu zalutale životinje.) U početku se sve čini jednostavno: napravi se kontejner zrakoplova, zatim se napravi novi zrakoplov koji se smjesti u kontejner određenog područja kontrole zračnog prometa . Što se tiče oslobađanja resursa, odgovarajući objekt se jednostavno uništi kada zrakoplov napusti zonu praćenja.

Ali možda postoji još jedan sustav registracije zrakoplova, a ti podaci ne zahtijevaju tako veliku pozornost kao glavna funkcija upravljanje. Možda su to zapisi planova leta svih malih zrakoplova koji napuštaju zračnu luku. Tako nastaje drugi kontejner za male zrakoplove; svaki put kada se novi objekt zrakoplova kreira u sustavu, on se također uključuje u drugi spremnik ako je zrakoplov mali. Zatim, neki pozadinski proces radi s objektima u ovom spremniku u trenucima minimalne zauzetosti.

Sada zadatak postaje kompliciraniji: kako znate kada treba izbrisati objekte? Čak i ako ste završili s objektom, moguće je da drugi sustav još uvijek komunicira s njim. Isto se pitanje postavlja u nizu drugih situacija, te u programskim sustavima gdje je potrebno eksplicitno obrisati objekte nakon završetka rada s njima (npr. C++), postaje prilično složeno.

Gdje se pohranjuju podaci o objektu i kako se određuje njihov životni vijek? NA C++ Učinkovitost je na prvom mjestu, tako da programer ima izbor. Za postignuće najveća brzina mjesto izvršenja i životni vijek mogu se odrediti u vrijeme pisanja programa. U ovom slučaju, objekti se guraju na stog (takve se varijable nazivaju automatski) ili u prostor za statičko skladištenje. Dakle, glavni faktor je brzina stvaranja i uništavanja objekata, a to u nekim situacijama može biti neprocjenjivo. Međutim, to dolazi po cijenu fleksibilnosti, budući da se broj objekata, njihov životni vijek i vrste moraju točno znati u fazi projektiranja programa. Pri rješavanju problema šireg profila - razvoj sustava računalno potpomognutog projektiranja
(CAD), kontrola inventara ili kontrola zračnog prometa - ovaj pristup može biti previše ograničen.

Drugi način je dinamičko stvaranje objekata u području memorije koje se naziva "hrpa" ( hrpa). U ovom slučaju, broj objekata, njihove točne vrste i životni vijek ostaju nepoznati sve dok se program ne pokrene. Sve se to utvrđuje "u hodu" dok program radi. Ako trebate novi objekt, jednostavno ga stvorite na hrpi kada je to potrebno. Budući da se hrpom upravlja dinamički, potrebno je puno više vremena za dodjelu memorije iz hrpe tijekom izvođenja programa nego kada se memorija dodjeljuje na stogu. (Potrebna je samo jedna strojna instrukcija za dodjelu memorije na hrpu, pomicanje pokazivača na hrpu prema dolje, a oslobađanje se vrši pomicanjem ovog pokazivača prema gore. Vrijeme potrebno za dodjelu memorije na gomili ovisi o strukturi pohrane.)

Dinamički pristup pretpostavlja da su objekti veliki i složeni, tako da dodatno vrijeme koje je potrebno za dodjelu i oslobađanje memorije neće imati značajan utjecaj na proces njihovog stvaranja. Zatim, dodatna fleksibilnost je vrlo važna za rješavanje osnovnih programskih problema.

NA Java koristi se samo drugi pristup Primitivni tipovi, o kojima će biti riječi u nastavku, poseban su slučaj.. Ključna riječ se koristi svaki put kada se kreira objekt. novi za izgradnju dinamičke instance.

Međutim, postoji još jedan čimbenik, naime životni vijek objekta. U jezicima koji podržavaju stvaranje objekata na stogu, kompajler određuje koliko dugo je objekt u upotrebi i može ga automatski uništiti. Međutim, kada se objekt kreira na hrpi, prevodilac nema pojma o životnom vijeku objekta. U jezicima poput C++, uništavanje objekta mora biti izričito uokvireno u programu; ako se to ne učini, dolazi do curenja memorije (čest problem u programima C++). NA Java postoji mehanizam tzv kolekcija smeća; automatski detektira kada se predmet više ne koristi i uništava ga. Sakupljač smeća je vrlo zgodan jer programera štedi mnogo muke. Što je još važnije, skupljač smeća daje vam puno veće povjerenje da vaš program nije pogođen podmuklim problemom curenja memorije (koji je bacio na koljena više od jednog projekta). C++).

NA Java skupljač smeća je dizajniran tako da se sam može nositi s problemom oslobađanja memorije (ovo ne utječe na druge aspekte kraja životnog vijeka objekta). Sakupljač smeća "zna" kada se objekt više ne koristi i koristi svoje znanje da automatski oslobodi memoriju. Zbog ove činjenice (zajedno s činjenicom da svi objekti nasljeđuju iz jedne osnovne klase Objekt i stvaraju se samo na hrpi) Java puno lakše od programiranja C++. Programer mora preuzeti manje odluka i prevladati manje prepreka.

Rukovanje iznimkama: rješavanje grešaka

Od ranih dana programskih jezika, rukovanje pogreškama bilo je jedna od najzahtjevnijih tema. Vrlo je teško razviti dobar mehanizam za obradu grešaka, tako da mnogi jezici jednostavno ignoriraju ovaj problem, prepuštajući ga programerima softverskih biblioteka. Potonji pružaju polovična rješenja koja djeluju u mnogim situacijama, ali koja se često mogu jednostavno zaobići (obično jednostavno ne obraćajući pozornost na njih). Glavni problem s mnogim mehanizmima za rukovanje iznimkama je taj što se oslanjaju na programerovo savjesno pridržavanje pravila koja jezik ne provodi. Ako je programer nemaran - a to se često događa kad se posao žuri - lako može zaboraviti na te mehanizme.

Mehanizam za rukovanje iznimkama ugrađuje obradu grešaka izravno u programski jezik ili čak u operacijski sustav. Iznimka je objekt koji je bačen na mjesto pogreške, koji zatim može biti "uhvaćen" odgovarajućim rukovateljem iznimkama dizajniranim za određene vrste pogrešaka. Čini se da rukovanje iznimkama definira paralelni put izvršavanja programa koji stupa na snagu kada nešto ne ide po planu. A budući da definira zasebnu putanju izvršenja, kod za obradu pogrešaka ne miješa se s normalnim kodom. Ovo pojednostavljuje pisanje programa jer ne morate stalno provjeravati moguće pogreške. Osim toga, iznimka nije kao numerički kod pogreške koji vraća metoda ili zastavica postavljena u slučaju problematične situacije, potonje se može zanemariti. Izuzetak se ne može zanemariti, zajamčeno je da će se negdje riješiti. Konačno, iznimke omogućuju vraćanje normalnog rada programa nakon neispravne operacije. Umjesto da samo prekinete program, možete ispraviti situaciju i nastaviti s radom; čime se povećava pouzdanost programa.

Mehanizam za rukovanje iznimkama u Java izdvaja se od ostalih jezika jer je ugrađen u jezik od samog početka i odgovornost je programera da ga koristi. Ovo je jedini prihvatljiv način za prijavu pogrešaka. Ako ne napišete kod za pravilno rukovanje iznimkama, dobit ćete pogrešku tijekom kompilacije. Takav dosljedan pristup ponekad uvelike pojednostavljuje rukovanje pogreškama.

Vrijedno je napomenuti da rukovanje iznimkama nije značajka objektno orijentiranog jezika, iako je u tim jezicima iznimka obično predstavljena objektom. Takav mehanizam postojao je i prije pojave objektno orijentiranih jezika.

Paralelno programiranje

Jedan od temeljnih koncepata programiranja je ideja da se radi više stvari u isto vrijeme. Mnogi zadaci zahtijevaju od programa da prekine trenutni rad, riješi neki drugi zadatak i zatim se vrati u glavni proces. Problem je riješen na različite načine.
U početku su programeri koji su poznavali arhitekturu stroja pisali procedure za rukovanje prekidima, odnosno obustava glavnog procesa se izvodila na hardverskoj razini. Ovo je rješenje dobro funkcioniralo, ali je bilo složeno i nije bilo mobilno, što je znatno otežalo prijenos takvih programa na nove vrste računala.

Ponekad su prekidi doista nužni za obradu operacija vremenski kritičnih zadataka, ali postoji cijela klasa zadataka kod kojih samo trebate razbiti zadatak u nekoliko zasebno izvršenih dijelova kako bi program brže reagirao na vanjske utjecaje. Ovi odvojeno izvedeni dijelovi programa nazivaju se potoci, a cijeli princip tzv konkurencija(istodobnost), odn paralelno računanje. Uobičajen primjer paralelnosti je korisničko sučelje. U navojnom programu korisnik može pritisnuti gumb i dobiti brzi odgovor bez čekanja da program završi trenutnu operaciju.

Obično niti samo definiraju kako se dodjeljuje vrijeme jednog procesora. Ali ako operativni sustav podržava više procesora, svaka se nit može dodijeliti posebnom procesoru; tako se postiže pravi paralelizam. Jedna od lijepih značajki paralelizma, na razini jezika, je da programer ne mora znati postoji li jedan ili više procesora u sustavu. Program je logično podijeljen u dretve, a ako stroj ima više od jednog procesora, radi brže bez posebnih podešavanja.

Sve to daje dojam da su streamovi vrlo jednostavni za korištenje. Ali postoji kvaka: zajednički resursi. Ako više niti pokuša pristupiti istom resursu u isto vrijeme, nastaju problemi. Na primjer, dva procesa ne mogu istovremeno slati informacije na pisač. Da biste spriječili sukob, zajednički resursi (kao što je pisač) trebaju biti zaključani dok su u upotrebi. Nit zaključava resurs, dovršava svoju operaciju, a zatim oslobađa zaključavanje tako da netko drugi može pristupiti resursu.

Podrška za paralelnost ugrađena u jezik Java, i s izlazom Java SE5 dodao je značajnu podršku na razini knjižnice.

Java i Internet

Ako a Java je još jedan programski jezik, postavlja se pitanje zašto je toliko važan i zašto se predstavlja kao revolucionarni korak u razvoju softvera? Sa stajališta tradicionalnih programskih zadataka, odgovor nije odmah očit. Iako jezik Java koristan pri izgradnji samostalnih aplikacija, njegova najvažnija primjena bila je i ostala programiranje za mrežu svjetska mreža.

Što je web?

Na prvi pogled, web izgleda prilično tajanstveno zbog obilja novih pojmova kao što su "surfanje", "prisutnost" i "početne stranice". Da biste razumjeli što je to, korisno je razumjeti širu sliku - ali prvo morate razumjeti interakciju sustava klijent/poslužitelj, koji su jedan od izazovne zadatke računalno računalstvo.

Računalstvo klijent/poslužitelj

Osnovna ideja iza sustava klijent/poslužitelj je da imate centralizirano spremište informacija - obično u obliku baze podataka - i da se informacije isporučuju na zahtjev neke grupe ljudi ili računala. U sustavu klijent/poslužitelj, centralizirano spremište informacija igra ključnu ulogu, obično dopuštajući da se podaci mijenjaju na takav način da se te promjene propagiraju korisnicima informacija. Sve zajedno: spremište informacija, softver, koji distribuira informacije, a računalo (računala) na kojem su softver i podaci pohranjeni naziva se poslužitelj. Softver na korisničkom računalu koji komunicira s poslužiteljem, prima informacije, obrađuje ih i zatim ih prikazuje na odgovarajući način naziva se klijent.

Dakle, osnovni koncept klijent/poslužitelj računalstva nije toliko kompliciran. Problemi nastaju jer jedan poslužitelj pokušava poslužiti više klijenata u isto vrijeme. Obično je sustav za upravljanje bazom podataka uključen u rješenje, a programer pokušava "optimizirati" strukturu podataka distribucijom u tablice. Osim toga, sustav često dopušta klijentu dodavanje novih informacija na poslužitelj. A to znači da nove informacije klijenta moraju biti zaštićene od gubitka tijekom pohranjivanja u bazi podataka, kao i od mogućnosti prepisivanja podacima drugog klijenta. (Ovo se zove obrada transakcija.) Kada promijenite klijentski softver, morate ga ne samo kompilirati i testirati, već i instalirati na klijentska računala, što može biti puno teže i skuplje nego što mislite. Posebno je teško organizirati podršku za mnogo različitih operacijskih sustava i računalnih arhitektura. Na kraju, potrebno je uzeti u obzir najvažniji faktor performanse: poslužitelj može primiti stotine zahtjeva u isto vrijeme, a najmanje kašnjenje prijeti ozbiljnim posljedicama. Kako bi smanjili latenciju, programeri pokušavaju distribuirati izračune, često čak i na klijentskom računalu, a ponekad ih prenose na dodatna poslužiteljska računala, koristeći tzv. međuprogramska oprema (međuprogramska oprema). (Proxy programi također olakšavaju održavanje programa.)

Jednostavna ideja širenja informacija među ljudima ima toliko razina složenosti u svojoj implementaciji da se, općenito gledano, njezino rješenje čini nedostižnim. A ipak je vitalan: otprilike polovica svih programskih zadataka temelji se na njemu. Uključen je u rješavanje problema u rasponu od obrade narudžbi i transakcija kreditnim karticama do širenja svih vrsta podataka - znanstvenih, vladinih, burzovnih kotacija... popis je beskrajan. U prošlosti ste morali izraditi zasebno rješenje za svaki novi zadatak. Ova rješenja nije jednostavno izraditi, još teže koristiti, a korisnik je sa svakim novim programom morao učiti novo sučelje. Zadatak računalstva klijent/poslužitelj zahtijeva širi pristup.

Web je poput divovskog poslužitelja

Zapravo, web je jedan ogroman sustav klijent/poslužitelj. Međutim, to nije sve: jedinstvena mreža svi poslužitelji i klijenti koegzistiraju istovremeno. Međutim, ova činjenica vas ne bi trebala zanimati, jer se obično povezujete i komunicirate sa samo jednim poslužiteljem (čak i ako ga morate tražiti po cijelom svijetu).

Isprva je korištena jednostavna jednosmjerna razmjena informacija. Uputili ste zahtjev serveru, on vam je poslao datoteku koju je vaš program za gledanje (odnosno klijent) obradio za vas. Ali uskoro jednostavno preuzimanje statičnih stranica s poslužitelja nije bilo dovoljno. Korisnici su željeli u potpunosti iskoristiti prednosti klijent/poslužiteljskog sustava, slati informacije od klijenta do poslužitelja kako bi, na primjer, pregledavali bazu podataka poslužitelja, dodavali nove informacije poslužitelju ili postavljali narudžbe (što je zahtijevalo posebne sigurnosne mjere) . Stalno promatramo te promjene u procesu web razvoja.

Alati za pregledavanje weba (preglednici) bili su veliki korak naprijed: uveli su koncept informacija koje se prikazuju na isti način na bilo kojoj vrsti računala. Međutim, prvi preglednici još uvijek su bili primitivni i brzo su prestali ispunjavati zahtjeve. Pokazalo se da nisu posebno interaktivni i usporavaju rad i servera i interneta u cjelini - za svaku radnju koja je zahtijevala programiranje, morali ste poslati informaciju na server i čekati da ih on obradi. Ponekad ste morali čekati nekoliko minuta samo da biste saznali da vam nedostaje jedno slovo u zahtjevu. Budući da je preglednik bio samo preglednik, nije mogao obavljati ni najjednostavnije programerske zadatke. (S druge strane, to je jamčilo sigurnost - korisnik je bio zaštićen od pokretanja programa koji sadrže viruse ili bugove.)

Za rješavanje ovih problema korišteni su različiti pristupi. Za početak, poboljšani su standardi grafičkog prikaza kako bi preglednici mogli prikazivati ​​animacije i videozapise. Preostali zadaci zahtijevali su mogućnost pokretanja programa na klijentovom računalu, unutar preglednika. To se zove programiranje na strani klijenta.

Programiranje na strani klijenta

U početku je sustav interakcije između poslužitelja i preglednika bio dizajniran za interaktivni sadržaj, ali je podrška toj interaktivnosti u potpunosti povjerena poslužitelju. Poslužitelj je generirao statične stranice za klijentov preglednik, koji ih je jednostavno obradio i prikazao. Standard HTML podržava najjednostavnije unose: tekstualna polja, radio gumbe, potvrdne okvire, popise i padajuće popise, zajedno s gumbima koji mogu učiniti samo dvije stvari: poništiti podatke obrasca i poslati ih na poslužitelj. Poslane informacije obrađuje sučelje CGI (Common Gateway Interface), koji podržavaju svi web poslužitelji. Tekst zahtjeva označava CGI kako postupati s podacima. Najčešće se na zahtjev pokreće program iz direktorija cgi-bin na poslužitelju. (U retku s adresom stranice u pregledniku, nakon slanja podataka obrasca, ponekad možete vidjeti podstring u zbrci znakova cgi-bin.) Takvi se programi mogu napisati na gotovo svim jezicima. Uobičajeno korišten Perl, budući da je orijentiran na tekst i također interpretirani jezik, stoga se može koristiti na bilo kojem poslužitelju, bez obzira na vrstu procesora ili operativnog sustava. Međutim, jezik Piton(moj omiljeni jezik - idi na www.Python.org) postupno mu osvaja "teritorij" svojom snagom i jednostavnošću.

Mnogi moćni web poslužitelji danas rade u potpunosti na temelju CGI; u načelu, ova tehnologija vam omogućuje da riješite gotovo svaki problem. Međutim, web poslužitelji izgrađeni na CGI programe je teško održavati i imaju problema s odzivom. Vrijeme odziva CGI-program ovisi o količini poslanih informacija, kao io opterećenju poslužitelja i mreže. (Zbog svih spomenutih lansiranja CGI program može dugo trajati). Prvi dizajneri weba nisu predvidjeli koliko brzo će resursi sustava biti iscrpljeni dok se koristi u raznim aplikacijama. Na primjer, u njemu je gotovo nemoguće prikazati grafikone u stvarnom vremenu, jer je pri svakoj promjeni situacije potrebno izgraditi novu GIF datoteku i prenijeti je klijentu. Nema sumnje da ste imali vlastita gorka iskustva - na primjer, jednostavno slanje podataka obrasca. Pritisnite gumb za slanje informacija; server se pokreće CGI- program koji otkriva grešku, generira HTML- stranica koja vam govori o tome, a zatim šalje ovu stranicu u vašem smjeru; morate ponovno upisati podatke i pokušati ponovno. Ne samo da je ovo sporo, nego je jednostavno neelegantno.

Problem se rješava programiranjem na strani klijenta. Preglednici se u pravilu pokreću na snažnim računalima sposobnim za rješavanje širokog spektra zadataka i sa standardnim pristupom temeljenim na HTML računalo jednostavno čeka da mu se posluži sljedeća stranica. Uz programiranje na strani klijenta, pregledniku se daje sav posao koji može obaviti, a za korisnika se to pretvara u brže pregledavanje weba i bolju interaktivnost.

Međutim, rasprava o klijentskom programiranju ne razlikuje se puno od rasprava o programiranju općenito. Uvjeti su isti, ali su platforme različite: preglednik nalikuje jako skraćenom operativnom sustavu. Svejedno morate programirati, tako da programiranje na strani klijenta stvara vrtoglavi niz problema i rješenja. Ovaj odjeljak završava pregledom nekih problema i pristupa svojstvenih programiranju na strani klijenta.

Moduli proširenja

Jedno od najvažnijih područja u klijentskom programiranju postao je razvoj modula proširenja ( dodaci). Ovaj pristup omogućuje programeru da doda novu funkcionalnost pregledniku preuzimanjem malog programa koji je ugrađen u preglednik. Zapravo, od ovog trenutka preglednik dobiva novu funkcionalnost. (Modul proširenja učitava se samo jednom.) Dodaci su preglednicima omogućili brojne brze i moćne inovacije, ali pisanje takvog modula nije lak zadatak i malo je vjerojatno da želite stvarati proširenja svaki put kada kreirate novu stranicu. Vrijednost dodataka za klijentsko programiranje je u tome što omogućuju iskusnom programeru da doda nove značajke pregledniku bez traženja dopuštenja od njegovog kreatora. Dakle, moduli proširenja pružaju "stražnja vrata" za integraciju novih programskih jezika na strani klijenta (iako nisu svi jezici implementirani u takve module).

Skriptni jezici

Razvoj dodataka doveo je do nastanka mnogih skriptnih jezika. Koristeći skriptni jezik, klijentski program ugrađujete izravno u HTML-stranica, a modul koji obrađuje ovaj jezik automatski se aktivira prilikom pregleda. Skriptne jezike obično je prilično lako naučiti; u biti, kod skripte je tekst koji je dio HTML-stranice, tako da se učitava vrlo brzo kao dio jednog zahtjeva poslužitelju tijekom dohvaćanja stranice. Cijena za to je da svatko može vidjeti (i ukrasti) vaš kod. Međutim, malo je vjerojatno da ćete napisati nešto emulirano i sofisticirano u skriptnim jezicima, tako da problem kopiranja koda i nije tako loš.

Skriptni jezik koji podržava gotovo svaki preglednik bez instaliranja dodatnih modula JavaScript(imaju vrlo malo zajedničkog s Java; naziv je korišten kako bi se "zgrabio" komadić uspjeha Java na tržištu). Nažalost, izvorne implementacije JavaScript u različitim preglednicima prilično su se razlikovali jedni od drugih, pa čak i između različitih verzija istog preglednika. Standardizacija JavaScript u obliku ECMAScript bio koristan, ali je trebalo vremena da se njegova podrška pojavi u svim preglednicima (pored toga, tvrtka Microsoft aktivno promovirali vlastiti jezik VBScript, nejasno nalik JavaScript). U općem slučaju, programer se mora ograničiti na minimum mogućnosti JavaScript tako da kod zajamčeno radi u svim preglednicima. Što se tiče rukovanja pogreškama i koda za otklanjanje pogrešaka JavaScript, onda je ovo u najboljem slučaju težak zadatak. Tek nedavno su programeri uspjeli stvoriti istinski složeni sustav napisano u JavaScript(društvo Google, usluga Gmail), a zahtijevao je najveći entuzijazam i iskustvo.

Ovo pokazuje da su skriptni jezici koji se koriste u preglednicima dizajnirani za niz specifičnih zadataka, uglavnom za stvaranje bogatijeg i interaktivnijeg grafičkog korisničkog sučelja ( GUI). Međutim, skriptni jezik može se koristiti za 80% zadataka klijentskog programiranja. Vaš zadatak može biti upravo u tih 80%. Jer skriptni jezici olakšavaju i brzo kreiraju programski kod, prvo biste trebali razmotriti upravo takav jezik prije nego prijeđete na složenija tehnološka rješenja kao što je Java.

Java

Ako skriptni jezici preuzimaju 80% zadataka klijentskog programiranja, tko se onda može nositi s ostalih 20%? Za njih je danas najpopularnije rješenje Java. To nije samo moćan programski jezik dizajniran imajući na umu sigurnost, kompatibilnost s platformom i internacionalizaciju, već i alat koji se stalno razvija s novim značajkama i bibliotekama koje se elegantno uklapaju u tradicionalno složene programske zadatke: višezadaćnost, pristup bazi podataka, mrežno programiranje i distribuirano računalstvo . Klijentsko programiranje Java svodi se na razvoj apleta, kao i korištenje paketa Java Web Start.

Aplet je mini-program koji se može pokrenuti samo unutar preglednika. Appleti se automatski učitavaju kao dio web stranice (na isti način na koji se učitavaju, primjerice, grafike). Kada se aplet aktivira, on izvršava program. Ovo je jedna od prednosti appleta - omogućuje vam automatsku distribuciju programa klijentima s poslužitelja točno kada korisnik treba te programe, a ne prije. Korisnik dobiva najnoviju verziju klijentskog programa, bez ikakvih problema i poteškoća povezanih s ponovnom instalacijom. Prema ideologiji Java, programer stvara samo jedan program koji se automatski pokreće na svim računalima koja imaju preglednike s ugrađenim tumačem Java. (Ovo vrijedi za gotovo sva računala.) Od Java je kompletan programski jezik, što je moguće više posla treba obaviti na strani klijenta prije (ili nakon) pozivanja poslužitelja. Na primjer, ne morate slati zahtjev preko interneta da biste doznali da je došlo do greške u primljenim podacima ili nekim parametrima, a klijentsko računalo može brzo iscrtati nekakav graf bez čekanja da poslužitelj to učini i poslati natrag slikovnu datoteku. Ova shema ne samo da pruža trenutačno povećanje brzine i odziva, već također smanjuje opterećenje glavnog mrežnog prijenosa i poslužitelja, sprječavajući usporavanje cjelokupnog internetskog iskustva.

Alternative

Da budem iskren, apleti Java nije opravdao početni entuzijazam. Pri prvom pojavljivanju Java svi su bili jako oduševljeni programčićima jer su omogućili ozbiljno programiranje na strani klijenta, povećali odziv i smanjili propusnost za internetske aplikacije. Appletima se predviđala sjajna budućnost.

Doista, na webu se može naći niz vrlo zanimljivih apleta. Pa ipak, masovni prijelaz na applete nije se dogodio. Vjerojatno je glavni problem bio preuzimanje paketa od 10 MB za instalaciju okruženja Java Runtime Environment (JRE) previše zastrašujuće za prosječnog korisnika. Činjenica da tvrtka Microsoft nije uključio JRE u isporuci Internet Explorer, konačno je odlučio sudbinu apleta. U svakom slučaju, apleti Java nisu naširoko korišteni.

Međutim, apleti i aplikacije Java Web Start vrlo su korisni u nekim situacijama. Ako je konfiguracija računala krajnjih korisnika pod kontrolom (na primjer, u organizacijama), korištenje ovih tehnologija za distribuciju i ažuriranje klijentskih aplikacija sasvim je opravdano; štedi puno vremena, rada i novca (osobito s čestim ažuriranjima).

.NET i C#

Neko vrijeme glavni pretendent Java-appleti su se smatrali komponentama ActiveX od tvrtke Microsoft, iako su za svoj rad zahtijevali prisutnost na stroju klijenta Windows. Sada Microsoft usprotivio se Java punopravni konkurenti: to je platforma .NETO i programski jezik IZ#. Platforma .NETO je otprilike isto što i virtualni stroj Java(JVM) i knjižnice Java, i jezik IZ# ima jasnu sličnost s jezikom Java. Bez sumnje, ovo je najbolje što je Microsoft stvorio u području programskih jezika i okruženja. Naravno, programeri Microsoft imao neku prednost; to su vidjeli u Java uspjeli, a što ne, i mogli su se nadograditi na te činjenice, ali rezultat se pokazao sasvim vrijednim. Prvi put od svog rođenja, Java bio je pravi natjecatelj. Programeri iz Sunce morao pogledati IZ#, saznajte zašto bi programeri mogli prijeći na ovaj jezik i uložite sve napore da ga ozbiljno poboljšate Java u Java SE5.

NA ovaj trenutak glavno je pitanje hoće li Microsoft dopustiti potpuni prijenos .NETO na druge platforme. NA Microsoft tvrde da u ovome i projektu nema problema mono() pruža djelomičnu implementaciju .NETO za linux. Međutim, budući da je ova implementacija za sada nedovršena Microsoft ne odlučuje izbaciti niti jedan dio, na koji se kladiti .NETO jer je tehnologija na više platformi još uvijek rana.

Internet i intranet

Web pruža najopćenitije rješenje za zadatke klijent/poslužitelj, tako da ima smisla koristiti istu tehnologiju za rješavanje specifičnih problema; to posebno vrijedi za klasičnu interakciju klijent/poslužitelj unutar tvrtke. Tradicionalni pristup klijent/poslužitelj ima problema s razlikama u tipovima klijentskih računala, dodajući im poteškoće u instaliranju novih programa za klijente; oba problema rješavaju preglednici i programiranje na strani klijenta. Kada se web tehnologija koristi za formiranje informacijske mreže unutar tvrtke, takva se mreža naziva intranet. Intraneti pružaju mnogo veću sigurnost od Interneta jer možete fizički kontrolirati pristup poslužiteljima svoje tvrtke. Što se tiče učenja, nekome tko razumije koncept preglednika puno je lakše razumjeti različite stranice i applete, tako da je vrijeme potrebno za svladavanje novih sustava smanjeno.

Pitanje sigurnosti dovodi nas do jednog od smjerova koji se automatski nameću u klijentskom programiranju. Ako vaš program radi na Internetu, onda ne znate na kojoj će platformi raditi. Mora se obratiti posebna pažnja kako bi se izbjeglo širenje netočnog koda. Ovdje su nam potrebna višeplatformska i sigurna rješenja, npr Java ili skriptni jezik.

Intraneti imaju druga ograničenja. Vrlo često svi strojevi na mreži rade na platformi Intel/Windows. Na intranetu ste odgovorni za kvalitetu svog koda i možete ispravljati pogreške čim se pronađu. Osim toga, možda već imate kolekciju rješenja za koja je dokazano da rade u tradicionalnijim sustavima klijent/poslužitelj, dok se novi softver mora ručno instalirati na klijentsko računalo sa svakom nadogradnjom. Vrijeme potrošeno na ažuriranje je najjači argument u korist tehnologija preglednika, gdje se ažuriranja vrše nevidljivo i automatski (isto se može učiniti Java Web Start). Ako ste uključeni u održavanje intraneta, pametnije je krenuti putem koji vam omogućuje da iskoristite ono što već imate, a da ne morate ponovno pisati programe na novim jezicima.

Kada se suočite s ogromnom količinom zadataka klijentskog programiranja koji mogu zbuniti svakog dizajnera, najbolje je procijeniti ih u smislu omjera troškova i koristi. Razmotrite ograničenja svog problema i pokušajte zamisliti najkraći način da ga riješite. Budući da je klijentsko programiranje još uvijek programiranje, razvojne tehnologije koje obećavaju najbrže rješenje uvijek su relevantne. Ovaj proaktivni stav će vam dati priliku da se pripremite za neizbježne probleme programiranja.

Programiranje na strani poslužitelja

Naša rasprava je zaobišla temu programiranja na strani poslužitelja, koju mnogi smatraju najviše jaka točka Java. Što se događa kada pošaljete zahtjev poslužitelju? Češće nego ne, zahtjev se svodi na jednostavan zahtjev "pošalji mi ovu datoteku". Preglednik tada obrađuje datoteku na odgovarajući način: as HTML-stranica poput slike poput Java-applet, poput skripte, itd.

Složeniji zahtjev poslužitelju obično uključuje pristup bazi podataka. U najčešćem slučaju traži se složena pretraga baze podataka, čije rezultate poslužitelj zatim pretvara u HTML-stranicu i šalje vam. (Naravno, ako klijent može izvesti neku radnju pomoću Java ili skriptni jezik, on može obrađivati ​​podatke, što će biti brže i smanjiti opterećenje poslužitelja.) Ili ćete se možda trebati registrirati u bazi podataka prilikom pridruživanja grupi ili odjaviti, što će zahtijevati promjene u bazi podataka. Takve zahtjeve mora obraditi neki kod na poslužitelju; općenito, to je ono što se naziva programiranje na strani poslužitelja. Tradicionalno se programiranje poslužitelja obavljalo na Perl, Python, C++ ili neki drugi jezik koji vam omogućuje stvaranje programa CGI, ali postoje zanimljivije opcije. Tu spadaju oni koji se temelje na Java web poslužitelji koji vam omogućuju programiranje na strani poslužitelja Java pomoću takozvanih servleta. Servleti i njihovi potomci JSP-ovi, dva su glavna razloga zašto se tvrtke koje se bave web sadržajem sele na Java, uglavnom zato što rješavaju probleme nekompatibilnosti s više preglednika.

Unatoč svim pričama o tome Java kao internetski programski jezik, Java zapravo, to je potpuni programski jezik koji može riješiti gotovo sve probleme koji se rješavaju u drugim jezicima. Prednosti Java nisu ograničeni na dobru prenosivost: to je prikladnost za rješavanje programskih problema, i otpornost na pogreške, i velika standardna biblioteka, te brojni razvoji trećih strana - kako postojeći tako i oni koji se stalno pojavljuju.

Sažetak

Znate kako izgleda proceduralni program: definicije podataka i pozivi funkcija. Pronalaženje svrhe takvog programa zahtijeva napor gledanjem funkcija i stvaranjem velike slike u vašem umu. Upravo zbog toga izrada takvih programa zahtijeva korištenje posrednih alata - oni su sami po sebi više usmjereni na računalo, a ne na zadatak koji se rješava.

Budući da OOP dodaje mnoge nove koncepte onima koji su već dostupni u proceduralnim jezicima, prirodno je pretpostaviti da kod Java bit će mnogo kompliciraniji od slične metode u proceduralnom jeziku. Ali ovdje vas čeka ugodno iznenađenje: dobro napisan program u Java obično mnogo lakši za razumijevanje nego njegov proceduralni pandan. Sve što vidite su definicije objekata koje predstavljaju koncepte prostora odlučivanja (ne koncepte računalne implementacije) i poruke poslane tim objektima koje predstavljaju akcije u tom prostoru. Jedna od prednosti OOP-a je da se dobro dizajnirani program može razumjeti jednostavnim pogledom na izvorni kod. Osim toga, obično morate napisati mnogo manje koda, budući da se mnogi zadaci već mogu lako riješiti. postojeće knjižnice klase.

Objektno orijentirano programiranje i jezik Java nisu prikladni za svakoga. Vrlo je važno prvo saznati svoje potrebe kako biste odlučili hoćete li prijeći na Java ili je bolje odlučiti se za neki drugi sustav programiranja (uključujući i onaj koji trenutno koristite). Ako znate da ćete se u doglednoj budućnosti suočiti s vrlo specifičnim potrebama ili će vaš rad biti podložan ograničenjima koja Java ne podnosi, bolje je razmotriti druge mogućnosti (osobito preporučujem da bolje pogledate jezik Piton,). Biranje Java, morate razumjeti koje su druge opcije dostupne i zašto ste odabrali ovaj put.

Razmjena poruka:

Pošaljite izravno na ovu stranu: http://website/javabooks/Thinking_in_Java_4th_edition.html Pošaljite BB kodove: Thinking_in_Java_4th_edition
html-poruka: