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
Objekat ima interfejs 20
Objekat pruža usluge 22
Skrivena implementacija 23
Implementacija ponovne upotrebe 24
Naslijeđe 25
Izmjenjivi objekti i polimorfizam 29
Jednokorijenska hijerarhija 33
Kontejneri 33
Parametrizovani tipovi 35
Stvaranje, korištenje objekata i njihov vijek trajanja 36
Rukovanje izuzecima: Postupanje s greškama 38
Paralelno izvršenje 38
Java i Internet 39
Poglavlje 2. Sve je objekat 48
Svi objekti moraju biti eksplicitno kreirani 49
Objekti se nikada ne moraju brisati 53
Kreiranje novih tipova podataka 54
Metode, argumenti i povratne vrijednosti 56
Kreiranje Java 58 programa
Ključna riječ statički 60
Naš prvi Java 61 program
Komentari i ugrađena dokumentacija 64
Stil dizajna programa 70
Poglavlje 3 Operateri 71
Jednostavne komande za štampanje 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 komanda ide na 109
Životopis 115
Poglavlje 5 Inicijalizacija i završetak 116
Konstruktor garantuje inicijalizaciju 116
Preopterećenje metode 118
Čišćenje: finalizacija i odvoz smeća 130
Inicijalizacija članova razreda 137
Inicijalizacija konstruktora 140
Inicijalizacija niza 146
Životopis 151
Poglavlje 6 Kontrola pristupa 152
Paket kao modul biblioteke 153
Specifikatori Java pristupa 159
Interfejs i implementacija 163
Pristup nastavi 164
Životopis 167
Poglavlje 7 Ponovno korištenje klasa 169
Sintaksa kompozicije 170
Sintaksa nasljeđivanja 172
Delegacija 176
Kombinacija sastava i nasljeđivanja 178
Sastav nasljeđivanja 184
Pretvorba naviše 186
Ključna riječ final 188
Životopis 197
Poglavlje 8. Polimorfizam 198
Opet o uzlaznoj transformaciji. . . > 199
Karakteristike 201
Konstruktori i polimorfizam 208
Kovarijansa tipa povrata 216
Razvoj sa nasljeđem 217
Životopis 220
Poglavlje 9 Interfejsi 221
Apstraktne klase i metode 221
Interfejsi 224
Odvajanje interfejsa od implementacije 227
Proširivanje sučelja putem nasljeđivanja 233
Interfejsi kao sredstvo prilagođavanja 236
Ugniježđeni interfejsi 239
Interfejsi i fabrike 242
Životopis 244
Poglavlje 10 Unutrašnje klase 245
Kreiranje unutrašnjih klasa 245
Komunikacija sa eksternom klasom 246
.this i .new konstrukcije 248
Unutrašnje klase i upcasting 249
Neimenovane interne klase 253
Unutrašnje klase: zašto? 261
Naslijeđe iz unutrašnjih klasa 272
Da li je moguće nadjačati unutrašnju klasu? 272
Lokalne unutrašnje klase 274
Životopis 276
Poglavlje 11 Kolekcije objekata 277
Parametrizovani i ukucani kontejneri 277
Osnovni koncepti 280
Dodavanje grupa elemenata 281
Iteratori 288
Set 294
Red 298
PriorityQueue 299
Kolekcija i Iterator 301
Idiom "metod-adapter" 306
Životopis 309
Poglavlje 12 Rukovanje greškama i izuzecima 310
Veliki izuzeci 310
Hvatanje 312 izuzetaka
Kreiranje vlastitih izuzetaka 314
Specifikacije izuzetaka 319
Hvatanje proizvoljnih izuzetaka 320
Java 328 Standardni izuzeci
Završetak sa konačno 330
Korištenje konačno s povratom 334
Ograničenja pri korištenju izuzetaka 336
Konstruktori 339
Identifikacija izuzetka 343
Alternativna rješenja 344
Životopis 351
Poglavlje 13 Informacije o tipu 352
Potreba za Dynamic Type Inference (RTTI) 352
Registracija fabrika 372
Refleksija: informacije o dinamičkoj klasi 376
Dinamički posrednici 380
Objekti u neodređenom stanju 384
Interfejsi i informacije o tipu 390
Životopis 394
Poglavlje 14 Parameterizacija 397
Jednostavna parametrizacija 398
Parametrizovani interfejsi 404
Parametrizovane metode 407
Izgradnja složenih modela 419
Ograničenja 437
Metaznakovi 440
Životopis 452
Poglavlje 15 Nizovi 454
Karakteristike nizova 454
Niz kao objekat 456
Povratak niza 458
Višedimenzionalni nizovi 460
Nizovi i parametrizacija 463
Kreiranje testnih podataka 465
Kreiranje nizova pomoću generatora 470
Nizovi 474 Helper Toolkit
Životopis 482
Poglavlje 16 Java I/O sistem 483
Fajl 484 kl
Ulaz i izlaz 489
Dodavanje atributa i interfejsa 491
Časovi čitaoca i pisca 494
RandomAccessFile: sam po sebi 497
Tipična upotreba I/O tokova 498
Čitači i pisci datoteka 505
Standardni I/O 507
Novi I/O (nio) 510
Kompresija podataka 531
Serijalizacija objekata 536
Preference 553
Životopis 555
Poglavlje 17 Paralelno izvršenje 557
Klasa konca 559
Umjetnici 561
Dijeljenje resursa 578
Komunikacija između niti 598
Međusobno blokiranje 602
Nove komponente biblioteke 607
CountDownLatch 607
CyclicBarrier 609
Red za blokiranje prioriteta 614
Semafori 619
Modelarstvo 624
Životopis 629
Abecedni indeks 631
Uvod u objekte
Seciramo prirodu, transformišemo je u pojmove i pripisujemo im značenje, kao što to činimo na mnogo načina, jer smo svi učesnici sporazuma koji važi u društvu vezanom za govor, a koji je fiksiran u strukturi jezika. .. Ne možemo uopšte komunicirati, osim pristankom na organizaciju i klasifikaciju podataka utvrđenu ovim ugovorom.
Benjamin Lee Worf (1897-1941)
Pojavu kompjuterske revolucije dugujemo mašini. Stoga se naši programski jezici trude da budu bliže ovoj mašini.
Ali u isto vrijeme, kompjuteri nisu toliko mehanizmi koliko su sredstvo za pojačavanje misli („bicikli za um“, kako voli da kaže Steve Jobs) i još jedno sredstvo samoizražavanja. Kao rezultat toga, programski alati se manje oslanjaju na mašine, a više na naše umove, kao i na druge oblike izražavanja ljudskih težnji, kao što su književnost, slikarstvo, skulptura, animacija i bioskop. Objektno orijentirano programiranje (OOP) dio je pretvaranja kompjutera u sredstvo za samoizražavanje.
Ovo poglavlje će vas upoznati sa osnovama OOP-a, uključujući pogled na glavne metode razvoja softvera. Ona, kao i knjiga općenito, pretpostavlja da imate iskustva u programiranju u proceduralnom jeziku, ne nužno C. Ako smatrate da prije čitanja ove knjige nemate znanja o programiranju i C sintaksi, koristite multimedijalni seminar Thinking in C. koji može preuzeti sa web stranice
U martu prošle godine prijavio se u filijalu jednog velikog međunarodna kompanija u Samari (da. od djetinjstva sam imao mnogo arogancije i ambicije). U to vreme sam znao html, css, java, javascript (osnove), pascal, visualbasic6, mysql upite, php, opšta ideja:c++. Ja uopste nisam poznavao Javu. Ponudili su mi posao dizajnera izgleda, ali sam ga odbio. Samo kao programer! Onda su mi dali listu:
Bruce Eckel Razmišljanje u Javi (ruski prijevod 2. izdanja ili original 4. - pročitajte oba)
-Steve McConnell - savršen kod.
- Grupa od četiri - Dizajn uzoraka. (ovo je skoro ABC OOP-a)
- budite što jasniji o razlici između j2se i j2ee.
decembra ukazala se potreba. dobio posao u malom Samarskom web studiju. odmah je bilo jasno da se radi o prevarantima, ali bilo kakav posao koji bih mogao pokazati budućim poslodavcima je bio potreban. nisu platili da plate (iako su sve usi pojedene obecanjima), ali je kod doveden do standarda dizajna, i sto je najvaznije, naucili su gdje traziti i sta traziti u slucaju greske, sta malo stvari je lako propustiti.
Uz literaturu iznad, pohađao sam kurs intuite (sada razumijem da je smiješan po svom obimu, ali u principu tu postoje osnove)
Krajem februara ponovo sam predala biografiju i dobila poziv za intervju. Ukupno je obavljeno 6 intervjua koji su trajali 1,5 mjesec. Dva od njih održana su putem video veze sa Moskvom. Cela slika je podsećala na film "Dođi sutra". Ali na kraju sam dobio ponudu za posao. Ugovor je sastavljen za rad na određeno vrijeme, jer. U to vrijeme nisam imao diplomu. Prošlog mjeseca sam dobio diplomu i ugovor je produžen za stalno.
Trenutna pozicija Soft-Inženjera. Plata je vise nego zadovoljavajuca. Jučer su ga, u vezi sa prelaskom na puno radno vrijeme, podigli za 30%.
Čak su i u toj prevarantskoj kancelariji tražili primjere rada. Predstavio sam posao koji sam uradio kao slobodnjak. Čak su i djela na drugim jezicima uvijek mnogo bolja nego nijedna.
Ps: Plava diploma iz FIZIKE. Potpuno sam samouk, tako da je sve u vašim rukama. Imam samo engleski iz škole besplatno (7 sati sedmično). iako ga Amerikanac koji nam je došao tokom svog putovanja oko svijeta ne poznaje dobro. Jedva sam pola toga razumio zbog njegovog naglaska. ali to nije tako kritično u mom odjelu. sva dokumentacija na engleskom - naučit ćete čak i ako niste znali)))))
Posebno hvala ovom forumu. Ja sam zapravo studirao ovdje- svakodnevno podučavaju sve teme koje naiđu)
PROGRAMSKA BIBLIOTEKA
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. 4th ed. - Sankt Peterburg: Petar, 2009. - 640 e.: ilustr. - (Serija "Programerska biblioteka").
ISBN 978-5-388-00003-3
Java se ne može shvatiti posmatrajući je samo kao zbirku nekih harakureški - neophodno je shvatiti zadatke ovog jezika kao posebne zadatke programiranja uopšte. r3ia je knjiga o problemima programiranja: zašto su postali problemi i koji pristup Java koristi za njihovo rješavanje. Stoga su karakteristike 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 preštampavanja u originalu, zbog dubokog i istinski filozofskog prikaza zamršenosti jezika, smatra se jednim od najboljih priručnika za Java programere.
BBK 32.973.2-018.1 UDK 004.3
Izdavačka prava stečena dogovorom sa Prentice Hall PTR.
Sva prava zadržana. Nijedan dio ove knjige ne smije se reproducirati u bilo kojem obliku bez pismene dozvole vlasnika autorskih prava.
Informacije sadržane u ovoj knjizi dobijene su iz izvora za koje izdavač vjeruje da su pouzdani. Međutim, s obzirom na moguće ljudske ili tehničke greške, izdavač ne može jamčiti apsolutnu točnost i potpunost datih informacija i nije odgovoran za moguće greške vezano za korištenje knjige.
ISBN 978-0131872486 © Prentice Hall PTR, 2006
ISBN 978-5-388-00003-3 © Prevod na ruski Peter Press LLC, 2009.
© Publikacija na ruskom jeziku, dizajn Piter Press LLC, 2009
Predgovor..................................13
Java SE5 i SE6..................................14
Priznanja................................................14
Poglavlje 1 Uvod u objekte..................................17
Razvoj apstrakcije ................................18
Objekat ima interfejs.................................20
Objekat pruža usluge.................................22
Skrivena implementacija..................................23
Implementacija Ponovna upotreba..................................24
Nasljeđe ................................25
Izmjenjivi objekti i polimorfizam ................................29
Jednokorijenska hijerarhija..................................33
Kontejneri..................................33
Parametrizovani tipovi..................................35
Stvaranje, korištenje predmeta i vrijeme njihovog života......................36
Rukovanje izuzecima: Postupanje s greškama.................................38
Paralelno izvršavanje..................................................38
Java i Internet..................................39
Sažetak................................................47
Poglavlje 2 Sve je objekat...................................................48
Svi objekti moraju biti eksplicitno kreirani..................................49
Objekti se nikada ne moraju brisati..................................................53
Kreiranje novih tipova podataka..................................................54
Metode, argumenti i povratne vrijednosti ................................56
Kreiranje Java programa..................................................58
Ključna riječ static................................60
Naš prvi Java program................................61
Komentari i ugrađena dokumentacija........................................64
Stil programiranja ................................................70
Sažetak................................................70
Poglavlje 3. Operateri .................................71
Jednostavne komande za štampanje..................................71
Java izjave ................................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 naredba goto ................................109
Sažetak................................................115
Poglavlje 5. Inicijalizacija i završetak................................116
Inicijalizacija garancija konstruktora.................................116
Preopterećenje metode................................118
Čišćenje: Završetak i sakupljanje smeća..................................130
Inicijalizacija članova klase................................137
Inicijalizacija konstruktora ................................140
Inicijalizacija nizova..................................146
Sažetak................................151
Poglavlje 6 Kontrola pristupa ..........................152
Paket kao bibliotečki modul..................................153
Java specifikacije pristupa................................159
Interfejs i implementacija..................................163
Pristup razredima................................164
Sažetak................................................167
Poglavlje 7 Ponovna upotreba klasa..................................169
Sintaksa kompozicije................................170
Sintaksa nasljeđivanja..................................172
Delegacija................................176
Kombinacija sastava i nasljeđivanja.........................178
Sastav nasljeđivanja ................................................184
zaštićen......................................185
Konverzija tipa naviše..................................186
Finalna ključna riječ..................................188
Sažetak................................................197
Poglavlje 8 Polimorfizam
Opet o uzlaznoj transformaciji. . . >................199
Karakteristike.....................................201
Konstruktori i polimorfizam..................................208
Kovarijansa tipa povrata......................................216
Dizajniranje sa nasljeđivanjem................................217
Životopis................................220
Poglavlje 9. Interfejsi................................221
Apstraktne klase i metode......................................221
Interfejsi................................224
Odvajanje interfejsa od implementacije.................................227
Proširivanje sučelja putem nasljeđivanja........................233
Interfejsi kao sredstvo prilagođavanja......................................236
Ugniježđeni interfejsi..................................239
Interfejsi i tvornice..................................242
Životopis................................244
Poglavlje 10 Unutrašnje klase................................245
Kreiranje unutrašnjih klasa.................................245
Komunikacija sa eksternom klasom..................................246
Konstrukcije .this i .new................................248
Unutrašnje klase i konverzija naviše......................249
Neimenovane unutrašnje klase......................253
Unutrašnje klase: zašto? ................................. 261
Naslijeđe iz unutrašnjih klasa..................................272
Da li je moguće nadjačati unutrašnju klasu?................................272
Lokalne unutrašnje klase................................274
Sažetak................................................276
Poglavlje 11 Zbirke objekata..................................................277
Parametrizovani i ukucani kontejneri................................277
Osnovni pojmovi.................................280
Dodavanje grupa elemenata.................................281
Lista................................285
Iteratori................................288
LinkedList................................291
Stack.................................292
Mnogi................................................................ 294
Karta.................................296
Red čekanja................................298
PriorityQueue................................299
Kolekcija i iterator..................................301
Idiom "metod-adapter" .........................306
Životopis.................................309
Poglavlje 12 Rukovanje greškama i izuzecima.................310
Glavni izuzeci..................................310
Hvatanje izuzetaka..................................312
Kreiranje vlastitih izuzetaka..................................314
Specifikacije izuzetaka..................................319
Hvatanje proizvoljnih izuzetaka..................................320
Standardni Java izuzeci..................................328
Završetak sa konačno......................330
Korištenje finally s return .................334
Ograničenja u korištenju izuzetaka..................................336
Konstruktori..................................339
Identifikacija izuzetaka..................................343
Alternativna rješenja......................................344
Sažetak................................................351
Poglavlje 13 Informacije o tipu..................................352
Potreba za Dynamic Type Inference (RTTI) .........352
Fabrička registracija ................................372
Refleksija: dinamičke informacije o klasi.........................376
Dinamički posrednici..................................380
Objekti sa neodređenim stanjem..................................384
Interfejsi i informacije o tipu..................................390
Životopis.................................394
Poglavlje 14
Jednostavna parametrizacija..................................398
Parametrizovani interfejsi..................................404
Parametrizovane metode...................407
Modeli kompleksa zgrada..................................419
Ograničenja................................437
Metakarakteri..................................440
Životopis................................452
Poglavlje 15. Nizovi................................454
Karakteristike niza..................................454
Niz kao objekat..................................456
Vraćanje niza..................................458
Višedimenzionalni nizovi..................................460
Nizovi i parametrizacija..................................463
Kreiranje testnih podataka................................465
Kreiranje nizova pomoću generatora.....................470
Priručnik za pomoćne alate za nizove..................................474
Životopis................................482
Poglavlje 16 Java I/O sistem.................................483
Klasa datoteke.................................484
Ulaz i izlaz..................................489
Dodavanje atributa i interfejsa..................................491
Časovi čitaoca i pisca.........................................494
RandomAccessFile: sama po sebi..................................497
Tipična upotreba I/O tokova..................................498
Čitači i pisci datoteka..................................................505
Vjerovatno se ne varam ako pretpostavim da je većina učenika Jave počela to raditi uz pomoć poznate knjige Brucea Eckela: "Razmišljanje u Javi", poznat u ruskom izdanju kao "Filozofija Jave". Nažalost in u elektronskom formatu(na ruskom) 2. izdanje ove knjige je najrasprostranjenije, zasnovano na verziji Java 1.1, koja je odavno izgubila na važnosti. Inovacije koje su se pojavile u narednim verzijama Jave (a posebno u Javi SE5) bile su veoma značajne, što je dovelo do ozbiljne revizije knjige u njenom četvrtom izdanju (čiji je prevod objavljen na ruskom). Međutim, u elektronskom formatu koji je lako čitljiv (i što je najvažnije - za brzo pretraživanje), ruska verzija ove publikacije nije postojala. Stoga sam odlučio da popunim ovu prazninu i napravim punu verziju ove popularne knjige u formatu "wikibook". Vjerujem da će ove informacije biti zanimljive i korisne ne samo onima koji uče jezike, već i svima koji rade u Javi zbog ogromnog broja odličnih primjera koji ilustruju gotovo sve aspekte programiranja na ovom jeziku. Pogotovo kada su u pitanju rijetko korištene Java funkcije.
wikibook "Filozofija Jave" objavljeno na:
"Proljeće na akciji"
Knjige iz serije ".....u akciji"(obično u PDF formatu i obično na engleskom) su zasluženo popularni u određenim krugovima :) Među njima ima i prostranih Talmuda, kao npr. "JSTL u akciji"(lako čitljiv i sa umjerenim znanjem engleskog, ali pogodan za ulogu dobre reference na temu), te skromnije zanate, kao npr. Struts in Action("Nije sve zlato..."). Book "Proljeće na akciji" na ovoj listi je i dalje iz kategorije "teškaša", i to u svakom smislu te riječi. Čitanje bez tečnog engleskog vjerovatno nije lako. A poenta prije nije u kompleksnosti prezentiranog materijala (nije komplikovano), već u činjenici da je ispalo - pretjerano "englesko-umjetničko", ili tako nešto.... Puno lirskih digresija, krilatih izraza, kalambura i drugi bla bla bla, autori jezika, brzo pretvara čitanje ovog vodiča (na originalnom jeziku) u zamoran proces. Ali s druge strane, to vam omogućava da znate da je riječ "izvlačenje"(obično - "izvući") može se koristiti u značenju "izvući iz" (doslovno - "vući, povući"). Kao rezultat toga (uzimajući u obzir opći stil prezentacije usvojen u knjizi) razumjeti tačno značenje fraze poput: "...proljeće nacrtaj ove podatke...", dešava se u isto vreme – i nije lako, a izuzetno je neophodno. Dakle, čitaoci poglavlja koja nisam preveo moraće sami da odluče šta su autori hteli u takvim slučajevima: da se poetski izraze o stvaranju (snimanju) fajla, ili zaigrano ispričaju o čitanju.
Ovu knjigu sam pretvorio iz PDF-a u wikibook kao ekspresnu referencu za moju ličnu upotrebu. Dakle, prevod nije totalan, već samo na mjestima - za koje je bilo dovoljno entuzijazma. Ostala poglavlja su jednostavno data u obliku pogodnom za brzo pretraživanje. Objavljuje se, SVE u formi - "kako jeste", i ne treba kriviti kvalitet ruskog teksta... Nisam profesionalni prevodilac, a nisam imao ni književnog urednika. Možda ću nekoga razočarati činjenicom da nisam preveo neka mjesta i poglavlja knjige (a ni ne planiram da ih prevodim), ali je trebalo ostaviti rezervu za buduće generacije
wikibook "Proljeće u akciji " objavljeno na:UVOD U OBJEKTE
Pojavu kompjuterske revolucije dugujemo mašini. Stoga se naši programski jezici trude da budu bliže ovoj mašini.
Ali u isto vrijeme, kompjuteri nisu toliko mehanizmi, već sredstva za pojačavanje misli („bicikli za um“, kako je volio da kaže Steve Jobs) i još jedno sredstvo samoizražavanja. Kao rezultat toga, programski alati se manje oslanjaju na mašine, a više na naše umove, kao i na druge oblike izražavanja ljudskih težnji, kao što su književnost, slikarstvo, skulptura, animacija i bioskop. Objektno orijentirano programiranje (OOP) dio je pretvaranja računara u medij samoizražavanja.
Ovo poglavlje će vas upoznati sa osnovama OOP-a, uključujući pogled na osnovne tehnike programiranja. Ona, kao i knjiga općenito, pretpostavlja da imate iskustvo u programiranju u proceduralnom jeziku, ne nužno C.
Ovo poglavlje sadrži pripremne i dodatni materijali. Mnogi čitaoci radije prvo zamišljaju širu sliku, a tek onda razumiju zamršenosti OOP-a. Stoga mnoge ideje u ovom poglavlju služe da vam daju solidno razumijevanje OOP-a. Međutim, mnogi ljudi ne shvataju opštu ideju sve dok ne vide konkretno kako stvari funkcionišu; takvi ljudi često zaglave u opštim crtama, bez primjera pred sobom. Ako ste jedan od potonjih i željni ste da počnete sa osnovama jezika, možete preskočiti na sledeće poglavlje - preskakanje ovog neće biti prepreka za pisanje programa ili učenje jezika. Međutim, trebali biste se kasnije vratiti na ovo poglavlje kako biste proširili svoje vidike i razumjeli zašto su objekti toliko važni i gdje se uklapaju u dizajn programa.
Razvoj apstrakcije
Svi programski jezici su izgrađeni na apstrakciji. Možda težina zadataka koje treba riješiti direktno ovisi o vrsti i kvaliteti apstrakcije. Pod "vrstom" mislim na: "Šta tačno apstrahujemo?" Asemblerski jezik je mala apstrakcija od računara na kojem radi. Mnogi takozvani "komandni" jezici nastali nakon njega (kao npr Fortran, BASIC i C) bile su apstrakcije sljedećeg nivoa. Ovi jezici su 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 mašine (u "prostoru rješenja", koji predstavlja mjesto gdje se rješenje implementira - na primjer, kompjuter) 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. Ne samo to, stvorio je i čitavu industriju "programskih metodologija".
Alternativa modeliranju mašine je modeliranje problema koji se rješava. Rani jezici poput LISP i APL, odabrao je poseban pristup modeliranju svijeta oko sebe („Svi problemi se rješavaju listama“ ili „Algoritmi rješavaju sve“, respektivno). PROLOG tretira sve probleme kao lance rješenja. Stvoreni su jezici za programiranje zasnovani na sistemu ograničenja i specijalnim jezicima u kojima se programiranje vršilo manipulacijom grafičkim strukturama (ispostavilo se da je opseg ovih potonjih preuzak). Svaki od ovih pristupa je dobar u određenoj oblasti problema koje treba riješiti, ali kada napustite ovu oblast, postaje teško koristiti ih.
Objektni pristup ide korak dalje pružajući programeru sredstva da predstavi zadatak u njegovom prostoru. Ovaj pristup je prilično opći i ne nameće ograničenja na vrstu problema koji se rješava. Elementi problematičnog prostora i njihove reprezentacije u prostoru rješenja nazivaju se "objekti". (Vjerovatno će vam trebati i drugi objekti koji nemaju analoga u prostoru problema.) Ideja je da se program može prilagoditi specifičnostima problema kreiranjem novih tipova objekata tako da dok čitate kod koji rješava problem, istovremeno vidi reči koje je opisuju. Ovo je fleksibilnija i moćnija apstrakcija, koja po svojim mogućnostima nadmašuje sve što je prije postojalo. Neki dizajneri jezika vjeruju da objektno orijentirano programiranje samo po sebi nije dovoljno za rješavanje svih problema programiranja i zagovaraju kombinaciju različitih programskih paradigmi u jednom jeziku. Takvi jezici se nazivaju multi-paradigma(multiparadigme). Pogledajte knjigu Timothyja Budda Multiparadigm Programming in Leda (Addison-Wesley, 1995).. Dakle, OOP vam omogućava da opišete zadatak u kontekstu samog zadatka, a ne u kontekstu računara na kojem će se rješenje izvršiti. Međutim, veza sa računarom je i dalje očuvana. Svaki objekat je kao mali kompjuter; ima stanje i operacije koje dozvoljava. Takva analogija dobro se uklapa u vanjski svijet, koji je „stvarnost koja nam je data u objektima“ koji imaju karakteristike i ponašanje.
Alan Kay je sažeo i zaključio pet glavnih karakteristika jezika Mali razgovor- prvi uspješan objektno orijentirani jezik, jedan od prethodnika Java. Ove karakteristike predstavljaju "čist", akademski pristup objektno orijentiranom programiranju:
- Sve je objekt. Zamislite objekt kao rafiniranu varijablu; on pohranjuje podatke, ali možete "upitati" objekat, tražeći od njega da izvrši operacije nad samim sobom. Teoretski, apsolutno svaka komponenta problema koji se rješava (pas, zgrada, služba itd.) može se predstaviti kao objekt.
- Program je grupa objekata koji jedni drugima govore šta da rade putem poruka. Da biste uputili zahtjev objektu, "pošaljete mu poruku". Vizuelnije, poruka se može predstaviti kao poziv metode koja pripada određenom objektu.
- Svaki objekat ima svoju "memoriju" koja se sastoji od drugih objekata. Drugim riječima, vi stvarate novi objekat ugrađivanjem postojećih objekata u njega. Dakle, moguće je konstruisati proizvoljno složen program, skrivajući ukupnu složenost iza jednostavnosti pojedinačnih objekata.
- Svaki objekat ima tip. Drugim rečima, svaki objekat je instanca klase, gde je "klasa" ekvivalent reči "tip". Najvažnija razlika između klasa leži upravo u odgovoru na pitanje: "Koje poruke se mogu poslati objektu?"
- Svi objekti određenog tipa mogu primati iste poruke. Kao što ćemo uskoro vidjeti, ovo je vrlo važna okolnost. Pošto je objekat tipa "krug" takođe objekat tipa "oblik", istina je da je "krug" svakako sposoban da prima poruke za "oblik". A to znači da možete pisati kod za oblike i biti sigurni da će raditi za sve što potpada 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 identitet.
Suština je da objekat može imati interne podatke (što je stanje objekta), metode (koje definiraju ponašanje), a svaki objekt se može jedinstveno razlikovati od bilo kojeg drugog objekta – preciznije, svaki objekt ima jedinstvenu adresu u um Ovo je tačno uz neka ograničenja, budući da objekti mogu zaista postojati na drugim mašinama iu različitim adresnim prostorima, a mogu biti i pohranjeni na disku. U ovim slučajevima, identitet objekta mora biti određen nečim drugim osim memorijske adrese..
Objekt ima interfejs
Vjerovatno je da je Aristotel bio prvi koji je pažljivo proučavao koncept 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šanjem, korišten je u prvom objektno orijentiranom jeziku, Simula-67, uz uvođenje osnovne ključne riječi klasa , koji je uveo novi tip u program.
Jezik Simula, kao što mu ime govori, kreiran je da razvija i simulira situacije slične klasičnom problemu "bankovnog blagajnika". Imate grupe blagajnika, kupaca, računa, plaćanja i valuta - puno "objekata". Objekti koji su identični u svim osim internom stanju dok je program pokrenut grupirani su u "klase objekata". Odavde je došlo ključna riječ klasa . Kreiranje apstraktnih tipova podataka je osnovni koncept u svim objektno orijentisanim programiranjem. Apstraktni tipovi podataka djeluju na isti način kao i ugrađeni tipovi: možete kreirati varijable tipa (koje se nazivaju objekti ili instance u OOP terminima) i manipulirati njima (koje se naziva slanje poruka ili upit; vi postavljate zahtjev i objekt odlučuje što će učiniti s to. ). Članovi (elementi) svake klase imaju sličnosti: svaki račun ima stanje, svaki blagajnik prima depozite itd. Istovremeno, svi članovi se razlikuju po svom internom stanju: svaki račun ima individualno stanje, svaki blagajnik ima ljudsko ime. Dakle, svi blagajnici, kupci, računi, transferi itd. mogu biti predstavljeni jedinstvenim entitetima unutar kompjuterski program. Ovo je suština objekta, a svaki objekat pripada određenoj klasi koja definiše njegove karakteristike i ponašanje.
Dakle, iako stvaramo nove tipove podataka u objektnim jezicima, gotovo svi ovi jezici koriste ključnu riječ "class". Kada vidite riječ "vrsta", pomislite "razred" i obrnuto Neki ljudi razlikuju to dvoje ističući da tip definiše interfejs, dok je klasa konkretna implementacija interfejsa..
Pošto klasa definira skup objekata sa identičnim karakteristikama (članovi podataka) i ponašanjem (funkcionalnošću), 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 definiše klasu koja predstavlja neki aspekt zadatka, umesto da koristi već postojeći tip koji predstavlja jedinicu za skladištenje podataka u mašini. Proširujete programski jezik dodavanjem novih tipova podataka koji odgovaraju vašim potrebama. Sistem programiranja favorizuje nove klase i posvećuje im potpuno istu pažnju 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 sistema koji razvijate, upotreba OOP tehnologije lako svodi veliki skup problema na jednostavno rješenje.
Nakon što je nova klasa definirana, možete kreirati bilo koji broj objekata te klase, a zatim njima manipulirati kao da su dio problema. U stvari, 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 objekat da radi ono što želite? Mora postojati mehanizam za slanje zahtjeva objektu da izvrši neku radnju - dovršenje 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 je određeno njegovim tipom. Najjednostavniji primjer bi bila električna sijalica:
Light lt = new Light() ;
lt.on();
Interfejs definira koje zahtjeve možete uputiti određenom objektu. Međutim, kod koji izvršava upite također mora postojati negdje. Ovaj kod, zajedno sa skrivenim podacima, čini implementaciju. Sa stanovišta proceduralnog programiranja, ovo što se dešava 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 kombinuje u jedan: "slanje poruke" (prenos zahtjeva) objektu i obrada od strane objekta (izvršavanje koda).
U ovom primjeru postoji tip (klasa) pod nazivom svjetlo (lampa), betonski objekt tipa svjetlo Sa imenom To , a klasa podržava različite objektne upite svjetlo : Isključite žarulju, upalite je, učinite svjetlijom ili prigušite. Vi kreirate objekat svjetlo , definirajući "referencu" na njega ( To ) i poziva operatera novo da kreirate novu instancu tog tipa. Da biste poslali poruku objektu, morate navesti ime objekta i povezati ga sa željenim zahtjevom tačkom. Sa stanovišta korisnika unapred definisane klase, ovo je sasvim dovoljno za rad na njenim objektima.
Gore prikazani grafikon prati format UML (Jedinstveni jezik modeliranja). Svaka klasa je predstavljena pravokutnikom, sva polja podataka koja su opisana smještena su u njen srednji dio, a metode (funkcije objekta kojem šaljete poruke) su navedene na dnu pravokutnika.
Često na grafikonima 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.
Objekat pruža usluge
Kada pokušavate da dizajnirate ili razumete strukturu programa, često je korisno razmišljati o objektima kao o „pružaocima usluga“. Vaš program pruža usluge korisniku, i to putem usluga koje pružaju drugi objekti. Vaš cilj je proizvesti (ili još bolje pronaći u bibliotekama klasa) skup objekata koji će biti optimalni za rješavanje vašeg problema.
Za početak, zapitajte se: „Kad bih mogao magično ukloniti predmete iz šešira, koji bi bili u stanju da riješe moj problem upravo sada?“ 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 obavljaju računovodstvene kalkulacije, objekat koji ispisuje čekove i fakture na raznim štampačima. Možda neki od ovih objekata već postoje, a za druge objekte vrijedi odgonetnuti kako bi mogli izgledati. Koje usluge bi ti objekti mogli pružati i koji bi im objekti bili potrebni da bi obavljali svoj posao? Ako nastavite ovako, prije ili kasnije ćete reći: “Ovaj objekt je dovoljno jednostavan da možemo sjesti i zapisati ga” ili “Sigurno takav objekt već postoji”. Ovo je razuman način da se rješenje problema distribuira na odvojene objekte.
Predstavljanje objekta kao pružatelj usluga dodatnu korist: pomaže poboljšanju povezanosti ( kohezivnost) objekt. Dobra povezanost - suštinski kvalitet softverski proizvod: to znači da se različiti aspekti softverske komponente (kao što je objekat, iako se može odnositi i na metodu ili biblioteku objekata) dobro uklapaju. Jedan od uobičajene greške dozvoljeno pri dizajniranju objekta je prezasićenje sa velikim brojem svojstava i mogućnosti. Na primjer, kada razvijate modul koji ispisuje čekove, možda biste željeli da "zna" sve o formatiranju i štampanju.
Ako malo razmislite, najvjerovatnije ćete doći do zaključka da je to previše za jedan objekt, pa ćete ići na tri ili više objekata. Jedan objekt će biti katalog svih mogućih oblika čekova i može se pitati kako bi ček trebao biti odštampan. Drugi objekat ili skup objekata će biti odgovoran za generalizovani interfejs za štampanje koji "zna" sve o raznim tipovima štampača (ali ne "razume" ništa u računovodstvu - bolje je kupiti takav objekat nego sami razvijati). Konačno, treći objekat će jednostavno koristiti usluge opisanih objekata kako bi izvršio zadatak. Dakle, svaki objekat je povezan skup usluga koje nudi. U dobro planiranom objektno orijentiranom projektu, svaki objekt dobro radi jedan određeni zadatak bez pokušaja da uradi više nego što je potrebno. Kao što je prikazano, ovo ne samo da vam omogućava da odredite koje objekte želite kupiti (objekat sa interfejsom za štampanje), već vam takođe omogućava da završite sa objektom koji se onda može koristiti negdje drugdje (katalog računa).
Predstavljanje objekata kao dobavljača usluga uvelike pojednostavljuje zadatak. Korisno je ne samo tokom razvoja, već i kada neko pokuša da razume vaš kod ili ponovo upotrebi objekat - tada će moći da adekvatno proceni objekat za nivo pružene usluge, a to će uveliko pojednostaviti integraciju potonjeg u drugi projekat.
Skrivena implementacija
Korisno je podijeliti programere na kreatori klase(oni koji kreiraju nove tipove podataka) i klijent programeriZahvalan sam na ovom mandatu svom prijatelju Scottu Meyersu.(potrošači klasa koji koriste tipove podataka u svojim aplikacijama). Cilj drugog je prikupiti što više časova kako bi se uključili u brzi razvoj programa. Cilj kreatora klase je da izgradi klasu koja otkriva samo ono što je potrebno klijentskom programeru 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 to nekome povrijediti. "Skriveni" dio je obično "najkrhkiji" dio objekta, koji nepažljivi ili neupućeni programer klijenta lako može oštetiti, tako da skrivanje implementacije smanjuje broj grešaka u programima.
U svakoj vezi važno je imati neke granice koje niko od učesnika ne prelazi. Kreiranjem biblioteke uspostavljate odnos sa klijentskim programerom. On je programer kao i vi, ali će koristiti vašu biblioteku za kreiranje aplikacije (i možda biblioteke višeg nivoa). Ako date pristup svim članovima klase bilo kome, programer klijenta može raditi šta god želi sa klasom, a ne postoji način da to učinite da se "igra po pravilima". Čak i ako kasnije trebate ograničiti pristup određenim članovima vaše klase, to se ne može učiniti bez mehanizma kontrole pristupa. Celokupna struktura časa otvorena je za sve prisutne.
Dakle, prvi razlog za ograničavanje pristupa je potreba da se od klijentskog programera zaštite "krhki" detalji - dijelovi interne "kuhinje" koji nisu dio interfejsa kojim korisnici rješavaju svoje probleme. Zapravo, ovo je korisno i za korisnike - oni će odmah vidjeti šta im je važno, a šta mogu zanemariti.
Drugi razlog za pojavu ograničenja pristupa je želja da se dozvoli programeru biblioteke da promeni unutrašnje mehanizme klase bez brige o tome kako će to uticati na klijentskog programera. Na primjer, možete implementirati određenu klasu u žurbi kako biste ubrzali razvoj programa, a zatim je prepisali da biste poboljšali brzinu. Ako ste pravilno odvojili i zaštitili sučelje i implementaciju, to uopće ne bi trebalo biti teško.
Java koristi tri eksplicitne ključne riječi koje karakteriziraju nivo pristupa: javno, privatno i zaštićeno . Njihova namjena i upotreba je vrlo jednostavna. Ovi specificatori pristupa određuju ko ima pravo da koristi definicije koje ih prate. Riječ javnosti 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 neko pokuša da koristi privatni -članovi, bit će zaustavljen greškom kompilacije. specificer zaštićeno djeluje slično kao privatni , sa jednim izuzetkom - izvedene klase imaju pristup označenim članovima zaštićeno ali nemaju pristup privatni -članovi (uskoro ćemo pokriti nasljeđe).
AT Java postoji i "podrazumevani" pristup koji se koristi u odsustvu bilo kojeg od navedenih specifikacija. 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 stiču status privatni .
Implementacija Ponovna upotreba
Generirana i testirana klasa bi (idealno) trebala biti koristan blok koda. Međutim, pokazalo se da je postizanje ovog cilja mnogo teže nego što mnogi misle; razvoj objekata za višekratnu upotrebu zahteva iskustvo i razumevanje suštine materije. Ali kada to uradite kako treba dobra konstrukcija, jednostavno će tražiti implementaciju u drugim programima. Ponovna upotreba koda je jedna od najimpresivnijih prednosti objektno orijentisanih jezika.
Najlakši način da ponovo koristite klasu je direktno kreiranje njenog objekta, ali možete i postaviti objekat te klase unutar nove klase. Ovo nazivamo ubrizgavanjem objekta (kreiranje objekta člana). Nova klasa može sadržavati bilo koji broj objekata drugih tipova, u bilo kojoj kombinaciji koja je neophodna za postizanje potrebne funkcionalnosti. Pošto sastavljamo nova klasa iz već postojećih klasa, ova metoda se poziva kompozicija(kada se kompozicija izvodi dinamički, obično se imenuje agregacija). Kompozicija se često naziva odnosom "ima" ( ima), kao, na primjer, u rečenici "Auto ima motor."
(U UML dijagramima, kompozicija je označena popunjenim dijamantom, što pokazuje, na primjer, da postoji samo jedan automobil. Obično koristim opštiji oblik odnosa: samo linije, bez dijamanta, što znači asocijacija (link). Ovo je obično dovoljno za većinu grafikona gdje vam razlika između kompozicije i agregacije nije značajna.)
Kompozicija je vrlo fleksibilan alat. Objekti članovi vaše nove klase obično se proglašavaju privatnim ( privatni ), što ih čini nedostupnim klijentskim programerima koji koriste klasu. Ovo omogućava da se naprave promjene na ovim objektima članova bez modificiranja postojećeg klijentskog koda. Također možete promijeniti ove članove u vrijeme izvođenja kako biste dinamički kontrolirali ponašanje vašeg programa. Dolje opisano nasljeđivanje nema ovu fleksibilnost jer kompajler nameće određena ograničenja klasama kreiranim korištenjem nasljeđivanja.
Nasljeđivanje igra važnu ulogu u objektno orijentiranom programiranju, pa mu se često pridaje velika pažnja, a početnik bi mogao pomisliti da bi nasljeđivanje trebalo primjenjivati svuda. A to je ispunjeno stvaranjem nespretnih i nepotrebno složenih rješenja. Umjesto toga, kada kreirate nove klase, prvo biste trebali procijeniti mogućnost kompozicije, jer je jednostavnija i fleksibilnija. Ako usvojite preporučeni pristup, vaše programske konstrukcije će postati mnogo jasnije. I kako budete stekli praktično iskustvo, neće biti teško razumjeti gdje bi se nasljeđivanje trebalo koristiti.
Nasljedstvo
Sama po sebi, ideja o objektu je izuzetno zgodna. Objekat vam omogućava da kombinujete podatke i funkcionalnost na konceptualnom nivou, to jest, možete da predstavite željeni koncept iz prostora zadataka umesto da ga konkretizujete koristeći dijalekt mašine. Ovi koncepti čine osnovne jedinice programskog jezika, opisane ključnom riječi class.
Ali morate priznati, bila bi šteta stvoriti nekakvu klasu, a onda ponovo raditi sav posao za sličnu klasu. Mnogo je racionalnije uzeti gotovu klasu, "klonirati" je, a zatim napraviti dodatke i ažuriranja rezultirajućeg klona. To je upravo ono što dobijate kao rezultat nasljeđivanja, s jednim izuzetkom - ako se originalna klasa (koja se naziva i osnovna * klasa, superklasa ili roditeljska klasa) promijeni, tada se sve promjene odražavaju u njenom "klonu" (koji se naziva izvedena klasa , naslijeđena klasa, podklasa ili podređena klasa).
(Strelica (prazan trougao) u UML dijagramu pokazuje od izvedene klase do osnovne klase. Kao što ćete uskoro videti, može postojati više od jedne izvedene klase.)
Tip definira više od samo osobina grupe objekata; takođe je povezan sa drugim tipovima. Ova dva tipa mogu dijeliti sličnosti i ponašanja, ali se razlikuju po broju karakteristika, kao i sposobnosti obrade više poruka (ili njihove obrade drugačije). Za izražavanje ove zajedničkosti 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. Vi kreirate osnovni tip koji predstavlja osnovu vašeg razumijevanja nekih objekata u vašem sistemu. Drugi tipovi su izvedeni iz osnovnog tipa, izražavajući druge implementacije ovog entiteta.
Na primjer, mašina za reciklažu sortira otpad. Osnovni tip će biti "smeće", a svaki komad smeća ima težinu, cijenu, itd., i može se zgnječiti, otopiti ili razložiti. Na osnovu toga se nasljeđuju specifičnije vrste smeća koje imaju dodatne karakteristike (boca ima boju) ili osobine ponašanja ( aluminijumska konzerva može biti zdrobljena, čelična limenka je privučena magnetom). Osim toga, neka ponašanja mogu varirati (cijena papira ovisi o njegovoj vrsti i stanju). Nasljeđivanje vam omogućava da kreirate hijerarhiju 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, lokaciju itd. Svaki oblik se može nacrtati, izbrisati, pomjeriti, obojiti, itd. Zatim se proizvode (naslijeđ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 karakteristike 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 nije potrebno mnogo međumodela koji povezuju opis rješenja s opisom problema. Kada radite sa objektima, hijerarhija tipova postaje primarni model, tako da idete od direktnog opisivanja sistema u stvarnom svetu na opisivanje sistema u kodu. U stvari, jedna od poteškoća u objektno orijentiranom planiranju je ta što vam je vrlo lako prijeći od početka problema do kraja rješenja. Um obučen za složena rješenja često zaglavi kada koristi jednostavne pristupe.
Nasljeđivanjem postojećeg tipa stvarate novi tip. Ovaj novi tip ne sadrži samo sve članove postojećeg tipa (iako su članovi označeni kao privatni , skriveno i nedostupno), ali, što je još važnije, ponavlja interfejs osnovne klase. To znači da sve poruke koje možete poslati osnovnoj klasi, možete poslati i izvedenoj klasi. A pošto razlikujemo tipove klasa po skupu poruka koje im možemo poslati, to znači da je izvedena klasa je poseban slučaj osnovne klase. U prethodnom primjeru, "krug je figura." Ekvivalencija tipova postignuta nasleđivanjem jedan je od osnovnih uslova za razumevanje značenja objektno orijentisanog programiranja.
Pošto 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 ništa drugo niste uradili, metode iz interfejsa osnovne klase će preći u izvedenu klasu nepromenjene. To znači da objekti izvedene klase nisu samo istog tipa, već imaju isto ponašanje, a istovremeno i samo nasljeđivanje gubi smisao.
Postoje dva načina za promjenu nove klase iz osnovne klase. Prvi je prilično očigledan: potpuno nove metode se dodaju izvedenoj klasi. Oni više nisu dio interfejsa osnovne klase. Očigledno da osnovna klasa nije uradila sve što je zadatak zahtevao, pa ste dodali nekoliko metoda. Međutim, tako jednostavan i primitivan pristup nasljeđivanju ponekad se pokaže kao idealno rješenje problema. Međutim, jedna stvar koju treba pažljivo razmotriti je da će i osnovnoj klasi možda trebati ove dodatne metode. Proces identifikacije 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 (posebno u Java, gdje je nasljeđivanje označeno ključnom riječi produžava , odnosno "proširi"), to uopće nije potrebno. Drugi, važniji način modifikacije klase je da promijeniti ponašanje već postojeće metode osnovna klasa. Ovo se zove nadjačavanje (ili nadjačavanje) metode.
Da biste nadjačali metodu, jednostavno kreirate novu definiciju te metode u izvedenoj klasi. Nekako kažete "Koristim isti metod interfejsa, ali želim da radi drugačije stvari za moj novi tip."
Kada se koristi nasljeđivanje, postavlja se očigledno pitanje: treba li nasljeđivanje nadjačati metode samo osnovnu klasu (a ne dodavati nove metode koje ne postoje u osnovnoj klasi)? To bi značilo da bi izvedena klasa bila potpuno istog tipa kao i osnovna klasa, budući da imaju isti interfejs. Kao rezultat, možete slobodno zamijeniti objekte osnovne klase 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 odnosom. "je nešto", pošto se može reći "krug je figura". Da bi se utvrdilo koliko će biti primjereno nasljeđivanje, dovoljno je provjeriti postoji li odnos "postoji" između klasa i koliko je on opravdan.
U drugim slučajevima, interfejs izvedene klase je dopunjen 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 veza se opisuje izrazom "slično" (ovo je moj izraz); novi tip sadrži interfejs starog tipa, ali uključuje i nove metode, a za ove tipove se ne može reći da su potpuno isti. Uzmimo klima uređaj kao primjer.
Pretpostavimo da je vaša kuća opremljena svime potrebnu opremu za kontrolu procesa hlađenja. Zamislite sada da se klima uređaj pokvario i da ste ga zamijenili grijačem koji može i grijati i hladiti. Grejač je „kao” klima uređaj, ali može više. Budući da kontrolni sistem vašeg doma može kontrolirati samo hlađenje, on je ograničen u komunikaciji sa rashladnim dijelom novog objekta. Interfejs novog objekta je proširen, a postojeći sistem ne prepoznaje ništa osim originalnog interfejsa.
Naravno, gledajući ovu hijerarhiju, postaje jasno da bazna klasa "sistema hlađenja" nije dovoljno fleksibilna; treba ga preimenovati u "sistem za kontrolu temperature" tako da uključuje i grijanje - a nakon toga će funkcionirati princip zamjene. Međutim, ovaj dijagram daje primjer onoga što se može dogoditi u stvarnosti.
Nakon upoznavanja sa principom supstitucije, može se steći utisak da je ovaj pristup (potpuna zamena) jedini način za razvoj. Uopšteno govoreći, ako vaše hijerarhije tipova rade na ovaj način, to je stvarno dobro. Ali u nekim situacijama apsolutno je neophodno dodati nove metode u interfejs izvedene klase. Pri bližem razmatranju, oba slučaja izgledaju prilično očigledna.
Izmjenjivi objekti i polimorfizam
Kada se koriste hijerarhije tipova, često je potrebno tretirati objekt određenog tipa kao osnovni tip. Ovo vam omogućava da pišete kod koji ne zavisi od konkretnih tipova. Dakle, u primjeru oblika, metode jednostavno manipuliraju oblicima, bez obzira na to jesu li to krugovi, pravokutnici, trouglovi ili neki još nedefinirani oblici. Svi oblici se mogu crtati, brisati i premještati, 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 kreirati novu podklasu oblika (pentagon) bez promjene metoda koje rade samo s generičkim oblicima. Mogućnost jednostavnog proširenja programa uvođenjem novih izvedenih tipova je vrlo 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 nazvati osnovnim tipovima (krugovi kao figura, bicikl kao vozilo, kormoran kao ptica, itd.), javlja se jedan problem. Ako će metoda reći generičkoj figuri da se nacrta, ili vozilu da prati određeni kurs, ili ptici da leti, kompajler ne može tačno znati koji će dio koda biti izvršen. To je cela poenta – kada se poruka pošalje, programer ne želi da zna koji kod se izvršava; metoda crtanja se može primijeniti na krug, pravougaonik i trokut s jednakim uspjehom, a objekt će izvršiti ispravan kod, ovisno o svom tipu karakteristike.
Ako ne morate znati koji se dio koda izvršava, onda kada dodate novi podtip, njegov implementacijski kod može biti drugačiji bez potrebe za promjenama metode iz koje je pozvan. Ako prevodilac ne zna tačno koji kod da izvrši, šta radi?
AT sljedeći primjer objekat BirdController (kontrola ptica) može raditi samo sa generičkim objektima ptica (ptica), ne znajući njihov tačan tip. Sa tačke gledišta BirdController ovo je zgodno jer ne morate pisati poseban kod za provjeru tipa objekta koji se koristi za to ptica , za upravljanje nekim posebnim ponašanjem. Kako se dešava da kada pozovete metodu move (), bez navođenja tačnog tipa ptica , vrši se ispravna radnja - objekat guska (guska) trči, leti ili pliva i predmet Penguin (pingvin) trčanje ili plivanje?
Odgovor je objašnjen glavna karakteristika objektno orijentirano programiranje: kompajler ne može pozvati takve funkcije na tradicionalan način. Prilikom pozivanja funkcija kreiranih od strane kompajlera koji nije OOP, koristite rano vezivanje- mnogi ne poznaju ovaj pojam jednostavno zato što ne zamišljaju drugu opciju. Sa ranim povezivanjem, kompajler generiše poziv funkcije sa dato ime, a linker vezuje ovaj poziv za apsolutnu adresu koda koji treba da se izvrši. U OOP-u, program nije u mogućnosti da odredi adresu koda do vremena izvršavanja, tako da prilikom slanja poruke objektu mora raditi drugačiji mehanizam.
Da bi riješili ovaj problem, objektno orijentirani programski jezici koriste koncept kasno uvezivanje. Kada pošaljete poruku objektu, kod koji se poziva nije poznat do vremena izvođenja. Kompajler samo osigurava postojanje metode, provjerava tipove za njene parametre i povratnu vrijednost, ali nema pojma kakav će kod biti izvršen.
Za implementaciju kasnog vezivanja, Java koristi posebne isječke koda umjesto apsolutnog poziva. Ovaj kod izračunava adresu tijela metode na osnovu informacija pohranjenih u objektu (proces je detaljno obrađen u poglavlju 7 o polimorfizmu). Stoga se svaki objekat može ponašati drugačije, ovisno o sadržaju ovog posebnog dijela koda. Kada pošaljete poruku, objekat zapravo odlučuje šta će s njom učiniti.
Neki jezici od vas zahtijevaju da eksplicitno navedete da metoda treba koristiti fleksibilni mehanizam kasnog povezivanja (u C++ postoji ključna riječ za ovo virtuelno). U ovim jezicima metode nisu dinamički povezane po defaultu. AT Java kasno uvezivanje se vrši prema zadanim postavkama i ne morate se sjetiti da dodate bilo koju ključnu riječ da biste osigurali polimorfizam.
Prisjetite se primjera s oblicima. Porodica klasa (bazirana na istom interfejsu) je prikazana na dijagramu ranije u ovom poglavlju. Da bismo demonstrirali polimorfizam, napisaćemo isječak koda koji zanemaruje specifičnosti tipa i radi samo na osnovnoj klasi. Ovaj kod je odvojen od specifičnosti tipa, pa ga je lakše napisati i razumjeti. A ako se kroz nasljeđivanje doda novi tip (na primjer, šesterokut), tada će kod koji napišete za novi tip figure raditi jednako dobro kao i kod za postojeće tipove. Tako program postaje proširiv.
Recimo da ste napisali Java sljedeću metodu (uskoro ćete naučiti kako to učiniti):
void doSomething (oblik oblika) (
shape.erase(); // izbrisati
//...
shape.draw(); // draw
}
Metoda radi s generaliziranom figurom ( oblik ), to jest, ne zavisi od određenog tipa objekta koji se crta ili briše. Sada koristimo poziv metode radi nešto() u drugom dijelu programa:
Circle circle = new Circle() ; // krug
Trougao trokut = novi Trokut() ; // trokut
Linija linija = nova linija(); // linija
doSomething(krug) ;
doSomething(trokut) ;
doSomething (linija);
Pozivi metoda radi nešto() automatski rade ispravno, bez obzira na stvarni tip objekta.
Ovo je zapravo prilično važna činjenica. Razmotrite liniju:
doSomething(krug) ;
Ovdje se događa sljedeće: metodi koja očekuje objekt oblik , objekt “krug” je proslijeđen ( Krug ). Od kruga ( Krug ) je istovremeno figura ( oblik ), zatim metodu radi nešto() i tretira je kao figuru. Drugim riječima, bilo koju poruku koju metoda može poslati oblik , takođe je prihvaćeno Krug . Ova akcija je potpuno sigurna i jednako logična.
Mi se odnosimo na ovaj proces rada sa izvedenim tipom kao da je osnovni tip. upcasting. Riječ transformacija znači da se objekt tretira kao da pripada drugom tipu, i uzlazno to je zato što su u dijagramima nasljeđivanja osnovne klase obično na vrhu, a izvedene klase su razvučene na dnu. To znači da je konverzija u osnovni tip kretanje prema gore duž dijagrama, pa je prema tome "gore".
Objektno orijentirani program gotovo uvijek sadrži upcast, jer se tako oslobađate potrebe da znate tačan tip objekta s kojim radite. Pogledajte tijelo metode radi nešto() :
shape.erase();
// ...
shape.draw();
Imajte na umu da ne piše "ako ste objekat Krug , uradi to i ako si objekat Square uradi ovo i to." Takav kod sa zasebnim akcijama za svaki mogući tip oblik bit će zbunjujuće i morat će se mijenjati svaki put kada se doda novi podtip oblik . I tako, samo kažete: „Ti si figura, a znam da umiješ da nacrtaš i obrišeš sebe, pa, uradi to i pobrini se za detalje sam“.
U kodu metode radi nešto() Ono što je zanimljivo je da sve funkcioniše kako treba. Kada je pozvan nacrtaj() za objekat Krug izvršava se drugi kod, a ne onaj koji radi kada se pozove nacrtaj() za objekte Square ili linija , i kada nacrtaj() primijenjen na nepoznatu figuru oblik , ispravno ponašanje je osigurano korištenjem realnog tipa oblik . Unutra je najviši stepen zanimljivo, jer, kao što je napomenuto malo ranije, kada kompajler generiše kod radi nešto() , ne zna tačno s kojim tipovima radi. Shodno tome, očekivalo bi se pozivanje verzija metoda nacrtaj() i obrisati() iz osnovne klase oblik , a ne njihove varijante iz konkretnih klasa Krug , Square ili linija . A ipak sve radi kako treba zahvaljujući polimorfizmu. Kompajler i runtime sistem vode računa o svim detaljima; sve što trebate znati je da će se to dogoditi... i što je još važnije, kako napraviti programe koristeći ovaj pristup. Kada pošaljete poruku objektu, objekt će odabrati ispravno ponašanje koristeći upcast.
Jednokorijenska hijerarhija
Ubrzo nakon pojavljivanja C++ pitanje iz OOP-a počelo se aktivno raspravljati - da li sve klase nužno moraju biti naslijeđene iz jedne osnovne klase? AT Java(kao u skoro svim drugim OOP jezicima osim C++) Na ovo pitanje je odgovoreno potvrdno. Čitava hijerarhija tipova zasnovana je na jednoj osnovnoj klasi Objekat . Pokazalo se da hijerarhija sa jednim korijenom ima mnogo prednosti.
Svi objekti u hijerarhiji s jednim korijenom dijele neki zajednički interfejs, tako da se uglavnom svi mogu smatrati jednim osnovnim tipom. AT C++ izabrana 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 orijentisanim programiranjem, moraćete da kreirate sopstvenu hijerarhiju klasa kako biste dobili iste prednosti koje su ugrađene u druge OOP jezike. I u bilo kojoj novoj biblioteci klasa, možete naići na neki nekompatibilan interfejs. Uključivanje ovih novih interfejsa u arhitekturu vašeg programa zahtevaće dodatni napor (i moguće višestruko nasleđivanje). Da li je dodatna "fleksibilnost" vrijedna toga? C++ slični troškovi? Ako vam zatreba (npr. velika ulaganja na razvoj koda C), tada nećete biti gubitnik. Ako razvoj počinje od nule, pristup Java izgleda produktivnije.
Zajamčeno je da svi objekti u jednoj korijenskoj hijerarhiji dijele neku zajedničku funkcionalnost. Znate da se određene osnovne operacije mogu izvesti na bilo kojem objektu u sistemu. Svi objekti se lako kreiraju na dinamičkoj hrpi, a prosljeđivanje argumenata je uvelike pojednostavljeno.
Jednostruka korijenska hijerarhija znatno olakšava implementaciju prikupljanja smeća - jedno od najvažnijih poboljšanja Java u odnosu na C++. Budući da je informacija o tipu zajamčeno prisutna u bilo kojem objektu u vrijeme izvođenja, nikada neće postojati objekt u sistemu čiji se tip ne može odrediti. Ovo je posebno važno kada se izvode sistemske operacije kao što je rukovanje izuzecima i za veću fleksibilnost programiranja.
Kontejneri
Često se ne zna unaprijed koliko će objekata biti potrebno za rješavanje određenog problema i koliko dugo će postojati. Također je nejasno kako pohraniti takve objekte. Koliko memorije treba izdvojiti za pohranjivanje ovih objekata? Nije poznato, jer će ove informacije postati dostupne samo dok je program pokrenut.
Mnogi problemi u objektno orijentiranom programiranju su riješeni jednostavna akcija: Kreirate drugu vrstu objekta. Novi tip objekta koji rješava ovaj konkretni problem sadrži reference na druge objekte. Naravno, nizovi, koji su podržani u većini jezika, takođe mogu igrati ovu ulogu. Međutim, novi objekat se obično naziva kontejner(ili zbirka, ali u Java izraz se koristi u drugačijem smislu) će se nužno proširiti kako bi primio sve što u njega stavite. Stoga nećete morati unaprijed znati za koliko objekata je kapacitet kontejnera dizajniran. Samo napravite kontejner i on će se pobrinuti za detalje.
Na sreću, dobar OOP jezik dolazi sa skupom gotovih kontejnera. AT C++ to je dio standardne biblioteke C++, koji se ponekad naziva i biblioteka standardni šabloni (Standard Template Library, STL). Mali razgovor dolazi sa veoma širokim asortimanom kontejnera. Java takođe sadrži kontejnere u svojoj standardnoj biblioteci. Za neke biblioteke smatra se da je dovoljno imati jedan jedini kontejner za sve potrebe, ali u drugima (npr. Java) postoje razni kontejneri za sve prilike: nekoliko različitih vrsta lista Lista (za pohranjivanje nizova elemenata), mape Mapa (takođe poznati kao asocijativni nizovi, omogućavaju vam da povežete objekte sa drugim objektima), kao i skupove set (pružajući jedinstvene vrijednosti za svaki tip). Biblioteke kontejnera također mogu sadržavati redove, stabla, stekove i tako dalje.
Sa stanovišta dizajna, sve što vam zaista treba je kontejner koji može riješiti vaš problem. Ako jedna vrsta kontejnera zadovoljava sve potrebe, nema razloga za korištenje drugih vrsta. Dva su razloga zašto morate birati između dostupnih kontejnera. Prvo, kontejneri pružaju različita sučelja i interakcije. Ponašanje i interfejs steka se razlikuje od onog u redu čekanja, koji se ponaša drugačije od skupa ili liste. Jedan od ovih kontejnera može pružiti više od efikasno rešenje vaš zadatak u poređenju sa ostalima. Drugo, različiti kontejneri obavljaju 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 operacije se značajno razlikuju u vremenu izvršenja. Recimo vrijeme uzorkovanja proizvoljnog elementa u ArrayList uvijek ostaje isti bez obzira koji element je odabran. Međutim, u LinkedList štetno je raditi sa nasumičnim pristupom - što se element nalazi niže na listi, veće kašnjenje uzrokuje njegovo pretraživanje. S druge strane, ako trebate umetnuti element u sredinu liste, LinkedList uradi to brže od ArrayList . Ove i druge operacije su različitu efikasnost zavisno od unutrašnja struktura kontejner. U fazi planiranja programa možete odabrati listu LinkedList , a zatim, tokom procesa optimizacije, prebacite se na ArrayList . Zbog apstraktne prirode interfejsa Lista takva tranzicija će zahtijevati minimalne promjene u kodu.
Parametrizovani tipovi (generički)
Prije puštanja Java SE5 kontejneri mogu pohranjivati samo podatke Objekat - jedini univerzalni tip Java. Hijerarhija jednog korijena znači da se svaki objekt može smatrati kao Objekat , dakle kontejner sa elementima Objekat pogodan za skladištenje bilo kakvih predmeta Primitivni tipovi se ne mogu pohraniti u kontejnere, već zahvaljujući mehanizmu automatsko pakovanje(autoboks) Java SE5 ovo ograničenje nije bitno. O ovoj temi će se detaljnije govoriti kasnije u knjizi..
Kada radite sa takvim kontejnerom, jednostavno stavite reference objekata u njega, a kasnije ih dohvatite. Ali ako je kontejner sposoban samo za skladištenje Objekat , zatim kada se u njega postavi referenca na objekt drugog tipa, konverzija u Objekat , odnosno gubitak "individualnosti" objekta. Kada ga vratite, dobijete referencu Objekat , a ne referenca na tip koji je postavljen u kontejner. Kako ga pretvoriti u određeni tip objekta smještenog u kontejner?
Problem je riješen konverzijom istog tipa, ali ovaj put ne koristite upcast (prema hijerarhiji nasljeđivanja do osnovnog tipa). Sada koristite metodu pretvaranja naniže hijerarhije nasljeđivanja (u podređeni tip). Ova metoda pozvao konverzija naniže. U slučaju upcast-a, poznato je da je krug figura, pa se zna da je konverzija sigurna, ali u slučaju obrnutog bacanja (na dječji tip), nemoguće je unaprijed reći da li je instanca predstavlja Objekat objekat Krug ili oblik , tako da je downcasting bezbedno samo ako znate tačno tip objekta.
Međutim, opasnost nije tako velika - spuštanje na pogrešan tip rezultirat će greškom u vremenu izvođenja koja se zove izuzetak(vidi dolje). Ali kada dohvaćate reference objekata iz kontejnera, morate nekako zapamtiti stvarni tip njihovih objekata kako biste izvršili ispravan downcast.
Downcasting i provjera tipa vremena izvršavanja zahtijevaju dodatno vrijeme i dodatni napor od programera. Ili možda možete nekako kreirati kontejner koji zna tip pohranjenih objekata, i tako eliminiše potrebu za konverzijom tipa i potencijalnim greškama? Rješenje se zove mehanizam parametrizacija tipa. Parametrizovani tipovi su klase koje kompajler može automatski prilagoditi za rad sa 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). Parametrizovani tipovi se lako prepoznaju po ugaonim zagradama koje obuhvataju nazive tipova parametara; npr. kontejner ArrayList , dizajniran za skladištenje objekata oblik , kreira se ovako:
ArrayList< Shape >shapes = new ArrayList< Shape > () ;
Mnoge komponente standardne biblioteke su također modificirane da koriste generičke tipove. Kao što ćete uskoro vidjeti, generički tipovi se pojavljuju u mnogim primjerima programa u ovoj knjizi.
Stvaranje, korištenje objekata i njihov vijek trajanja
Jedan od kritične aspekte rad sa objektima - organizacija njihovog 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: kreirate objekt, koristite ga onoliko dugo koliko je potrebno, a zatim ga uništite. Međutim, u praksi se često dešavaju složenije situacije.
Recimo, na primjer, da razvijate sistem za upravljanje vazdušnim saobraćajem. (Isti model važi i za kontrolu tare u skladištu, ili sistem za iznajmljivanje videa, ili uzgajivačnicu lutalica.) U početku sve izgleda jednostavno: kreira se avionski kontejner, zatim se pravi novi avion koji se postavlja u kontejner određene oblasti kontrole letenja . Što se tiče oslobađanja resursa, odgovarajući objekat se jednostavno uništava kada avion napusti zonu praćenja.
Ali možda postoji još jedan sistem registracije aviona, a ti podaci ne zahtijevaju tako veliku pažnju kao glavna funkcija menadžment. Možda je to evidencija plana leta svih malih aviona koji napuštaju aerodrom. Tako se pojavljuje drugi kontejner za male avione; svaki put kada se u sistemu kreira novi avionski objekat, on se takođe uključuje u drugi kontejner ako je letelica mala. Zatim, neki pozadinski proces radi s objektima u ovom kontejneru u trenucima minimalne zauzetosti.
Sada zadatak postaje složeniji: kako znati kada treba izbrisati objekte? Čak i ako ste završili s objektom, moguće je da drugi sistem još uvijek komunicira s njim. Isto pitanje postavlja se iu nizu drugih situacija, te u softverskim sistemima gdje je potrebno eksplicitno brisati objekte nakon što je rad s njima završen (npr. C++), postaje prilično složen.
Gdje se pohranjuju podaci o objektu i kako se određuje njihov vijek trajanja? AT C++ Efikasnost je na prvom mestu, tako da programer ima mogućnost izbora. Za postignuće najveća brzina lokacija izvršenja i životni vijek mogu se odrediti u vrijeme pisanja programa. U ovom slučaju, objekti se guraju u stek (takve varijable se pozivaju automatski) ili u statički prostor za skladištenje. Dakle, glavni faktor je brzina stvaranja i uništavanja objekata, a to može biti neprocjenjivo u nekim situacijama. Međutim, to dolazi po cijenu fleksibilnosti, jer broj objekata, njihov vijek trajanja i tipovi moraju biti poznati tačno u fazi dizajna programa. Prilikom rješavanja problema šireg profila - razvoj sistema kompjuterskog projektovanja
(CAD), kontrola inventara ili kontrola vazdušnog saobraćaja - ovaj pristup može biti previše ograničen.
Drugi način je da se dinamički kreiraju objekti u području memorije zvanom "gomila" ( hrpa). U ovom slučaju, broj objekata, njihovi tačni tipovi i životni vijek ostaju nepoznati dok se program ne pokrene. Sve se to određuje "u hodu" dok program radi. Ako vam je potreban novi objekat, jednostavno ga kreirate na hrpi kada je to potrebno. Pošto se hrpom upravlja dinamički, potrebno je mnogo duže da se memorija iz hrpe dodijeli tokom izvršavanja programa nego kada se memorija dodjeljuje na stog. (Potrebna je samo jedna mašinska instrukcija za dodelu memorije na stek, pomeranje pokazivača steka nadole, a njegovo oslobađanje se vrši pomeranjem ovog pokazivača gore. Vreme potrebno za dodelu memorije na hrpi zavisi od strukture skladišta.)
Dinamički pristup pretpostavlja da su objekti veliki i složeni, tako da dodatno vrijeme potrebno za alociranje i oslobađanje memorije neće imati značajan utjecaj na proces njihovog kreiranja. Zatim, dodatna fleksibilnost je vrlo važna za rješavanje osnovnih problema programiranja.
AT Java koristi se samo drugi pristup Primitivni tipovi, o kojima će biti reči u nastavku, su poseban slučaj.. Ključna riječ se koristi svaki put kada se objekt kreira. novo za izgradnju dinamičke instance.
Međutim, postoji još jedan faktor, a to je životni vijek objekta. U jezicima koji podržavaju kreiranje objekata na steku, kompajler određuje koliko dugo je objekt u upotrebi i može ga automatski uništiti. Međutim, kada se objekt kreira na hrpi, kompajler nema pojma o životnom vijeku objekta. Na jezicima poput C++, uništavanje objekta mora biti eksplicitno uokvireno u programu; ako se to ne učini, dolazi do curenja memorije (čest problem u programima C++). AT Java postoji mehanizam tzv odvoz smeća; automatski detektuje kada se objekat više ne koristi i uništava ga. Sakupljač smeća je vrlo zgodan jer programeru štedi mnogo muke. Što je još važnije, sakupljač smeća vam daje mnogo više samopouzdanja da se podmukli problem s curenjem memorije nije uvukao u vaš program (što je dovelo do više od jednog projekta u C++).
AT Java sakupljač smeća je dizajniran tako da može sam da reši problem oslobađanja memorije (ovo ne utiče na druge aspekte kraja života objekta). Sakupljač smeća "zna" kada se objekat više ne koristi i koristi svoje znanje da automatski oslobodi memoriju. Zbog ove činjenice (zajedno sa činjenicom da svi objekti nasljeđuju iz jedne osnovne klase Objekat i kreiraju se samo na hrpi) Java mnogo lakše od programiranja C++. Programer mora preuzeti manje odluka i savladati manje prepreka.
Rukovanje izuzecima: Postupanje s greškama
Od ranih dana programskih jezika, rukovanje greškama je bila jedna od najzahtjevnijih tema. Vrlo je teško razviti dobar mehanizam za rukovanje greškama, tako da mnogi jezici jednostavno ignorišu ovaj problem, prepuštajući ga programerima softverskih biblioteka. Potonji pružaju polovična rješenja koja funkcioniraju u mnogim situacijama, ali se često mogu jednostavno zaobići (obično jednostavno ne obraćajući pažnju na njih). Glavni problem sa mnogim mehanizmima za rukovanje izuzecima je taj što se oslanjaju na programerovo savesno pridržavanje pravila koja nisu nametnuta jezikom. Ako je programer nemaran - a to se često dešava kada je posao u žurbi - lako može zaboraviti na ove mehanizme.
Mehanizam za rukovanje izuzecima ugrađuje rukovanje greškama direktno u programski jezik, ili čak u njega operativni sistem. Izuzetak je objekt koji je bačen na mjesto greške, koji onda može biti "uhvaćen" od strane odgovarajućeg rukovatelja izuzetkom dizajniranog za određene vrste grešaka. Čini se da rukovanje izuzecima definira paralelnu putanju izvršavanja programa koja stupa na snagu kada nešto ne ide prema planu. A pošto definiše zasebnu putanju izvršavanja, kod za rukovanje greškama se ne meša sa normalnim kodom. Ovo pojednostavljuje pisanje programa jer ne morate stalno provjeravati moguće greške. Osim toga, izuzetak nije poput numeričkog koda greške koji vraća metoda, ili zastavice postavljene u slučaju problematične situacije, ovo drugo se može zanemariti. Izuzetak se ne može zanemariti, zagarantovano je da će se negdje obrađivati. Konačno, izuzeci omogućavaju 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 izuzecima 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 grešaka. Ako ne napišete kod za pravilno rukovanje izuzecima, dobit ćete grešku u vrijeme kompajliranja. Takav dosljedan pristup ponekad uvelike pojednostavljuje rukovanje greškama.
Vrijedi napomenuti da rukovanje izuzecima nije karakteristika objektno orijentisanog jezika, iako je u ovim jezicima izuzetak obično predstavljen objektom. Takav mehanizam je postojao i prije pojave objektno orijentiranih jezika.
Paralelno programiranje
Jedan od osnovnih koncepta programiranja je ideja da se radi više stvari u isto vrijeme. Mnogi zadaci zahtijevaju da program prekine svoj trenutni rad, riješi neki drugi zadatak, a zatim se vrati na glavni proces. Problem je riješen na različite načine.
Isprva su programeri koji su poznavali arhitekturu mašine pisali procedure za rukovanje prekidima, odnosno suspenzija glavnog procesa se vršila na hardverskom nivou. Ovo rješenje je dobro funkcionisalo, ali je bilo složeno i nemobilno, što je otežavalo prenos takvih programa na nove tipove računara.
Ponekad su prekidi zaista potrebni za obradu operacija vremenski kritičnih zadataka, ali postoji cijela klasa zadataka gdje je potrebno samo razbiti zadatak na nekoliko odvojeno izvršavanih dijelova kako bi program brže reagirao na vanjske utjecaje. Ovi zasebno izvršeni dijelovi programa se pozivaju potoci, a cijeli princip se zove istovremenost(istodobnost), ili paralelno računanje. Uobičajeni primjer istodobnosti je korisnički interfejs. U programu sa navojem, korisnik može pritisnuti dugme 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 sistem podržava više procesora, svaka nit se može dodijeliti zasebnom procesoru; tako se postiže pravi paralelizam. Jedna od lepih karakteristika paralelizma, na nivou jezika, jeste da programer ne mora da zna da li postoji jedan ili više procesora u sistemu. Program je logično podijeljen na niti, a ako mašina ima više od jednog procesora, radi brže bez posebnih postavki.
Sve ovo ostavlja 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 štampač) trebaju biti zaključani dok se koriste. Nit zaključava resurs, završava njegovu operaciju, a zatim otpušta zaključavanje tako da neko drugi može pristupiti resursu.
Podrška za konkurentnost ugrađena u jezik Java, i sa izlazom Java SE5 dodala je značajnu podršku na nivou biblioteke.
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 stanovišta tradicionalnih programskih zadataka, odgovor nije odmah očigledan. Iako jezik Java korisna pri izgradnji samostalnih aplikacija, njegova najvažnija primjena bilo je i ostaje programiranje za mrežu svjetske mreže.
Šta je Web?
Na prvi pogled, Web izgleda prilično misteriozno zbog obilja novonastalih termina kao što su "surfovanje", "prisutnost" i "početne stranice". Da biste razumjeli o čemu se radi, korisno je razumjeti širu sliku – ali prvo morate razumjeti interakciju klijent/server sistema, koji su jedan od izazovni zadaci kompjutersko računarstvo.
Client/Server Computing
Osnovna ideja koja stoji iza klijent/server sistema je da imate centralizovano spremište informacija - obično u obliku baze podataka - i da se informacije isporučuju na zahtev neke grupe ljudi ili računara. U sistemu klijent/server, centralizovano spremište informacija igra ključnu ulogu, koje obično omogućava da se podaci modifikuju na takav način da se ove promene propagiraju korisnicima informacija. Sve zajedno: spremište informacija, softver, koji distribuira informacije, a računar(a) na kojem se pohranjuju softver i podaci nazivaju se serverom. Softver na korisnikovoj mašini koji komunicira sa serverom, prima informacije, obrađuje ih, a zatim ih prikazuje na odgovarajući način naziva se klijent.
Dakle, osnovni koncept klijent/server računarstva nije toliko komplikovan. Problemi nastaju jer jedan server pokušava da opslužuje više klijenata u isto vrijeme. Obično je sistem za upravljanje bazom podataka uključen u rešenje, a programer pokušava da "optimizuje" strukturu podataka tako što je distribuira u tabele. Dodatno, sistem često dozvoljava klijentu da doda nove informacije serveru. A to znači da nove informacije klijenta moraju biti zaštićene od gubitka prilikom skladištenja u bazi podataka, kao i od mogućnosti prepisivanja sa podacima drugog klijenta. (Ovo se zove obrada transakcija.) Kada mijenjate klijentski softver, morate ga ne samo kompajlirati i testirati, već i instalirati na klijentske mašine, što može biti mnogo teže i skuplje nego što mislite. Posebno je teško organizovati podršku za mnoge različite operativne sisteme i računarske arhitekture. Na kraju, potrebno je uzeti u obzir najvažniji faktor performanse: server može primiti stotine zahtjeva u isto vrijeme, a najmanje kašnjenje prijeti ozbiljnim posljedicama. Da bi smanjili kašnjenje, programeri pokušavaju da distribuiraju proračune, često čak i na klijentskoj mašini, a ponekad ih prenose na dodatne serverske mašine, koristeći tzv. Middleware (Middleware). (Proxy programi također olakšavaju održavanje programa.)
Jednostavna ideja o širenju informacija među ljudima ima toliko razina složenosti u svojoj implementaciji da se, općenito, njeno rješenje čini nedostižnim. A ipak je od vitalnog značaja: otprilike polovina svih programskih zadataka se zasniva na njemu. Uključen je u rješavanje problema u rasponu od obrade narudžbi i transakcija kreditnim karticama do diseminacije svih vrsta podataka – naučnih, državnih, berzanskih kotacija... lista je beskonačna. U prošlosti ste morali kreirati zasebno rješenje za svaki novi zadatak. Ova rješenja nije lako kreirati, još su teža za korištenje, a korisnik je sa svakim novim programom morao naučiti novi interfejs. Zadatku klijent/server računarstva potreban je širi pristup.
Web je poput ogromnog servera
U stvari, web je jedan ogroman sistem klijent/server. Međutim, to nije sve: jednu mrežu svi serveri i klijenti koegzistiraju istovremeno. Međutim, ova činjenica vas ne bi trebala zanimati, jer se obično povezujete i komunicirate sa samo jednim serverom (čak i ako ga morate tražiti po cijelom svijetu).
U početku je korištena jednostavna jednosmjerna razmjena informacija. Napravili ste zahtjev serveru, on vam je poslao datoteku koju je vaš program za gledanje (tj. klijent) obradio umjesto vas. Ali ubrzo, jednostavno preuzimanje statičnih stranica sa servera nije bilo dovoljno. Korisnici su hteli da u potpunosti iskoriste prednosti klijent/server sistema, da šalju informacije od klijenta do servera kako bi, na primer, pregledali bazu podataka servera, dodali nove informacije na server ili naručili (što je zahtevalo posebne mere bezbednosti) . Konstantno pratimo ove promjene u procesu web razvoja.
Alati za pretraživanje weba (pretraživači) bili su veliki korak naprijed: uveli su koncept informacija koje se prikazuju na isti način na bilo kojoj vrsti računara. Međutim, prvi pretraživači su još uvijek bili primitivni i brzo su prestali ispunjavati zahtjeve. Ispostavilo se da nisu posebno interaktivni i usporavali su rad i servera i interneta u cjelini - za bilo koju radnju koja je zahtijevala programiranje, morali ste poslati informaciju serveru i čekati da ih on obradi. Ponekad ste morali čekati nekoliko minuta da biste saznali da ste propustili jedno slovo u zahtjevu. Pošto je pretraživač bio samo preglednik, nije mogao da obavlja ni najjednostavnije programske zadatke. (S druge strane, ovo je zagarantovano sigurnost - korisnik je bio zaštićen od pokretanja programa koji sadrže viruse ili greške.)
Za rješavanje ovih problema korišteni su različiti pristupi. Za početak, standardi grafičkog prikaza su poboljšani tako da pretraživači mogu prikazivati animacije i video zapise. Preostali zadaci su zahtijevali mogućnost pokretanja programa na klijentovom stroju, unutar pretraživača. Ovo se naziva programiranje na strani klijenta.
Programiranje na strani klijenta
U početku je sistem interakcije između servera i pretraživača bio dizajniran za interaktivni sadržaj, ali je podrška za ovu interaktivnost u potpunosti povjerena serveru. Server je generisao statičke stranice za klijentov pretraživač, koji ih je jednostavno obradio i prikazao. Standard HTML podržava najjednostavnije unose: tekstualna polja, radio dugmad, potvrdne okvire, liste i padajuće menije, zajedno sa dugmadima koji mogu da urade samo dve stvari: resetovanje podataka obrasca i slanje na server. Poslane informacije obrađuje sučelje CGI (Common Gateway Interface), podržan od strane svih web servera. Tekst zahtjeva označava CGI kako postupati sa podacima. Najčešće, na zahtjev, program se pokreće iz cgi-bin direktorija na serveru. (U redu sa adresom stranice u pretraživaču, nakon slanja podataka obrasca, ponekad možete vidjeti podniz u zbrci znakova cgi-bin.) Takvi programi mogu biti napisani na gotovo svim jezicima. Uobičajeno korišteno Perl, budući da je tekstualno orijentisan i takođe interpretirani jezik, stoga se može koristiti na bilo kom serveru, bez obzira na tip procesora ili operativnog sistema. Međutim, jezik Python(moj omiljeni jezik - idi na www.Python.org) postepeno osvaja "teritoriju" od njega zbog svoje moći i jednostavnosti.
Mnogi moćni web serveri danas rade u potpunosti zasnovani na CGI; u principu, ova tehnologija vam omogućava da riješite gotovo svaki problem. Međutim, web serveri izgrađeni na CGI programe je teško održavati i imaju problema sa odzivom. Vrijeme odziva CGI-program zavisi od količine poslanih informacija, kao i od opterećenja servera i mreže. (Zbog svega navedenog lansiranja CGI program može potrajati dugo). Rani dizajneri weba nisu predvidjeli koliko će brzo resursi sistema biti iscrpljeni jer se koristio u raznim aplikacijama. Na primjer, u njemu je gotovo nemoguće prikazati grafikone u realnom vremenu, jer je pri svakoj promjeni situacije potrebno napraviti novu GIF datoteku i prenijeti je klijentu. Nema sumnje da ste imali svoja gorka iskustva – na primjer, jednostavno podnošenje podataka iz obrasca. Pritisnete dugme za slanje informacija; server se pokreće CGI- program koji detektuje grešku, generiše HTML- stranica koja vam govori o tome, a zatim šalje ovu stranicu u vašem smjeru; morate ponovo upisati podatke i pokušati ponovo. Ne samo da je ovo sporo, već je jednostavno neelegantno.
Problem se rješava programiranjem na strani klijenta. Po pravilu, pretraživači rade na moćnim računarima sposobnim za rješavanje širokog spektra zadataka i sa standardnim pristupom zasnovanim na HTML kompjuter jednostavno čeka da mu se servira 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 pretraživanje weba i bolju interaktivnost.
Međutim, diskusija o klijentskom programiranju ne razlikuje se mnogo od diskusija o programiranju općenito. Uslovi su isti, ali platforme su različite: pretraživač liči na jako skraćeni operativni sistem. Ionako 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 za proširenje
Jedna od najvažnijih oblasti u klijentskom programiranju postao je razvoj modula proširenja ( dodaci). Ovaj pristup omogućava programeru da doda novu funkcionalnost pretraživaču preuzimanjem malog programa koji je ugrađen u pretraživač. Zapravo, od ovog trenutka pretraživač dobija novu funkcionalnost. (Modul ekstenzije se učitava samo jednom.) Dodaci su omogućili pretraživačima niz brzih i moćnih inovacija, ali pisanje takvog modula nije lak zadatak i malo je vjerovatno da želite da kreirate ekstenzije svaki put kada kreirate novu stranicu. Vrijednost dodataka za klijentsko programiranje je u tome što omogućavaju iskusnom programeru da doda nove funkcije pretraživaču bez traženja dozvole od njegovog kreatora. Dakle, moduli proširenja pružaju "backdoor" za integraciju novih programskih jezika na strani klijenta (iako nisu svi jezici implementirani u takvim modulima).
Skript jezici
Razvoj dodataka je doveo do mnogih skriptnih jezika. Koristeći skriptni jezik, ugrađujete klijentski program direktno u HTML-stranica, a modul koji obrađuje ovaj jezik se automatski aktivira prilikom pregleda. Skriptni jezici se obično prilično lako uče; u suštini, kod skripte je tekst koji je dio HTML-pages, tako da se učitava vrlo brzo kao dio jednog zahtjeva serveru tokom preuzimanja stranice. Cijena za ovo je da svako može vidjeti (i ukrasti) vaš kod. Međutim, malo je vjerovatno da ćete napisati nešto emulirano i sofisticirano u skript jezicima, tako da problem kopiranja koda i nije tako loš.
Skriptni jezik koji podržava gotovo svaki pretraživač bez instaliranja dodatnih modula je JavaScript(ima vrlo malo zajedničkog sa Java; ime je korišćeno da bi se "ugrabio" deo uspeha Java na tržištu). Nažalost, originalne implementacije JavaScript u različitim pretraživačima bili prilično različiti jedni od drugih, pa čak i između različitih verzija istog pretraživača. Standardizacija JavaScript u obliku ECMAScript je bio koristan, ali je trebalo vremena da se njegova podrška pojavi u svim pretraživačima (osim toga, kompanija Microsoft aktivno promovirali svoj jezik VBScript, nejasno nalik JavaScript). U opštem slučaju, programer se mora ograničiti na minimum mogućnosti JavaScript tako da kod garantuje da radi u svim pretraživačima. Što se tiče rukovanja greškama i koda za otklanjanje grešaka JavaScript, onda je ovo u najboljem slučaju težak zadatak. Tek nedavno su programeri uspjeli stvoriti istinski složen sistem upisano u JavaScript(kompanija Google, servis Gmail), i zahtijevao je najveći entuzijazam i iskustvo.
Ovo pokazuje da su skriptni jezici koji se koriste u pretraživačima dizajnirani za niz specifičnih zadataka, uglavnom za stvaranje bogatijeg i interaktivnijeg grafičkog korisničkog sučelja ( GUI). Međutim, skriptni jezik se može koristiti za 80% zadataka klijentskog programiranja. Vaš zadatak može biti samo u tih 80%. Zato što jezici za skriptiranje olakšavaju i brzo kreiranje programski kod, trebali biste prvo razmotriti upravo takav jezik prije nego što pređete na složenija tehnološka rješenja kao što su Java.
Java
Ako skriptni jezici preuzimaju 80% zadataka klijentskog programiranja, ko onda može podnijeti ostalih 20%? Za njih je danas najpopularnije rješenje Java. Ne samo da je moćan programski jezik dizajniran imajući na umu sigurnost, kompatibilnost platforme i internacionalizaciju, već je i alat koji se stalno razvija s novim funkcijama i bibliotekama koje se elegantno uklapaju u tradicionalno složene programske zadatke: više zadataka, pristup bazi podataka, mrežno programiranje i distribuirano računarstvo. Klijentsko programiranje Java svodi se na razvoj apleta, kao i na korištenje paketa Java Web Start.
Aplet je mini-program koji se može pokrenuti samo unutar pretraživača. Apleti se automatski učitavaju kao dio web stranice (na isti način na koji se, na primjer, učitavaju grafike). Kada je aplet aktiviran, on izvršava program. Ovo je jedna od prednosti apleta - omogućava vam da automatski distribuirate programe klijentima sa servera tačno kada su korisniku potrebni ovi programi, a ne ranije. Korisnik dobija najnoviju verziju klijentskog programa, bez ikakvih problema i poteškoća povezanih s ponovnom instalacijom. Prema ideologiji Java, programer kreira samo jedan program koji se automatski pokreće na svim računarima koji imaju pretraživače sa ugrađenim interpretatorom Java. (Ovo važi za skoro sve računare.) Od Java je kompletan programski jezik, što je moguće više posla treba obaviti na strani klijenta prije (ili poslije) pozivanja servera. Na primjer, ne morate slati zahtjev preko interneta da biste saznali da je došlo do greške u primljenim podacima ili nekim parametrima, a klijentski računar može brzo nacrtati neku vrstu grafikona bez čekanja da to uradi server i poslati nazad datoteku slike. Ova šema ne samo da pruža trenutnu prednost brzine i odziva, već i smanjuje opterećenje glavnog mrežnog transporta i servera, sprečavajući usporavanje ukupnog internet iskustva.
Alternative
Da budem iskren, appleti Java nije opravdalo prvobitni entuzijazam. Pri prvom pojavljivanju Java svi su bili veoma oduševljeni apletima jer su omogućili ozbiljno programiranje na strani klijenta, povećan odziv i smanjen propusni opseg za internet aplikacije. Predviđena je velika budućnost apletima.
Zaista, na webu se može naći niz vrlo zanimljivih apleta. Ipak, masovni prelazak na aplete nije se dogodio. Vjerojatno je glavni problem bilo preuzimanje paketa od 10 MB za instalaciju okruženja Java Runtime Environment (JRE) previše zastrašujuće za prosječnog korisnika. Činjenica da je kompanija Microsoft nije uključio JRE u isporuci Internet Explorer, konačno je odlučila sudbinu apleta. U svakom slučaju, apleti Java nisu bile u širokoj upotrebi.
Međutim, apleti i aplikacije Java Web Start su veoma korisni u nekim situacijama. Ako je konfiguracija računara krajnjih korisnika pod kontrolom (na primjer, u organizacijama), upotreba ovih tehnologija za distribuciju i ažuriranje klijentskih aplikacija je sasvim opravdana; štedi mnogo vremena, rada i novca (naročito uz česta ažuriranja).
.NET i C#
Već neko vrijeme glavni kandidat Java-apleti su smatrani komponentama ActiveX iz kompanije Microsoft, iako su za svoj rad zahtijevali prisustvo na mašini klijenta Windows. Sad Microsoft protiv Java punopravni konkurenti: to je platforma .NET i programski jezik IZ #. Platforma .NET je otprilike isto što i virtuelna mašina Java(JVM) i biblioteke Java, i jezik IZ # ima jasnu sličnost sa jezikom Java. Bez sumnje, ovo je najbolje što je Microsoft stvorio na polju programskih jezika i okruženja. Naravno, programeri Microsoft imao određenu prednost; videli su to u Java uspjelo i ono što nije, i moglo se graditi na ovim činjenicama, ali rezultat se pokazao sasvim dostojnim. Prvi put od njegovog rođenja, Java postojao je pravi konkurent. Programeri iz Ned morao pogledati IZ #, saznajte zašto bi programeri možda željeli da pređu na ovaj jezik i uložite sve napore da se ozbiljno poboljšaju Java in Java SE5.
AT ovog trenutka glavno pitanje je da li će Microsoft dozvoliti potpuni prenos .NET na druge platforme. AT Microsoft tvrde da u ovome i projektu nema problema mono() obezbeđuje delimičnu implementaciju .NET za linux. Međutim, kako je ova implementacija za sada nedovršena Microsoft ne odluči da izbaci bilo koji dio toga, da se na njega kladi .NET kao cross-platform tehnologija je još uvijek rano.
Internet i intranet
Web pruža najopćenitije rješenje za klijent/server zadatke, tako da ima smisla koristiti istu tehnologiju za rješavanje specifičnih problema; ovo posebno važi za klasičnu interakciju klijent/server unutar kompanije. Tradicionalni pristup klijent/server ima problema sa razlikama u tipovima klijentskih računara, dodajući im poteškoće prilikom instaliranja novih programa za klijente; oba problema su rešena pretraživačima i programiranjem na strani klijenta. Kada se web tehnologija koristi za formiranje informacijske mreže unutar kompanije, takva mreža se naziva intranet. Intraneti pružaju mnogo više sigurnosti od interneta jer možete fizički kontrolirati pristup serverima vaše kompanije. U smislu učenja, nekome ko razumije koncept pretraživača mnogo je lakše razumjeti različite stranice i aplete, tako da se smanjuje vrijeme za savladavanje novih sistema.
Pitanje sigurnosti dovodi nas do jednog od pravaca koji se automatski javlja u klijentskom programiranju. Ako vaš program radi na Internetu, onda ne znate na kojoj će platformi raditi. Posebnu pažnju treba posvetiti izbjegavanju širenja pogrešnog koda. Ovdje su nam potrebna cross-platformska i sigurna rješenja, npr Java ili skriptni jezik.
Intraneti imaju druga ograničenja. Vrlo često, sve mašine na mreži rade na platformi Intel/Windows. Na intranetu ste odgovorni za kvalitet vašeg koda i možete ispraviti greške kada se pronađu. Osim toga, možda već imate kolekciju rješenja za koja je dokazano da rade u tradicionalnijim klijent/server sistemima, dok se novi softver mora ručno instalirati na klijentskoj mašini sa svakom nadogradnjom. Vrijeme utrošeno na ažuriranja je najjači argument u korist tehnologija pretraživača, 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, mudrije je krenuti putem koji vam omogućava da iskoristite ono što već imate bez potrebe da prepisujete programe na novim jezicima.
Kada se suočite sa ogromnim obimom zadataka klijentskog programiranja koji mogu zbuniti svakog dizajnera, najbolje ih je procijeniti u smislu omjera troškova i koristi. Uzmite u obzir ograničenja vašeg 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 su uvijek relevantne. Ovaj proaktivan stav će vam dati priliku da se pripremite za neizbježne probleme programiranja.
Programiranje na strani servera
Naša rasprava je zaobišla temu programiranja na strani servera, za koju mnogi smatraju da je najviše jača strana Java. Šta se dešava kada pošaljete zahtev serveru? Češće nego ne, zahtjev se svodi na jednostavan zahtjev "pošalji mi ovaj fajl". Pregledač zatim obrađuje datoteku na odgovarajući način: as HTML-Sviđa mi se slika Java-aplet, kao skripta, itd.
Složeniji zahtjev prema serveru obično uključuje pristup bazi podataka. U najčešćem slučaju, traži se složena pretraga baze podataka, u čije rezultate server zatim konvertuje HTML-stranica i šalje Vama. (Naravno, ako klijent može izvršiti neku radnju koristeći Java ili skriptni jezik, podatke može obraditi on, što će biti brže i smanjiti opterećenje servera.) Ili ćete se možda morati registrovati u bazi podataka kada se pridružite grupi ili odjaviti, što će zahtijevati promjene u bazi podataka. Takvi zahtjevi moraju biti obrađeni nekim kodom na serveru; općenito, to je ono što se zove programiranje na strani servera. Tradicionalno, serversko programiranje je rađeno na Perl, Python, C++ ili drugi jezik koji vam omogućava da kreirate programe CGI, ali ima zanimljivijih opcija. To uključuje one zasnovane na Java web servere koji vam omogućavaju programiranje na strani servera Java koristeći takozvane servlete. Servleti i njihovo potomstvo JSP-ovi, dva su glavna razloga zašto se kompanije za web sadržaj kreću Java, uglavnom zato što rješavaju probleme nekompatibilnosti među pretraživačima.
Uprkos svim pričama o tome Java kao internet programski jezik, Java u stvari, to je punopravni programski jezik koji može riješiti gotovo sve probleme riješene na drugim jezicima. Prednosti Java nisu ograničeni na dobru prenosivost: to je pogodnost za rješavanje problema programiranja, i otpornost na greške, i velika standardna biblioteka, i brojni razvoji trećih strana - postojeći i koji se stalno pojavljuju.
Sažetak
Znate kako izgleda proceduralni program: definicije podataka i pozivi funkcija. Pronalaženje svrhe takvog programa zahtijeva trud gledanjem funkcija i stvaranjem velike slike u svom umu. Upravo zbog toga stvaranje ovakvih programa zahtijeva korištenje srednjih alata - oni su sami po sebi više orijentirani na računalo, a ne na zadatak koji se rješava.
Pošto OOP dodaje mnoge nove koncepte onima koji su već dostupni u proceduralnim jezicima, prirodno je pretpostaviti da je kod Javaće biti mnogo komplikovanije od slične metode u proceduralnom jeziku. Ali ovdje vas čeka ugodno iznenađenje: dobro napisan program Java obično mnogo lakši za razumevanje nego njegov proceduralni parnjak. Sve što vidite su definicije objekata koje predstavljaju koncepte prostora odlučivanja (ne koncepte kompjuterske implementacije) i poruke koje se šalju onim objektima koji predstavljaju akcije u tom prostoru. Jedna od prednosti OOP-a je da se dobro dizajniran program može razumjeti jednostavnim gledanjem u izvorni kod. Osim toga, obično morate pisati mnogo manje koda, jer se mnogi zadaci već mogu lako riješiti. postojeće biblioteke casovi.
Objektno orijentirano programiranje i jezik Java nisu pogodni za svakoga. Vrlo je važno da prvo saznate svoje potrebe kako biste odlučili hoćete li se prebaciti na Java ili je bolje da se odlučite za drugi sistem programiranja (uključujući i ovaj koji trenutno koristite). Ako znate da ćete se u doglednoj budućnosti suočiti sa vrlo specifičnim potrebama ili će vaš rad biti podložan ograničenjima koja Java ne snalazi se, bolje je razmotriti druge mogućnosti (posebno 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 direktno na ovu stranu: http://website/javabooks/Thinking_in_Java_4th_edition.html Pošaljite BB kodove: Thinking_in_Java_4th_editionhtml-poruka:
Za početnike: uzgoj brojlera kod kuće Prokuhana voda za brojlere
Samo ljubavnici će preživeti
Karakteristike oglašavanja namijenjenog djeci
retuširanje starih fotografija u photoshopu retuširanje starih fotografija
Šta je NPO: dekodiranje, definisanje ciljeva, vrste aktivnosti Da li neprofitna organizacija ima pravo