Նախնական փաստաթուղթը փոխելու համար «blank.fb2» ֆայլը ձեռքով խմբագրեք։

Նախաբան 13

Java SE5 և SE6 14

Շնորհակալություն 14

Գլուխ 1 Օբյեկտների ներածություն 17

Աբստրակցիայի զարգացում 18

Օբյեկտն ունի ինտերֆեյս 20

Հաստատությունը ծառայություններ է մատուցում 22

Թաքնված իրականացում 23

Վերօգտագործման իրականացում 24

Ժառանգություն 25

Փոխարինելի առարկաներ և պոլիմորֆիզմ 29

Միակ արմատային հիերարխիա 33

Բեռնարկղեր 33

Պարամետրացված տեսակներ 35

Օբյեկտների ստեղծում, օգտագործում և դրանց կյանքի տևողությունը 36

Բացառությունների կառավարում. Սխալների հետ գործ ունենալը 38

Զուգահեռ կատարում 38

Java և ինտերնետ 39

Գլուխ 2. Ամեն ինչ առարկա է 48

Բոլոր օբյեկտները պետք է բացահայտորեն ստեղծվեն 49

Օբյեկտները երբեք չպետք է ջնջվեն 53

Տվյալների նոր տեսակների ստեղծում 54

Մեթոդներ, փաստարկներ և վերադարձի արժեքներ 56

Java 58 ծրագրի ստեղծում

Հիմնաբառ ստատիկ 60

Մեր առաջին Java 61 ծրագիրը

Մեկնաբանություններ և ներկառուցված փաստաթղթեր 64

Ծրագրի ձևավորման ոճ 70

Գլուխ 3 Օպերատորներ 71

Պարզ տպման հրամաններ 71

Java 72 հայտարարություններ

Բառացի 82

Java-ին բացակայում է sizeof() 92-ը

Ռեզյումե 100

Գլուխ 4 Կառավարման կառուցվածքներ 101

Շարահյուսություն 105-ի համար

ընդմիջել և շարունակել 108

Վատ հրամանը ստացել է 109

Ռեզյումե 115

Գլուխ 5 Նախնականացում և դադարեցում 116

Կոնստրուկտորը երաշխավորում է սկզբնավորումը 116

Գերբեռնման մեթոդ 118

Մաքրում. վերջնական մշակում և աղբահանություն 130

Դասարանի անդամների սկզբնավորում 137

Կոնստրուկտորի սկզբնավորում 140

Զանգվածի սկզբնավորում 146

Ռեզյումե 151

Գլուխ 6 Մուտքի վերահսկում 152

Փաթեթ որպես գրադարանային մոդուլ 153

Java Access Specifers 159

Ինտերֆեյս և իրականացում 163

Մուտք դեպի դասեր 164

Ռեզյումե 167

Գլուխ 7 Դասերի վերօգտագործում 169

Կոմպոզիցիայի շարահյուսություն 170

Ժառանգական շարահյուսություն 172

Պատվիրակություն 176

Կազմության և ժառանգության համադրում 178

Կազմն ընդդեմ ժառանգության 184

Վերև տիպի փոխարկում 186

Հիմնաբառ վերջնական 188

Ռեզյումե 197

Գլուխ 8. Պոլիմորֆիզմ 198

Կրկին վերափոխման մասին։ . . > 199

Առանձնահատկություններ 201

Կոնստրուկտորներ և պոլիմորֆիզմ 208

Վերադարձի տիպի կովարիանս 216

Զարգացում ժառանգությամբ 217

Ռեզյումե 220

Գլուխ 9 Միջերեսներ 221

Աբստրակտ դասեր և մեթոդներ 221

Ինտերֆեյս 224

Ինտերֆեյսի առանձնացում իրականացումից 227

Ինտերֆեյսի ընդլայնում ժառանգության միջոցով 233

Ինտերֆեյսները՝ որպես հարմարվողականության միջոց 236

Ներդրված միջերեսներ 239

Ինտերֆեյսեր և գործարաններ 242

Ռեզյումե 244

Գլուխ 10 Ներքին դասեր 245

Ներքին դասերի ստեղծում 245

Հաղորդակցություն արտաքին դասի հետ 246

.this և .new կոնստրուկցիաները 248

Ներքին դասեր և վերազինում 249

Անանուն ներքին դասեր 253

Ներքին դասեր. ինչու: 261

Ժառանգություն ներքին դասերից 272

Հնարավո՞ր է արդյոք վերացնել ներքին դասը: 272

Տեղական ներքին դասեր 274

Ռեզյումե 276

Գլուխ 11 Օբյեկտների հավաքածուներ 277

Պարամետրացված և տպագրված բեռնարկղեր 277

Հիմնական հասկացություններ 280

Տարրերի խմբերի ավելացում 281

Իտերատորներ 288

Հավաքածու 294

Հերթ 298

PriorityHueue 299

Հավաքածու և Iterator 301

Իդիոմ «մեթոդ-ադապտեր» 306

Ռեզյումե 309

Գլուխ 12 Սխալների և բացառությունների հետ կապված 310

Հիմնական բացառություններ 310

Բռնում 312 Բացառություններ

Ստեղծելով ձեր սեփական բացառությունները 314

Բացառության բնութագրեր 319

Բռնում կամայական բացառություններ 320

Java 328 ստանդարտ բացառություններ

Դադարեցում վերջապես 330-ով

Օգտագործելով վերջապես վերադարձ 334-ով

Բացառություններ օգտագործելիս սահմանափակումներ 336

Կոնստրուկտորներ 339

Բացառության նույնականացում 343

Այլընտրանքային լուծումներ 344

Ռեզյումե 351

Գլուխ 13 Տիպային տեղեկատվություն 352

Անհրաժեշտ է դինամիկ տիպի եզրակացություն (RTTI) 352

Գործարանների գրանցում 372

Արտացոլում. դասի դինամիկ տեղեկատվություն 376

Դինամիկ միջնորդներ 380

Անորոշ վիճակով առարկաներ 384

Ինտերֆեյսներ և տիպի տեղեկատվություն 390

Ռեզյումե 394

Գլուխ 14 Պարամետրիզացիա 397

Պարզ պարամետրացում 398

Պարամետրացված միջերեսներ 404

Պարամետրացված մեթոդներ 407

Շինությունների համալիր մոդելներ 419

Սահմանափակումներ 437

Մետանիշեր 440

Ռեզյումե 452

Գլուխ 15 Զանգվածներ 454

Զանգվածների առանձնահատկությունները 454

Զանգվածը որպես օբյեկտ 456

Զանգվածի վերադարձ 458

Բազմաչափ զանգվածներ 460

Զանգվածներ և պարամետրացում 463

Թեստային տվյալների ստեղծում 465

Զանգվածների ստեղծում՝ օգտագործելով գեներատորներ 470

Arrays 474 Օգնական գործիքակազմ

Ռեզյումե 482

Գլուխ 16 Java I/O համակարգը 483

Ֆայլ 484 դաս

Մուտք և ելք 489

Հատկանիշների և միջերեսների ավելացում 491

Ընթերցողի և գրողի դասեր 494

RandomAccessFile՝ ինքնին 497

I/O հոսքերի տիպիկ օգտագործում 498

Ֆայլերի ընթերցիչներ և գրողներ 505

Ստանդարտ I/O 507

Նոր I/O (nio) 510

Տվյալների սեղմում 531

Օբյեկտների սերիականացում 536

Նախապատվություններ 553

Ռեզյումե 555

Գլուխ 17 Զուգահեռ կատարում 557

Թեմայի դաս 559

Արվեստագետներ 561

Ռեսուրսների փոխանակում 578

Հաղորդակցություն թելերի միջև 598

Փոխադարձ արգելափակում 602

Գրադարանի նոր բաղադրիչներ 607

CountDownLatch 607

CyclicBarier 609

PriorityBlockingQueue 614

Սեմաֆորներ 619

Մոդելավորում 624

Ռեզյումե 629

Այբբենական ցուցիչ 631

Օբյեկտների ներածություն

Մենք կտրում ենք բնությունը, փոխակերպում այն ​​հասկացությունների և դրանց իմաստ ենք վերագրում, ինչպես անում ենք շատ առումներով, որովհետև մենք բոլորս համաձայնության կողմ ենք, որը վավեր է խոսքով կապված հասարակության մեջ և որը ամրագրված է լեզվի կառուցվածքում: .. Մենք ընդհանրապես չենք կարող շփվել, բացառությամբ՝ համաձայնելով սույն պայմանագրով սահմանված տվյալների կազմակերպմանը և դասակարգմանը:

Բենջամին Լի Վորֆ (1897-1941)

Համակարգչային հեղափոխության առաջացումը մենք պարտական ​​ենք մեքենային: Հետևաբար, մեր ծրագրավորման լեզուները փորձում են ավելի մոտ լինել այս մեքենային:

Բայց միևնույն ժամանակ, համակարգիչները ոչ այնքան մեխանիզմներ են, որքան մտքի ուժեղացման միջոցներ («հեծանիվներ մտքի համար», ինչպես սիրում է ասել Սթիվ Ջոբսը) և ինքնարտահայտման ևս մեկ միջոց: Արդյունքում, ծրագրավորման գործիքները ավելի քիչ են թեքվում դեպի մեքենաները և ավելի շատ դեպի մեր միտքը, ինչպես նաև մարդկային ձգտումների արտահայտման այլ ձևեր, ինչպիսիք են գրականությունը, նկարչությունը, քանդակը, անիմացիան և կինոն: Օբյեկտ-կողմնորոշված ​​ծրագրավորումը (OOP) համակարգիչը ինքնարտահայտման մեքենայի վերածելու մի մասն է:

Այս գլուխը ձեզ կներկայացնի OOP-ի հիմունքներին՝ ներառյալ ծրագրային ապահովման մշակման հիմնական մեթոդների հայացքը: Այն, և գիրքն ընդհանրապես, ենթադրում է, որ դուք ծրագրավորման փորձ ունեք ընթացակարգային լեզվով, ոչ թե C: Եթե կարծում եք, որ մինչ այս գիրքը կարդալը ձեզ պակասում է ծրագրավորման և C շարահյուսության գիտելիքները, օգտագործեք Thinking in C մուլտիմեդիա սեմինարը: ներբեռնել կայքից

Անցած տարվա մարտին նա դիմել էր խոշոր ընկերության մասնաճյուղ միջազգային ընկերությունՍամարայում (այո։ Մանկուց մեծամտություն ու փառասիրություն եմ ունեցել)։ Այն ժամանակ ես գիտեի html, css, java, javascript (հիմնականներ), pascal, visualbasic6, mysql հարցումներ, php, ընդհանուր գաղափար:c++. Ես ընդհանրապես չգիտեի Java-ն: Նրանք ինձ առաջարկեցին դասավորության դիզայներ աշխատել, բայց ես մերժեցի: Միայն որպես ծրագրավորող: Հետո նրանք ինձ ցուցակ տվեցին.

Bruce Eckel Thinking in Java (2-րդ հրատարակության ռուսերեն թարգմանությունը կամ 4-րդի բնօրինակը - կարդալ երկուսն էլ)
-Steve McConnell - կատարյալ ծածկագիր:
- Չորսի բանդա - Կաղապարի ձևավորում: (սա OOP-ի գրեթե ABC-ն է)
- հնարավորինս պարզ եղեք j2se-ի և j2ee-ի միջև եղած տարբերության մասին:

դեկտեմբերին անհրաժեշտություն առաջացավ. աշխատանք է ստացել Սամարայի փոքրիկ վեբ-ստուդիայում: անմիջապես պարզ դարձավ, որ դրանք խաբեբաներ էին, բայց ցանկացած աշխատանք, որը ես կարող էի ցույց տալ ապագա գործատուներին, անհրաժեշտ էր: չվճարեցին վճարելու համար (թեև բոլոր ականջները խոստումներով էին կերել), բայց ծածկագիրը բերվեց դիզայնի չափանիշներին, և ամենակարևորը սովորեցրին, թե որտեղ փնտրել և ինչ փնտրել սխալների դեպքում, ինչ քիչ. բաները հեշտ է բաց թողնել:

Բացի վերը նշված գրականությունից, ես գնացի ինտուիտային դասընթաց (հիմա հասկանում եմ, որ դա ծիծաղելի է իր ծավալով, բայց սկզբունքորեն այնտեղ հիմքեր կան)

Փետրվարի վերջին ես նորից ներկայացրեցի իմ ռեզյումեն և ստացա հարցազրույցի հրավեր։ Ընդհանուր առմամբ եղել է 6 հարցազրույց և տևել է 1,5 ամիս։ Նրանցից երկուսը անցկացվել են Մոսկվայի հետ տեսահոլովակի միջոցով։ Ամբողջ պատկերը հիշեցնում էր «Արի վաղը» ֆիլմը։ Բայց ի վերջո աշխատանքի առաջարկ ստացա։ Պայմանագիրը կազմվել է կես դրույքով աշխատանքի համար, քանի որ. Ես այդ ժամանակ դիպլոմ չունեի: Անցյալ ամիս ես դիպլոմ ստացա և պայմանագիրը երկարաձգվեց լրիվ դրույքով։

Փափուկ ինժեների ներկայիս պաշտոնը: Աշխատավարձն ավելի քան գոհացուցիչ է։ Երեկ լրիվ դրույքով աշխատանքի անցնելու հետ կապված 30 տոկոսով բարձրացրել են։

Անգամ այդ խարդախի աշխատասենյակում աշխատանքի օրինակներ էին խնդրում։ Ես ներկայացրեցի իմ ֆրիլանսի կատարած աշխատանքը։ Նույնիսկ այլ լեզուներով ստեղծագործությունները միշտ շատ ավելի լավն են, քան ոչ մեկը:

Հ.Գ. ՖԻԶԻԿԱ երկնագույն դիպլոմ: Ես լիովին ինքնուսույց եմ, ուստի ամեն ինչ ձեր ձեռքերում է։ Ես միայն անգլերեն ունեմ դպրոցից անվճար (շաբաթական 7 ժամ): չնայած աշխարհասփյուռ իր շրջագայության ժամանակ մեզ մոտ եկած ամերիկացին նրան լավ չի ճանաչում։ Նրա առոգանության պատճառով կեսը հազիվ հասկացա։ բայց սա այնքան էլ կարևոր չէ իմ բաժնում: բոլոր փաստաթղթերը անգլերեն լեզվով - դուք կսովորեք, նույնիսկ եթե չգիտեիք)))))

Հատուկ շնորհակալություն այս ֆորումին: Ես իրականում սովորել եմ այստեղ- ամեն օր դասավանդում է բոլոր այն թեմաները, որոնք հանդիպում են)

ԾՐԱԳՐԱՎՈՐՆԵՐԻ ԳՐԱԴԱՐԱՆ

Բրյուս Էքել

4-րդ հրատարակություն

(^ PPTER

Մոսկվա - Սանկտ Պետերբուրգ - Նիժնի Նովգորոդ - Վորոնեժ Դոնի Ռոստով - Եկատերինբուրգ - Սամարա - Նովոսիբիրսկ Կիև - Խարկով - Մինսկ

BBK 32.973 2-018.1

Էկել Բ.

E38 Java փիլիսոփայություն. Ծրագրավորողի գրադարան. 4-րդ հրատ. - Սանկտ Պետերբուրգ: Peter, 2009. - 640 e.: ill. - (Սերիա «Ծրագրողների գրադարան»):

ISBN 978-5-388-00003-3

Java-ն չի կարելի հասկանալ՝ նայելով այն միայն որպես որոշ հարակուրեշկիների հավաքածու. անհրաժեշտ է հասկանալ այս լեզվի առաջադրանքները որպես ընդհանրապես ծրագրավորման հատուկ առաջադրանքներ: r3ia-ն գիրք է ծրագրավորման խնդիրների մասին. ինչու են դրանք դարձել խնդիրներ և ինչ մոտեցում է օգտագործում Java-ն դրանք լուծելու համար: Հետևաբար, յուրաքանչյուր գլխում քննարկված լեզվի առանձնահատկությունները անքակտելիորեն կապված են այն բանի հետ, թե ինչպես են դրանք օգտագործվում որոշակի խնդիրներ լուծելու համար:

Այս գիրքը, որը դիմակայել է բնօրինակով բազմաթիվ վերահրատարակությունների, լեզվի խճճվածության խորը և իսկապես փիլիսոփայական ներկայացման շնորհիվ, համարվում է Java ծրագրավորողների լավագույն ձեռնարկներից մեկը:

BBK 32.973.2-018.1 UDC 004.3

Հրատարակչական իրավունքներ, որոնք ձեռք են բերվել Prentice Hall PTR-ի հետ համաձայնությամբ:

Բոլոր իրավունքները պաշտպանված են. Այս գրքի ոչ մի մաս չի կարող վերարտադրվել որևէ ձևով առանց հեղինակային իրավունքի սեփականատերերի գրավոր թույլտվության:

Այս գրքում պարունակվող տեղեկատվությունը ստացվել է այն աղբյուրներից, որոնք հրատարակիչը վստահելի է համարում: Այնուամենայնիվ, հաշվի առնելով հնարավոր մարդկային կամ տեխնիկական սխալները, հրատարակիչը չի կարող երաշխավորել տրամադրված տեղեկատվության բացարձակ ճշգրտությունն ու ամբողջականությունը և պատասխանատվություն չի կրում դրա համար. հնարավոր սխալներկապված գրքի օգտագործման հետ։

ISBN 978-0131872486 © Prentice Hall PTR, 2006 թ.

ISBN 978-5-388-00003-3 © Թարգմանությունը ռուսերեն Պիտեր Պրես ՍՊԸ-ի, 2009 թ.

© Հրատարակություն ռուսերեն, դիզայն՝ Piter Press LLC, 2009 թ

Առաջաբան ..............................13

Java SE5 և SE6..............................14

Երախտագիտություն.................................14

Գլուխ 1 Օբյեկտների ներածություն..............................17

Աբստրակցիայի զարգացումը ...................................18

Օբյեկտն ունի ինտերֆեյս................................20

Հաստատությունը մատուցում է ծառայություններ.................................22

Թաքնված իրականացում..............................23

Իրականացում Վերօգտագործում................................24

Ժառանգություն................................25

Փոխարինելի առարկաներ և պոլիմորֆիզմ.................................29

Միակ արմատային հիերարխիա..............................33

Բեռնարկղեր................................33

Պարամետրացված տեսակները................................35

Օբյեկտների ստեղծումը, օգտագործումը և դրանց կյանքի ժամանակը..................36

Բացառություններ վարելը. Սխալների հետ գործ ունենալը................................38

Զուգահեռ կատարում ..............................38

Java-ն և ինտերնետը................................39

Ամփոփում.................................47

Գլուխ 2 Ամեն ինչ առարկա է...................................48

Բոլոր օբյեկտները պետք է ստեղծվեն բացահայտորեն..............................49

Օբյեկտները երբեք չպետք է ջնջվեն...................................53

Տվյալների նոր տեսակների ստեղծում..........................54

Մեթոդներ, փաստարկներ և վերադարձի արժեքներ.................................56

Java ծրագրի ստեղծում..........................................58

Հիմնաբառը ստատիկ................................60

Մեր առաջին Java ծրագիրը................................61

Մեկնաբանություններ և ներկառուցված փաստաթղթեր...................................64

Ծրագրավորման ոճ ...................................70

Ամփոփում................................70

Գլուխ 3. Օպերատորներ..............................71

Տպման պարզ հրամաններ ..............................71

Java-ի հայտարարություններ..............................72

Բառացիներ...................................82

Java-ին բացակայում է sizeof() ..............................................92

Ռեզյումե..............................100

Գլուխ 4 Կառավարման կառուցվածքները ..................101

Շարահյուսություն foreach..............................105

վերադարձ, ................................107

ընդմիջել և շարունակել................................108

Bad goto հրամանը ...................................109

Ամփոփում.................................115

Գլուխ 5. Նախնականացում և դադարեցում...................116

Կոնստրուկտորների երաշխիքների սկզբնավորումը..................................116

Մեթոդների ծանրաբեռնում................................118

Մաքրում. Վերջնականացում և աղբահանություն ................................130

Դասարանի անդամների սկզբնավորումը..............................137

Կոնստրուկտորի սկզբնավորում .................................140

Զանգվածների սկզբնավորումը..............................146

Ամփոփում..............................151

Գլուխ 6 Մուտքի վերահսկում ..........................152

Փաթեթը որպես գրադարանային մոդուլ................................153

Java մուտքի սպեցիֆիկատորներ..............................159

Ինտերֆեյս և իրականացում..............................163

Դասարանների մուտք ................................164

Ամփոփում.................................167

Գլուխ 7 Դասերի վերօգտագործում..............................169

Կոմպոզիցիայի շարահյուսություն..............................170

Ժառանգական շարահյուսություն..............................172

Պատվիրակություն.................................176

Կազմության և ժառանգության համադրում............................178

Կազմը ընդդեմ ժառանգության ..................................184

պաշտպանված.................................185

Վերև տիպի փոխարկում ......................................186

Վերջնական հիմնաբառ ................................188

Ամփոփում.................................197

Գլուխ 8 Պոլիմորֆիզմ

Կրկին վերափոխման մասին։ . . >................199

Առանձնահատկություններ ................................ 201

Կոնստրուկտորները և պոլիմորֆիզմը..............................208

Վերադարձի տիպի կովարիանս ......................................216

Նախագծում ժառանգությամբ..............................217

Ռեզյումե................................220

Գլուխ 9. Ինտերֆեյսներ...................221

Աբստրակտ դասեր և մեթոդներ......................................221

Ինտերֆեյսներ................................224

Ինտերֆեյսի տարանջատում իրականացումից..............................227

Ժառանգության միջոցով ինտերֆեյսի ընդլայնում ...................233

Ինտերֆեյսերը՝ որպես հարմարվողականության միջոց................................................236

Ներդրված ինտերֆեյսներ..............................239

Ինտերֆեյսեր և գործարաններ..............................242

Ռեզյումե................................244

Գլուխ 10 Ներքին դասեր................................245

Ներքին դասերի ստեղծում..........................245

Հաղորդակցություն արտաքին դասի հետ................................246

.այս և .նոր կոնստրուկցիաները..............................248

Ներքին դասեր և վերափոխում.................249

Անանուն ներքին դասեր................................253

Ներքին դասեր. ինչու՞ ................................ 261

Ժառանգություն ներքին դասերից................................272

Հնարավո՞ր է արդյոք գերակշռել ներքին դասը:................................272

Տեղական ներքին դասեր................................274

Ամփոփում.................................276

Գլուխ 11 Օբյեկտների հավաքածուներ..............................277

Պարամետրացված և տպագրված բեռնարկղեր...................277

Հիմնական հասկացություններ.................................280

Տարրերի խմբերի ավելացում..............................281

Ցուցակ.................................285

Իտերատորներ..............................288

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

Դույլ................................292

Շատերը ................................................ 294

Քարտեզ................................296

Հերթ.................................298

Առաջնահերթ հերթ..............................299

Հավաքածու և Իտերատոր................................301

Իդիոմ «մեթոդ-ադապտեր» ......................306

Ռեզյումե................................309

Գլուխ 12 Սխալների և բացառությունների կառավարում...................310

Խոշոր բացառություններ.................................310

Բացառություններ բռնելու համար................................312

Ստեղծելով ձեր սեփական բացառությունները................................314

Բացառություն Տեխնիկական ..............................319

Բռնում կամայական բացառություններ..............................320

Ստանդարտ Java բացառություններ ................................328

Ավարտվում է վերջապես.................330-ով

Օգտագործելով վերջապես վերադարձի հետ..........................334

Բացառությունների կիրառման սահմանափակումներ..............................336

Կոնստրուկտորներ..............................339

Բացառությունների բացահայտում..............................343

Այլընտրանքային լուծումներ..............................344

Ամփոփում.................................351

Գլուխ 13 Տիպի Տեղեկություն.................................352

Անհրաժեշտ է դինամիկ տիպի եզրակացություն (RTTI) .........352

Գործարանային գրանցում ................................372

Արտացոլում՝ դինամիկ տեղեկատվություն դասի մասին..............................376

Դինամիկ միջնորդներ..............................380

Անորոշ վիճակով առարկաներ................................384

Ինտերֆեյսներ և տիպի տեղեկատվություն................................390

Ռեզյումե..............................394

Գլուխ 14

Պարզ պարամետրիզացիա.................................398

Պարամետրացված ինտերֆեյսներ..............................404

Պարամետրացված մեթոդներ...................407

Շենքերի համալիրի մոդելներ..............................419

Սահմանափակումներ..............................437

Մետանիշեր.................................440

Ռեզյումե..............................452

Գլուխ 15. Զանգվածներ..............................454

Զանգվածի առանձնահատկությունները..............................454

Զանգվածը որպես օբյեկտ..............................456

Զանգվածի վերադարձ ..............................458

Բազմաչափ զանգվածներ..............................460

Զանգվածներ և պարամետրիզացիա..............................463

Թեստային տվյալների ստեղծում..............................465

Զանգվածների ստեղծում՝ օգտագործելով գեներատորներ................................470

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

Ռեզյումե..............................482

Գլուխ 16 Java I/O համակարգը..............................483

Ֆայլի դաս.................................484

Մուտք և ելք..............................489

Հատկանիշների և միջերեսների ավելացում..............................491

Ընթերցողի և գրողի դասարաններ..............................494

RandomAccessFile՝ ինքնին...................497

I/O հոսքերի տիպիկ օգտագործումը..............................498

Ֆայլերի ընթերցողներ և գրողներ......................................505

Ես, հավանաբար, չեմ սխալվում՝ ենթադրելով, որ Java սովորողների մեծ մասը սկսել է դա անել Բրյուս Էքելի հայտնի գրքի օգնությամբ. «Մտածում Java-ում», ռուսերեն հրատարակությամբ հայտնի է որպես «Ջավայի փիլիսոփայություն». Ցավոք ներս էլեկտրոնային ձևաչափով(ռուսերեն) այս գրքի 2-րդ հրատարակությունն ամենաշատ տարածվածն է՝ հիմնված Java 1.1 տարբերակի վրա, որը վաղուց կորցրել է իր արդիականությունը: Java-ի հաջորդ տարբերակներում (և հատկապես Java SE5-ում) հայտնված նորամուծությունները շատ նշանակալից էին, ինչը հանգեցրեց գրքի լուրջ վերանայմանը չորրորդ հրատարակության մեջ (որի թարգմանությունը լույս է տեսել ռուսերեն): Այնուամենայնիվ, հեշտ ընթեռնելի (և ամենակարևորը` արագ որոնման համար) էլեկտրոնային ձևաչափով այս հրապարակման ռուսերեն տարբերակը գոյություն չուներ: Ուստի որոշեցի լրացնել այս բացը և արտադրել այս հանրաճանաչ գրքի ամբողջական տարբերակը «վիքիգրքի» ձևաչափով։ Կարծում եմ, որ այս տեղեկատվությունը հետաքրքիր և օգտակար կլինի ոչ միայն լեզու սովորողների համար, այլև բոլոր նրանց համար, ովքեր աշխատում են Java-ում, քանի որ այս լեզվով ծրագրավորման գրեթե բոլոր ասպեկտները պատկերող հիանալի օրինակներ են: Հատկապես, երբ խոսքը վերաբերում է հազվադեպ օգտագործվող Java հնարավորություններին:

վիքիգիրք «Ջավայի փիլիսոփայություն»փակցված՝

«Գարունը գործողության մեջ»

Գրքեր շարքից «Գործողության մեջ»(սովորաբար PDF ձևաչափով և սովորաբար անգլերենով) արժանիորեն հայտնի են որոշակի շրջանակներում :) Դրանց թվում կան նաև տարողունակ թալմուդներ, ինչպիսիք են. «JSTL in Action»(հեշտությամբ ընթեռնելի և անգլերենի չափավոր իմացությամբ, բայց հարմար է թեմայի վերաբերյալ լավ հղումի դերի համար) և ավելի համեստ արհեստներ, ինչպիսիք են. Struts in Action(«Ամեն ինչ չէ, որ ոսկի է...»): Գիրք «Գարունը գործողության մեջ»այս ցուցակում դեռևս «ծանր քաշայինների» կատեգորիայից է և բառիս բոլոր իմաստով։ Այն կարդալն առանց սահուն անգլերենի, հավանաբար, հեշտ չէ: Եվ խոսքը ոչ թե ներկայացված նյութի բարդության մեջ է (դա բարդ չէ), այլ այն, որ պարզվեց՝ չափից դուրս «անգլիական-գեղարվեստական», կամ ինչ-որ բան… Լիրիկական շեղումներով, թեւավոր արտահայտություններով, բառախաղերով և այլ բլա բլա բլա, լեզվի հեղինակներ, այս ուղեցույցի ընթերցումը (բնօրինակ լեզվով) արագ վերածում են հոգնեցուցիչ գործընթացի: Բայց մյուս կողմից դա թույլ է տալիս իմանալ, որ բառը «նկարել»(սովորաբար՝ «քաշել») կարող է օգտագործվել «քաղվածքից» իմաստով (լիտ.՝ «քաշել, քաշել»)։ Արդյունքում (հաշվի առնելով գրքում ընդունված մատուցման ընդհանուր ոճը) հասկանալ ճշգրիտ իմաստարտահայտություններ, ինչպիսիք են. «...գարնանային նկարեք այս տվյալները...»:, դա տեղի է ունենում միաժամանակ, և դա հեշտ չէ, և դա չափազանց անհրաժեշտ է։ Հետևաբար, այն գլուխների ընթերցողները, որոնք ես չեմ թարգմանել, իրենք պետք է որոշեն, թե ինչ են ցանկացել հեղինակները նման դեպքերում՝ բանաստեղծորեն արտահայտվել ֆայլի ստեղծման (ձայնագրության) մասին, թե՞ զվարճալի պատմել այն կարդալու մասին:

Այս գիրքը իմ կողմից PDF-ից վերածվել է վիքիգրքի՝ որպես իմ անձնական օգտագործման էքսպրես հղում: Հետևաբար, թարգմանությունը ամբողջական չէ, այլ միայն այն վայրերում, որոնց համար բավական ոգևորություն կար։ Մնացած գլուխները պարզապես տրվել են արագ որոնման համար հարմար ձևով։ Հրատարակվում է, ԱՄԵՆ ԻՆՉ «ինչպես կա», և չպետք է մեղադրել ռուսերեն տեքստի որակին... Ես պրոֆեսիոնալ թարգմանիչ չեմ, և գրական խմբագիր չեմ ունեցել։ Թերևս ինչ-որ մեկին հիասթափեցնեմ այն ​​փաստով, որ ես չեմ թարգմանել գրքի որոշ տեղեր և գլուխներ (և չեմ էլ նախատեսում թարգմանել), այլ անհրաժեշտ էր պահուստ թողնել ապագա սերունդների համար.

վիքիգիրք "Գարունը գործողության մեջ " փակցված՝

ՕԲՅԵԿՏՆԵՐԻ ՆԵՐԱԾՈՒԹՅՈՒՆ

Համակարգչային հեղափոխության առաջացումը մենք պարտական ​​ենք մեքենային: Հետևաբար, մեր ծրագրավորման լեզուները փորձում են ավելի մոտ լինել այս մեքենային:

Բայց միևնույն ժամանակ, համակարգիչները ոչ այնքան մեխանիզմներ են, որքան միտքը ուժեղացնելու միջոցներ («հեծանիվներ մտքի համար», ինչպես սիրում էր ասել Սթիվ Ջոբսը) և ինքնարտահայտման ևս մեկ միջոց։ Արդյունքում, ծրագրավորման գործիքները ավելի քիչ են թեքվում դեպի մեքենաները և ավելի շատ դեպի մեր միտքը, ինչպես նաև մարդկային ձգտումների արտահայտման այլ ձևեր, ինչպիսիք են գրականությունը, նկարչությունը, քանդակը, անիմացիան և կինոն: Օբյեկտ-կողմնորոշված ​​ծրագրավորումը (OOP) համակարգիչը ինքնարտահայտման միջոցի վերածելու մի մասն է:

Այս գլուխը ձեզ կներկայացնի OOP-ի հիմունքներին, ներառյալ ծրագրավորման հիմնական տեխնիկան: Այն, և գիրքն ընդհանրապես, ենթադրում է, որ դուք ծրագրավորման փորձ ունեք ընթացակարգային լեզվով, պարտադիր չէ, որ Գ.

Այս գլուխը պարունակում է նախապատրաստական ​​և լրացուցիչ նյութեր. Շատ ընթերցողներ նախընտրում են նախ պատկերացնել մեծ պատկերը և միայն դրանից հետո հասկանալ OOP-ի բարդությունները: Հետևաբար, այս գլխի գաղափարներից շատերը ծառայում են ձեզ OOP-ի հիմնավոր ըմբռնմանը: Այնուամենայնիվ, շատ մարդիկ չեն ըմբռնում ընդհանուր գաղափարը, մինչև չտեսնեն, թե կոնկրետ ինչպես են աշխատում: նման մարդիկ հաճախ են խրվում ընդհանուր տերմիններով՝ առանց իրենց առջև օրինակներ ունենալու։ Եթե ​​դուք վերջիններից մեկն եք և ցանկանում եք սկսել լեզվի հիմունքները, կարող եք առաջ անցնել հաջորդ գլխին. այս մեկը բաց թողնելը խոչընդոտ չի լինի ծրագրեր գրելու կամ լեզուն սովորելու համար: Այնուամենայնիվ, դուք պետք է ավելի ուշ վերադառնաք այս գլխին, որպեսզի ընդլայնեք ձեր հորիզոնները և հասկանաք, թե ինչու են օբյեկտներն այդքան կարևոր և որտեղ են դրանք տեղավորվում ծրագրի ձևավորման մեջ:

Աբստրակցիայի զարգացում

Ծրագրավորման բոլոր լեզուները կառուցված են աբստրակցիայի վրա: Թերևս լուծվելիք առաջադրանքների դժվարությունն ուղղակիորեն կախված է աբստրակցիայի տեսակից և որակից։ «Տիպ» ասելով նկատի ունեմ. «Կոնկրետ ի՞նչ ենք վերացականում»։ Ասամբլեայի լեզուն փոքր աբստրակցիա է այն համակարգչից, որի վրա այն աշխատում է: Նրանից հետո ստեղծված բազմաթիվ այսպես կոչված «հրամանատար» լեզուներ (օրինակ Fortran, ՀԻՄՆԱԿԱՆև Գ) հաջորդ մակարդակի աբստրակցիաներ էին: Այս լեզուները զգալի առավելություն ունեին անսամբլի լեզվի նկատմամբ, բայց դրանց հիմնական աբստրակցիան դեռ ստիպում է մտածել համակարգչի կառուցվածքի մասին, այլ ոչ թե լուծվող խնդրի մասին: Ծրագրավորողը պետք է հարաբերություններ հաստատի մեքենայի մոդելի («լուծման տարածությունում», որը ներկայացնում է այն վայրը, որտեղ լուծումն իրականացվում է, օրինակ՝ համակարգիչ) և լուծվող խնդրի մոդելի միջև («խնդրի տարածությունում» , որն այն տեղն է, որտեղ առկա է խնդիրը, օրինակ՝ կիրառական տարածք): Կապի հաստատումը պահանջում է ջանք, որը կտրված է իրական ծրագրավորման լեզվից. արդյունքը ծրագրեր են, որոնք դժվար է գրել և դժվար պահպանել: Ոչ միայն դա, այլեւ ստեղծեց «ծրագրավորման մեթոդոլոգիաների» մի ամբողջ արդյունաբերություն։

Մեքենայի մոդելավորման այլընտրանքը լուծվող խնդրի մոդելավորումն է: Վաղ լեզուները նման են LISPև ԱՊԼ, ընտրել է շրջապատող աշխարհի մոդելավորման հատուկ մոտեցում (համապատասխանաբար «Բոլոր խնդիրները լուծվում են ցուցակներով» կամ «Ալգորիթմները լուծում են ամեն ինչ»): ՊՐՈԼՈԳբոլոր խնդիրները վերաբերվում են որպես լուծումների շղթա: Լեզուները ստեղծվել են ծրագրավորման համար՝ հիմնված սահմանափակումների համակարգի վրա, և հատուկ լեզուներ, որոնցում ծրագրավորումն իրականացվել է գրաֆիկական կառուցվածքների մանիպուլյացիայի միջոցով (վերջինիս շրջանակը չափազանց նեղ է ստացվել): Այս մոտեցումներից յուրաքանչյուրը լավ է լուծվող խնդիրների որոշակի ոլորտում, բայց երբ հեռանում եք այս տարածքից, դժվար է դառնում դրանք օգտագործելը:

Օբյեկտային մոտեցումը մի քայլ առաջ է գնում՝ ծրագրավորողին տրամադրելով միջոց՝ առաջադրանքն իր տարածքում ներկայացնելու համար: Այս մոտեցումը բավականին ընդհանուր է և սահմանափակումներ չի դնում լուծվող խնդրի տեսակի վրա։ Խնդրի տարածության տարրերը և դրանց ներկայացումները լուծման տարածության մեջ կոչվում են «օբյեկտներ»: (Ձեզ հավանաբար անհրաժեշտ կլինեն այլ օբյեկտներ, որոնք չունեն անալոգներ խնդրի տարածքում:) Գաղափարն այն է, որ ծրագիրը կարող է հարմարվել խնդրի առանձնահատկություններին՝ ստեղծելով նոր տեսակի օբյեկտներ, որպեսզի խնդիրը լուծող կոդը կարդալիս դուք միաժամանակ տես բառերը, որոնք նկարագրում են նրան: Սա ավելի ճկուն և հզոր աբստրակցիա է, որն իր հնարավորություններով գերազանցում է այն ամենին, ինչ նախկինում կար։ Լեզուների որոշ դիզայներներ կարծում են, որ օբյեկտի վրա հիմնված ծրագրավորումն ինքնին բավարար չէ ծրագրավորման բոլոր խնդիրները լուծելու համար, և պաշտպանում են ծրագրավորման տարբեր պարադիգմների համադրություն մեկ լեզվում: Այդպիսի լեզուներ են կոչվում բազմակողմանի պարադիգմ(բազմապարադիգմներ): Տե՛ս Թիմոթի Բադդի «Մուլտիպարադիգմային ծրագրավորում» գիրքը Լեդայում (Ադիսոն-Ուեսլի, 1995):. Այսպիսով, OOP-ը թույլ է տալիս նկարագրել առաջադրանքը հենց առաջադրանքի համատեքստում, այլ ոչ թե այն համակարգչի համատեքստում, որի վրա լուծումը կկատարվի: Սակայն համակարգչի հետ կապը դեռ պահպանվում է։ Յուրաքանչյուր առարկա նման է փոքր համակարգչի. այն ունի վիճակ և գործառնություններ, որոնք թույլ է տալիս: Նման անալոգիան լավ է համապատասխանում արտաքին աշխարհին, որը «իրականություն է, որը մեզ տրված է առարկաների մեջ», որոնք ունեն առանձնահատկություններ և վարքագիծ:

Ալան Քեյն ամփոփել և եզրակացրել է լեզվի հինգ հիմնական հատկանիշները Կարճ խոսակցություն- առաջին հաջողակ օբյեկտ-կողմնորոշված ​​լեզուն, նախորդներից մեկը Java. Այս բնութագրերը ներկայացնում են օբյեկտի վրա հիմնված ծրագրավորման «մաքուր» ակադեմիական մոտեցում.

• Ամեն ինչ օբյեկտ է։ Մտածեք օբյեկտը որպես ճշգրտված փոփոխական; այն պահում է տվյալներ, բայց դուք կարող եք «հարցել» օբյեկտին, խնդրելով, որ նա գործողություններ կատարի իր վրա: Տեսականորեն լուծվող խնդրի բացարձակապես ցանկացած բաղադրիչ (շուն, շենք, ծառայություն և այլն) կարող է ներկայացվել որպես օբյեկտ։

• Ծրագիրը օբյեկտների խումբ է, որոնք միմյանց ասում են, թե ինչ անել հաղորդագրությունների միջոցով: Օբյեկտին հարցում անելու համար դուք «այն հաղորդագրություն եք ուղարկում»։ Ավելի տեսողականորեն, հաղորդագրությունը կարող է ներկայացվել որպես որոշակի օբյեկտին պատկանող մեթոդի կոչ:

• Յուրաքանչյուր առարկա ունի իր «հիշողությունը»՝ բաղկացած այլ առարկաներից։ Այսինքն՝ դու ստեղծագործում ես նոր օբյեկտգոյություն ունեցող օբյեկտների մեջ ներդնելով: Այսպիսով, հնարավոր է կառուցել կամայականորեն բարդ ծրագիր՝ թաքցնելով ընդհանուր բարդությունը առանձին օբյեկտների պարզության հետևում:

• Յուրաքանչյուր առարկա ունի իր տեսակը. Այլ կերպ ասած, յուրաքանչյուր օբյեկտ դասի օրինակ է, որտեղ «class»-ը «type» բառի համարժեքն է։ Դասերի միջև ամենակարևոր տարբերությունը հենց այն հարցի պատասխանն է. «Ի՞նչ հաղորդագրություններ կարելի է ուղարկել օբյեկտին»:

• Որոշակի տեսակի բոլոր օբյեկտները կարող են ստանալ նույն հաղորդագրությունները: Ինչպես շուտով կտեսնենք, սա շատ կարևոր հանգամանք է։ Քանի որ «շրջանակ» տիպի օբյեկտը նաև «ձևի» տիպի օբյեկտ է, ապա ճիշտ է, որ «շրջանակը», անշուշտ, կարող է հաղորդագրություններ ստանալ «ձևի» համար։ Եվ սա նշանակում է, որ դուք կարող եք գրել կոդ ձևերի համար և վստահ լինել, որ այն կաշխատի այն ամենի համար, ինչ վերաբերում է ձևի հասկացությանը: Փոխարինելիությունը OOP-ի ամենահզոր հասկացություններից մեկն է:

Բուչն առաջարկեց օբյեկտի էլ ավելի հակիրճ նկարագրություն.

Օբյեկտն ունի վիճակ, վարքագիծ և անհատականություն.

Եզրակացությունն այն է, որ օբյեկտը կարող է ունենալ ներքին տվյալներ (որը օբյեկտի վիճակն է), մեթոդներ (որոնք սահմանում են վարքագիծը), և յուրաքանչյուր օբյեկտ կարող է եզակիորեն տարբերվել ցանկացած այլ օբյեկտից. ավելի կոնկրետ, յուրաքանչյուր օբյեկտ ունի եզակի հասցե: միտք Սա ճշմարիտ է որոշ սահմանափակումներով, քանի որ օբյեկտները կարող են իրականում գոյություն ունենալ այլ մեքենաներում և հասցեների տարբեր տարածություններում, ինչպես նաև կարող են պահվել սկավառակի վրա: Այս դեպքերում օբյեկտի ինքնությունը պետք է որոշվի հիշողության հասցեից բացի այլ բանով:.

Օբյեկտն ունի ինտերֆեյս

Հավանական է, որ Արիստոտելն առաջինն էր, ով ուշադիր ուսումնասիրեց տիպի հասկացությունը. նա խոսեց «ձկների և թռչունների դասի» մասին։ Հայեցակարգը, որ բոլոր օբյեկտները, թեև եզակի են, միևնույն ժամանակ նմանատիպ բնութագրերով և վարքագիծ ունեցող օբյեկտների դասի մաս են կազմում, օգտագործվել է առաջին օբյեկտի վրա հիմնված լեզվում՝ Simula-67-ում, հիմնարար բանալի բառի ներդրմամբ։ դաս , որը նոր տեսակ ներմուծեց ծրագրում։

Լեզու Սիմուլա, ինչպես ենթադրում է նրա անվանումը, ստեղծվել է դասական «բանկի գանձապահի» խնդրին նման իրավիճակներ մշակելու և մոդելավորելու համար: Դուք ունեք գանձապահների, հաճախորդների, հաշիվների, վճարումների և արժույթների խմբեր՝ շատ «օբյեկտներ»: Օբյեկտները, որոնք բոլորովին նույնական են, բացառությամբ ներքին վիճակում, մինչ ծրագիրը աշխատում է, խմբավորվում են «օբյեկտների դասերի»: Այստեղից եկավ հիմնաբառ դաս . Վերացական տվյալների տիպերի ստեղծումը հիմնարար հայեցակարգ է բոլոր օբյեկտի վրա հիմնված ծրագրավորման մեջ: Վերացական տվյալների տեսակները գործում են գրեթե նույն կերպ, ինչ ներկառուցված տեսակները. դուք կարող եք ստեղծել տիպի փոփոխականներ (կոչվում են օբյեկտներ կամ օրինակներ OOP տերմիններով) և մանիպուլյացիայի ենթարկել դրանք (կոչվում է հաղորդագրություն կամ հարցում, դուք հարցում եք անում, և օբյեկտը որոշում է, թե ինչ անել: այն.): Յուրաքանչյուր դասի անդամները (տարրերը) ունեն նմանություններ. յուրաքանչյուր հաշիվ ունի մնացորդ, յուրաքանչյուր գանձապահ ընդունում է ավանդներ և այլն: Միևնույն ժամանակ, բոլոր անդամները տարբերվում են իրենց ներքին վիճակով. յուրաքանչյուր հաշիվ ունի անհատական ​​մնացորդ, յուրաքանչյուր գանձապահ ունի մարդու անուն: Հետևաբար, բոլոր գանձապահները, հաճախորդները, հաշիվները, փոխանցումները և այլն կարող են ներկայացված լինել ներսում գտնվող եզակի սուբյեկտներով համակարգչային ծրագիր. Սա օբյեկտի էությունն է, և յուրաքանչյուր օբյեկտ պատկանում է որոշակի դասի, որը սահմանում է նրա բնութագրերն ու վարքը:

Այսպիսով, մինչ մենք ստեղծում ենք տվյալների նոր տեսակներ օբյեկտների լեզուներով, գործնականում այս բոլոր լեզուներն օգտագործում են «դաս» հիմնաբառը: Երբ տեսնում եք «տեսակ» բառը, մտածեք «դաս», և հակառակը Որոշ մարդիկ տարբերակում են երկուսը` նշելով, որ տեսակը սահմանում է ինտերֆեյսը, մինչդեռ դասը ինտերֆեյսի կոնկրետ իրականացումն է:.

Քանի որ դասը սահմանում է նույնական հատկանիշներով (տվյալների անդամներ) և վարքագծի (ֆունկցիոնալություն) ունեցող օբյեկտների մի շարք, դասը իրականում տվյալների տեսակ է, քանի որ, օրինակ, լողացող կետի համարն ունի նաև մի շարք բնութագրեր և վարքագիծ: Տարբերությունն այն է, որ ծրագրավորողը սահմանում է դաս՝ առաջադրանքի որոշ ասպեկտ ներկայացնելու համար, փոխարենը օգտագործելու արդեն գոյություն ունեցող տեսակ, որը ներկայացնում է մեքենայում տվյալների պահպանման միավորը: Դուք ընդլայնում եք ծրագրավորման լեզուն՝ ավելացնելով նոր տվյալների տեսակներ՝ ձեր կարիքներին համապատասխան: Ծրագրավորման համակարգը նպաստում է նոր դասերի և նրանց տալիս է ճիշտ նույն ուշադրությունը, ինչ ներկառուցված տեսակները:

Օբյեկտ-կողմնորոշված ​​մոտեցումը չի սահմանափակվում միայն մոդելների կառուցմամբ: Անկախ նրանից, թե համաձայն եք, թե ոչ, որ որևէ ծրագիր ձեր մշակած համակարգի մոդելն է, OOP տեխնոլոգիայի օգտագործումը հեշտությամբ նվազեցնում է խնդիրների մեծ շարքը՝ դարձնելով պարզ լուծում:

Երբ նոր դասը սահմանվի, դուք կարող եք ստեղծել այդ դասի ցանկացած թվով օբյեկտներ, այնուհետև դրանք շահարկել այնպես, կարծես դրանք առկա խնդրի մի մասն են: Իրականում, OOP-ի հիմնական դժվարություններից մեկը խնդրի տարածքում գտնվող օբյեկտների և լուծման տարածության օբյեկտների միջև մեկ առ մեկ համապատասխանություն հաստատելն է:

Բայց ինչպե՞ս եք ստիպել օբյեկտին անել այն, ինչ ուզում եք: Պետք է լինի մեխանիզմ՝ օբյեկտին հարցում ուղարկելու համար՝ ինչ-որ գործողություն կատարելու համար՝ գործարքի ավարտ, էկրանին նկարում և այլն: Յուրաքանչյուր օբյեկտ կարող է կատարել միայն հարցումների որոշակի շրջանակ: Հարցումները, որոնք կարող եք ուղարկել օբյեկտին, որոշվում են նրա միջերեսով, իսկ օբյեկտի ինտերֆեյսը որոշվում է նրա տեսակով: Ամենապարզ օրինակը կլինի էլեկտրական լամպը.

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

Ինտերֆեյսը սահմանում է, թե ինչ հարցումներ կարող եք կատարել կոնկրետ օբյեկտին: Այնուամենայնիվ, այն կոդը, որն իրականացնում է հարցումները, նույնպես պետք է ինչ-որ տեղ գոյություն ունենա: Այս կոդը, թաքնված տվյալների հետ միասին, կազմում է իրականացումը: Ընթացակարգային ծրագրավորման տեսանկյունից այն, ինչ տեղի է ունենում, այնքան էլ դժվար չէ։ Տեսակը պարունակում է մեթոդ յուրաքանչյուր հնարավոր հարցման համար, և երբ կոնկրետ հարցում է ստացվում, կանչվում է համապատասխան մեթոդ: Գործընթացը սովորաբար զուգակցվում է մեկի մեջ՝ «հաղորդագրություն ուղարկելը» (հարցը փոխանցելը) օբյեկտին և այն մշակել օբյեկտի կողմից (կոդը կատարող):

Այս օրինակում կա մի տեսակ (դաս) անունով լույս (լամպ), տեսակի կոնկրետ օբյեկտ լույս Անունով Այն , և դասը աջակցում է տարբեր օբյեկտների հարցումներ լույս Անջատեք լամպը, միացրեք այն, դարձրեք ավելի պայծառ կամ խամրեցրեք այն: Դուք ստեղծում եք օբյեկտ լույս , սահմանելով դրան «հղում» ( Այն ) և զանգահարել օպերատորին նոր ստեղծել այդ տեսակի նոր օրինակ: Օբյեկտին հաղորդագրություն ուղարկելու համար դուք պետք է նշեք օբյեկտի անունը և այն կապեք ցանկալի հարցման հետ կետով: Նախապես սահմանված դասի օգտագործողի տեսանկյունից դա բավական է իր օբյեկտների վրա գործելու համար:

Վերևում ներկայացված աղյուսակը հետևում է ձևաչափին UML (Մոդելավորման միասնական լեզու). Յուրաքանչյուր դաս ներկայացված է ուղղանկյունով, բոլոր նկարագրված տվյալների դաշտերը տեղադրվում են դրա միջին մասում, իսկ մեթոդները (օբյեկտի գործառույթները, որին ուղարկում եք հաղորդագրություններ) նշված են ուղղանկյան ներքևի մասում:

Հաճախ գծապատկերներում UMLցուցադրվում են միայն դասի անվանումը և հանրային մեթոդները, իսկ միջին մասը բացակայում է: Եթե ​​ձեզ հետաքրքրում է միայն դասի անվանումը, կարող եք բաց թողնել նաև ներքևի մասը։

Հաստատությունը մատուցում է ծառայություններ

Երբ փորձում եք նախագծել կամ հասկանալ ծրագրի կառուցվածքը, հաճախ օգտակար է պատկերացնել օբյեկտները որպես «ծառայություններ մատակարարողներ»: Ձեր ծրագիրը ծառայություններ է մատուցում օգտվողին, և դա անում է այլ օբյեկտների կողմից տրամադրվող ծառայությունների միջոցով: Ձեր նպատակն է արտադրել (կամ ավելի լավ՝ դասարանների գրադարաններում գտնել) օբյեկտների մի շարք, որոնք օպտիմալ կլինեն ձեր խնդիրը լուծելու համար:

Սկսելու համար, հարցրեք ինքներդ ձեզ. «Եթե ես կարողանայի կախարդական կերպով հեռացնել առարկաները գլխարկից, ո՞րը կկարողանայի լուծել իմ խնդիրը հենց հիմա»: Ենթադրենք, դուք հաշվապահական ծրագիր եք մշակում: Կարելի է պատկերացնել մի շարք օբյեկտներ, որոնք ապահովում են ստանդարտ պատուհաններ հաշվապահական տեղեկատվության մուտքագրման համար, օբյեկտների մեկ այլ խումբ, որոնք կատարում են հաշվապահական հաշվարկներ, օբյեկտ, որը տպում է չեկեր և հաշիվ-ապրանքագրեր տարբեր տպիչների վրա: Միգուցե այդ օբյեկտներից մի քանիսն արդեն գոյություն ունեն, իսկ մյուս օբյեկտների համար արժե պարզել, թե ինչպիսի տեսք կարող են ունենալ դրանք: Ի՞նչ ծառայություններ կարող են մատուցել այդ հաստատությունները, և ի՞նչ հնարավորություններ պետք է ունենան իրենց աշխատանքը կատարելու համար: Եթե ​​այսպես շարունակես, վաղ թե ուշ կասես՝ «Այս առարկան այնքան պարզ է, որ մենք կարող ենք նստել և գրել այն», կամ «Իհարկե, այդպիսի օբյեկտ արդեն գոյություն ունի»։ Սա խնդրի լուծումը առանձին օբյեկտների վրա բաշխելու ողջամիտ միջոց է։

Օբյեկտը որպես ծառայություն մատուցող ներկայացնելը ունի ավելացված օգուտԱյն օգնում է բարելավել կապը ( համախմբվածություն) օբյեկտ. Լավ կապ - էական որակ ծրագրային արտադրանքդա նշանակում է, որ ծրագրային բաղադրիչի տարբեր ասպեկտները (օրինակ՝ օբյեկտը, թեև այն կարող է նաև վերաբերել մեթոդին կամ օբյեկտների գրադարանին) լավ տեղավորվում են: Մեկը ընդհանուր սխալներթույլատրվում է օբյեկտի նախագծման ժամանակ այն գերհագեցնելը մեծ թվով հատկություններով և հնարավորություններով: Օրինակ, չեկեր տպող մոդուլ մշակելիս կարող եք ցանկանալ, որ այն «իմանա» ամեն ինչ ֆորմատավորման և տպագրության մասին:

Եթե ​​մտածեք դրա մասին, ամենայն հավանականությամբ, կգաք այն եզրակացության, որ սա շատ է մեկ օբյեկտի համար, և դուք կգնաք երեք կամ ավելի օբյեկտների: Մեկ օբյեկտը կլինի ստուգումների բոլոր հնարավոր ձևերի կատալոգը և կարող է հարցվել, թե ինչպես պետք է տպագրվի չեկը: Մեկ այլ օբյեկտ կամ օբյեկտների հավաքածու պատասխանատու կլինի ընդհանրացված տպագրական ինտերֆեյսի համար, որը «գիտի» ամեն ինչ տարբեր տեսակի տպիչների մասին (բայց հաշվապահական հաշվառման մեջ ոչինչ չի «հասկանում». ավելի լավ է նման առարկա գնել, քան ինքներդ մշակել): Վերջապես, երրորդ օբյեկտը պարզապես կօգտագործի նկարագրված օբյեկտների ծառայությունները՝ առաջադրանքը կատարելու համար։ Այսպիսով, յուրաքանչյուր օբյեկտ իրենից ներկայացնում է միացված ծառայությունների մի շարք, որն առաջարկում է: Լավ պլանավորված օբյեկտի վրա հիմնված նախագծում յուրաքանչյուր օբյեկտ լավ է կատարում մեկ կոնկրետ առաջադրանք՝ չփորձելով անել ավելին, քան անհրաժեշտ է: Ինչպես ցույց է տրված, սա ոչ միայն թույլ է տալիս որոշել, թե որ առարկաները պետք է գնել (տպագիր ինտերֆեյսով օբյեկտ), այլև թույլ է տալիս հայտնվել այնպիսի օբյեկտի հետ, որը կարող է օգտագործվել այլ տեղ (անդորրագրի կատալոգ):

Օբյեկտները որպես ծառայություններ մատուցող ներկայացնելը մեծապես հեշտացնում է խնդիրը: Այն օգտակար է ոչ միայն մշակման ընթացքում, այլ նաև, երբ ինչ-որ մեկը փորձում է հասկանալ ձեր կոդը կամ նորից օգտագործել օբյեկտը, ապա նա կկարողանա պատշաճ կերպով գնահատել օբյեկտը մատուցվող ծառայության մակարդակի համար, և դա մեծապես կհեշտացնի վերջինիս ինտեգրումը: մեկ այլ նախագիծ.

Թաքնված իրականացում

Օգտակար է ծրագրավորողներին բաժանել դասի ստեղծողներ(նրանք, ովքեր ստեղծում են տվյալների նոր տեսակներ) և հաճախորդ ծրագրավորողներԵս երախտապարտ եմ այս ժամկետի համար իմ ընկեր Սքոթ Մեյերսին:(դասերի սպառողներ, որոնք օգտագործում են տվյալների տեսակներ իրենց հավելվածներում): Երկրորդի նպատակն է հնարավորինս շատ դասարաններ հավաքել՝ ծրագրերի արագ մշակմամբ զբաղվելու համար։ Դասերի ստեղծողի նպատակն է կառուցել դաս, որը բացահայտում է միայն այն, ինչ կարիք ունի հաճախորդ ծրագրավորողի և թաքցնում մնացած ամեն ինչ: Ինչո՞ւ։ Հաճախորդ ծրագրավորողը չի կարողանա մուտք գործել թաքնված մասեր, ինչը նշանակում է, որ դասերի ստեղծողը հնարավորություն է վերապահում դրանք կամայականորեն փոխել՝ չվախենալով, որ դա ինչ-որ մեկին կվնասի: «Թաքնված» մասը սովորաբար օբյեկտի «ամենափխրուն» մասն է, որը կարող է հեշտությամբ փչանալ անփույթ կամ անգրագետ հաճախորդի ծրագրավորողի կողմից, ուստի իրականացումը թաքցնելը նվազեցնում է ծրագրերի սխալների քանակը:

Ցանկացած հարաբերություններում կարևոր է ունենալ որոշ սահմաններ, որոնք չեն անցնում մասնակիցներից որևէ մեկի կողմից: Ստեղծելով գրադարան՝ դուք հարաբերություններ եք հաստատում հաճախորդի ծրագրավորողի հետ: Նա ծրագրավորող է ճիշտ այնպես, ինչպես դուք, բայց կօգտագործի ձեր գրադարանը հավելված ստեղծելու համար (և գուցե ավելի բարձր մակարդակի գրադարան): Եթե ​​դասի բոլոր անդամներին մուտք եք տալիս որևէ մեկին, հաճախորդ ծրագրավորողը կարող է անել այն, ինչ ցանկանում է դասի հետ, և ոչ մի կերպ չեք կարող ստիպել նրան «խաղալ կանոններով»: Նույնիսկ եթե հետագայում ձեզ անհրաժեշտ է սահմանափակել մուտքը ձեր դասի որոշ անդամների, դա հնարավոր չէ անել առանց մուտքի վերահսկման մեխանիզմի: Դասի ամբողջ կառուցվածքը բաց է բոլոր այցելուների համար։

Այսպիսով, մուտքի սահմանափակման առաջին պատճառը հաճախորդի ծրագրավորողից «փխրուն» մանրամասները պաշտպանելու անհրաժեշտությունն է՝ ներքին «խոհանոցի» մասերը, որոնք ինտերֆեյսի մաս չեն, որոնցով օգտատերերը լուծում են իրենց խնդիրները: Իրականում սա նաև օգտակար է օգտատերերի համար՝ նրանք անմիջապես կտեսնեն, թե ինչն է իրենց համար կարևոր և ինչ կարող են անտեսել:

Մուտքի սահմանափակման երկրորդ պատճառը գրադարանի մշակողին թույլ տալու ցանկությունն է փոխել դասի ներքին մեխանիզմները՝ առանց անհանգստանալու, թե դա ինչպես կազդի հաճախորդի ծրագրավորողի վրա: Օրինակ, դուք կարող եք շտապ իրականացնել որոշակի դաս՝ ծրագրի մշակումն արագացնելու համար, այնուհետև վերաշարադրել այն՝ արագությունը բարելավելու համար: Եթե ​​դուք պատշաճ կերպով առանձնացրել և պաշտպանել եք ինտերֆեյսը և իրականացումը, դա ամենևին էլ դժվար չպետք է լինի:

Javaօգտագործում է մուտքի մակարդակը բնութագրող երեք բացահայտ հիմնաբառեր. հանրային, մասնավոր և պաշտպանված . Նրանց նպատակը և օգտագործումը շատ պարզ է. Այս մուտքի ցուցիչները որոշում են, թե ով իրավունք ունի օգտագործելու դրանց հաջորդող սահմանումները: Խոսք հանրային նշանակում է, որ հետևյալ սահմանումները հասանելի են բոլորին. Ընդհակառակը, խոսքը մասնավոր նշանակում է, որ դրան հաջորդող դրույթները հասանելի են միայն տիպի ստեղծողին, դրա մեթոդների ներսում: Ժամկետ մասնավոր - «բերդի պատ» ձեր և ծրագրավորող-հաճախորդի միջև։ Եթե ​​ինչ-որ մեկը փորձի օգտագործել մասնավոր -անդամներ, այն կկանգնեցվի կազմման սխալի պատճառով: սպեցիֆիկատոր պաշտպանված գործում է նման մասնավոր , մեկ բացառությամբ ստացված դասերին հասանելի են նշված անդամները պաշտպանված բայց մուտք չունեն մասնավոր -անդամներ (մենք շուտով կանդրադառնանք ժառանգությանը):

AT Javaկա նաև «կանխադրված» մուտք, որն օգտագործվում է նշված ցուցիչներից որևէ մեկի բացակայության դեպքում: Այն նաև երբեմն կոչվում է փաթեթային մուտք ( փաթեթի հասանելիություն) քանի որ դասերը կարող են օգտագործել իրենց փաթեթում այլ դասերի ընկերներին, բայց փաթեթից դուրս նույն ընկեր անդամները ձեռք են բերում կարգավիճակ. մասնավոր .

Իրականացում Վերօգտագործում

Ստեղծված և փորձարկված դասը (իդեալական) պետք է լինի օգտակար կոդի բլոկ: Սակայն պարզվում է, որ այս նպատակին հասնելը շատ ավելի դժվար է, քան շատերը կարծում են. բազմակի օգտագործման օբյեկտների մշակումը պահանջում է փորձ և հարցի էության ըմբռնում: Բայց հենց որ ճիշտ հասկանաք լավ շինարարություն, դա ուղղակի խնդրելու է իրականացնել այլ ծրագրերում։ Կոդի վերօգտագործումը օբյեկտի վրա հիմնված լեզուների ամենատպավորիչ առավելություններից մեկն է:

Դաս վերօգտագործելու ամենահեշտ ձևը նրա օբյեկտն ուղղակիորեն ստեղծելն է, բայց դուք կարող եք նաև տեղադրել այդ դասի օբյեկտը նոր դասի ներսում: Մենք այս օբյեկտը անվանում ենք ներարկում (անդամ օբյեկտի ստեղծում): Նոր դասը կարող է պարունակել ցանկացած թվով այլ տեսակի օբյեկտներ, ցանկացած համակցությամբ, որն անհրաժեշտ է ցանկալի ֆունկցիոնալությանը հասնելու համար: Քանի որ մենք կազմում ենք նոր դասարդեն գոյություն ունեցող դասերից այս մեթոդը կոչվում է կազմը(երբ կոմպոզիցիան կատարվում է դինամիկ, այն սովորաբար կոչվում է ագրեգացիա) Կազմը հաճախ կոչվում է «ունի» հարաբերություն ( ունի), ինչպես, օրինակ, «Մեքենան ունի շարժիչ» նախադասության մեջ։

(UML դիագրամներում կոմպոզիցիան նշվում է լցված ադամանդի միջոցով՝ ցույց տալով, օրինակ, որ կա միայն մեկ մեքենա: Ես սովորաբար օգտագործում եմ հարաբերությունների ավելի ընդհանուր ձև՝ միայն գծեր, առանց ադամանդի, ինչը նշանակում է ասոցիացիա (հղում): Սա սովորաբար բավարար է գծապատկերների մեծ մասի համար, որտեղ կազմի և համախմբման միջև տարբերությունը ձեզ համար կարևոր չէ:)

Կոմպոզիցիան շատ ճկուն գործիք է։ Ձեր նոր դասի անդամ օբյեկտները սովորաբար հայտարարվում են մասնավոր ( մասնավոր ), ինչը նրանց անհասանելի է դարձնում դասը օգտագործող հաճախորդ ծրագրավորողների համար: Սա թույլ է տալիս փոփոխություններ կատարել այս անդամ օբյեկտներում՝ առանց փոփոխելու առկա հաճախորդի կոդը: Դուք կարող եք նաև փոխել այս անդամներին գործարկման ժամանակ՝ դինամիկ կերպով վերահսկելու ձեր ծրագրի վարքագիծը: Ստորև նկարագրված ժառանգությունը չունի այս ճկունությունը, քանի որ կոմպիլյատորը որոշակի սահմանափակումներ է դնում ժառանգության միջոցով ստեղծված դասերի վրա:

Ժառանգությունը կարևոր դեր է խաղում օբյեկտի վրա հիմնված ծրագրավորման մեջ, ուստի հաճախ դրան մեծ ուշադրություն է հատկացվում, և սկսնակը կարող է մտածել, որ ժառանգությունը պետք է կիրառվի ամենուր: Իսկ դա հղի է անշնորհք ու անհարկի բարդ լուծումների ստեղծմամբ։ Փոխարենը, նոր դասեր ստեղծելիս նախ պետք է գնահատել կոմպոզիցիայի հնարավորությունը, քանի որ այն ավելի պարզ է և ճկուն։ Եթե ​​դուք ընդունեք առաջարկվող մոտեցումը, ձեր ծրագրավորման կառուցվածքները շատ ավելի պարզ կդառնան: Եվ քանի որ գործնական փորձ ձեռք բերեք, դժվար չի լինի հասկանալ, թե որտեղ պետք է օգտագործվի ժառանգությունը:

Ժառանգություն

Ինքնին օբյեկտի գաղափարը չափազանց հարմար է: Օբյեկտը թույլ է տալիս միավորել տվյալներն ու ֆունկցիոնալությունը կոնցեպտուալ մակարդակում, այսինքն՝ կարող եք ցանկալի հայեցակարգը ներկայացնել առաջադրանքի տարածքից՝ այն կոնկրետացնելու փոխարեն՝ օգտագործելով մեքենայի բարբառը: Այս հասկացությունները կազմում են ծրագրավորման լեզվի հիմնական միավորները, որոնք նկարագրված են դասի բանալի բառով:

Բայց դուք պետք է խոստովանեք, որ ամոթ կլինի ստեղծել ինչ-որ դասակարգ, և հետո նորից կատարել ամբողջ աշխատանքը նմանատիպ դասարանի համար: Շատ ավելի ռացիոնալ է վերցնել պատրաստի դաս, այն «կլոնավորել», իսկ հետո լրացումներ ու թարմացումներ անել ստացված կլոնի վրա։ Սա հենց այն է, ինչ դուք ստանում եք ժառանգության արդյունքում, մեկ բացառությամբ. եթե սկզբնական դասը (նաև կոչվում է բազային * դաս, գերդաս կամ ծնող դաս) փոխվում է, ապա բոլոր փոփոխությունները արտացոլվում են նրա «կլոնում» (կոչվում է ստացված դաս): , ժառանգված դաս, ենթադաս կամ երեխա դաս):

(UML դիագրամի սլաքը (դատարկ եռանկյունին) ցույց է տալիս ստացված դասից մինչև հիմնական դասը: Ինչպես շուտով կտեսնեք, կարող է լինել մեկից ավելի ստացված դաս:

Տիպը սահմանում է ոչ միայն օբյեկտների խմբի հատկությունները. այն կապված է նաև այլ տեսակների հետ: Երկու տեսակները կարող են կիսել նմանություններն ու վարքագիծը, բայց տարբերվում են բնութագրերի քանակով, ինչպես նաև ավելի շատ հաղորդագրություններ մշակելու (կամ դրանք այլ կերպ մշակելու ունակությամբ): Տեսակների այս ընդհանրությունն արտահայտելու համար ժառանգությունն օգտագործում է բազային և ածանցյալ տեսակների հասկացությունը։ Հիմնական տեսակը պարունակում է բոլոր բնութագրերն ու գործողությունները, որոնք ընդհանուր են դրանից բխող բոլոր տեսակների համար: Դուք ստեղծում եք բազային տեսակ՝ ներկայացնելու ձեր համակարգի որոշ օբյեկտների վերաբերյալ ձեր հասկացողության հիմքը: Մյուս տեսակները բխում են բազային տիպից՝ արտահայտելով այս էության այլ իրականացումները:

Օրինակ, վերամշակող մեքենան տեսակավորում է թափոնները: Բազային տեսակը կլինի «աղբը», և աղբի յուրաքանչյուր կտոր ունի քաշ, արժեք և այլն, և կարող է տրորվել, հալվել կամ քայքայվել: Դրա հիման վրա ժառանգվում են աղբի ավելի կոնկրետ տեսակներ՝ ունենալով լրացուցիչ բնութագրեր (շիշն ունի գույն) կամ վարքագծային գծեր ( ալյումինե տուփկարող է տրորվել, պողպատե տուփը ձգվում է մագնիսի միջոցով): Բացի այդ, որոշ վարքագծեր կարող են տարբեր լինել (թղթի արժեքը կախված է դրա տեսակից և վիճակից): Ժառանգությունը թույլ է տալիս ստեղծել տիպի հիերարխիա, որը նկարագրում է լուծվող խնդիրը իր տեսակների համատեքստում:

Երկրորդ օրինակը դասական օրինակ է երկրաչափական ձևեր. Այստեղ հիմքի տեսակը «ձևն» է, և յուրաքանչյուր ձև ունի չափ, գույն, դիրք և այլն: Յուրաքանչյուր ձև կարելի է նկարել, ջնջել, տեղափոխել, ներկել և այլն: Այնուհետև արտադրվում են (ժառանգված) ձևերի հատուկ տեսակներ. քառակուսի, եռանկյուն և այլն, որոնցից յուրաքանչյուրն ունի իր լրացուցիչ բնութագրերը և վարքագիծը: Օրինակ, որոշ ձևեր աջակցում են հայելային գործողություն: Վարքագծի անհատական ​​հատկանիշները կարող են տարբերվել, ինչպես գործչի տարածքը հաշվարկելու դեպքում: Տիպի հիերարխիան մարմնավորում է ձևերի և՛ նմանատիպ, և՛ տարբեր հատկություններ:

Օրինակում օգտագործված հասկացությունների լուծումը նվազեցնելը չափազանց հարմար է, քանի որ ձեզ հարկավոր չեն բազմաթիվ միջանկյալ մոդելներ, որոնք կապում են լուծման նկարագրությունը խնդրի նկարագրության հետ: Օբյեկտների հետ աշխատելիս տիպի հիերարխիան դառնում է առաջնային մոդել, ուստի իրական աշխարհում համակարգը ուղղակիորեն նկարագրելուց անցնում եք համակարգը կոդով նկարագրելուն: Իրականում, օբյեկտի վրա հիմնված պլանավորման դժվարություններից մեկն այն է, որ ձեզ համար շատ հեշտ է խնդրի սկզբից մինչև լուծման ավարտը անցնելը: Բարդ լուծումների համար պատրաստված միտքը հաճախ խրվում է պարզ մոտեցումներ կիրառելիս:

Ժառանգելով գոյություն ունեցող տեսակից՝ դուք ստեղծում եք նոր տեսակ։ Այս նոր տեսակը պարունակում է ոչ միայն գոյություն ունեցող տիպի բոլոր անդամներին (չնայած անդամները նշված են որպես մասնավոր , թաքնված և անհասանելի), բայց, որ ավելի կարևոր է, կրկնում է բազային դասի ինտերֆեյսը։ Սա նշանակում է, որ բոլոր հաղորդագրությունները, որոնք կարող եք ուղարկել բազային դասին, կարող եք նաև ուղարկել ստացված դասին: Եվ քանի որ մենք տարբերակում ենք դասի տեսակները հաղորդագրությունների հավաքածուով, որը մենք կարող ենք ուղարկել, դա նշանակում է, որ ստացված դասը բազային դասի հատուկ դեպք է. Նախորդ օրինակում «շրջանակը գործիչ է»։ Ժառանգության միջոցով ձեռք բերված տեսակների համարժեքությունը օբյեկտի վրա հիմնված ծրագրավորման իմաստը հասկանալու հիմնարար պայմաններից մեկն է:

Քանի որ և՛ բազային, և՛ ածանցյալ դասերն ունեն նույն հիմնական ինտերֆեյսը, այդ ինտերֆեյսի համար պետք է իրականացում լինի: Այլ կերպ ասած, ինչ-որ տեղ պետք է լինի կոդ, որը կատարվում է, երբ օբյեկտը ստանում է որոշակի հաղորդագրություն: Եթե ​​դուք պարզապես ժառանգել եք դաս և այլ բան չեք արել, բազային դասի ինտերֆեյսի մեթոդները կանցնեն ստացված դասի մեջ անփոփոխ: Սա նշանակում է, որ ածանցյալ դասի օբյեկտները ոչ միայն նույն տիպի են, այլև ունեն նույն վարքագիծը, և միևնույն ժամանակ ժառանգությունն ինքնին կորցնում է իր նշանակությունը։

Նոր դասը բազային դասից փոխելու երկու եղանակ կա. Առաջինը բավականին ակնհայտ է. ստացված դասին ավելացվում են բոլորովին նոր մեթոդներ: Դրանք այլևս բազային դասի ինտերֆեյսի մաս չեն: Ըստ երևույթին, բազային դասը չի արել այն ամենը, ինչ պահանջվում էր, այնպես որ դուք ավելացրեցիք մի քանի մեթոդներ: Այնուամենայնիվ, ժառանգության նկատմամբ նման պարզ և պարզունակ մոտեցումը երբեմն պարզվում է, որ խնդրի իդեալական լուծումն է: Այնուամենայնիվ, մի բան, որը պետք է ուշադիր դիտարկել, այն է, որ բազային դասին կարող են անհրաժեշտ լինել նաև այս ավելացված մեթոդները: Նախշերի նույնականացման և ճարտարապետության վերանայման գործընթացը առօրյա է օբյեկտի վրա հիմնված ծրագրավորման մեջ:

Մինչդեռ ժառանգությունը երբեմն հուշում է, որ ինտերֆեյսը կավելացվի նոր մեթոդներով (հատկապես Java, որտեղ ժառանգությունը նշվում է բանալի բառով տարածվում է , այսինքն՝ «ընդլայնել»), սա ամենևին էլ անհրաժեշտ չէ։ Դասը փոփոխելու երկրորդ, ավելի կարևոր միջոցը դա է փոփոխությունվարքագիծ արդեն առկա մեթոդներըբազային դաս. Սա կոչվում է գերակայող (կամ գերակայող) մեթոդ:

Մեթոդը վերացնելու համար դուք պարզապես ստեղծում եք այդ մեթոդի նոր սահմանումը ստացված դասում: Դուք մի տեսակ ասում եք «Ես օգտագործում եմ նույն ինտերֆեյսի մեթոդը, բայց ես ուզում եմ, որ այն տարբեր բաներ անի իմ նոր տեսակի համար»:

Ժառանգությունն օգտագործելիս ակնհայտ հարց է առաջանում՝ արդյոք ժառանգականությունը պետք է գերազանցի մեթոդներին միայնբազային դաս (և չավելացնե՞լ նոր մեթոդներ, որոնք գոյություն չունեն բազային դասում): Սա կնշանակի, որ ստացված դասը կլինի ճիշտ նույն տեսակը, ինչ բազային դասը, քանի որ նրանք ունեն նույն ինտերֆեյսը: Արդյունքում, դուք կարող եք ազատորեն փոխարինել բազային դասի օբյեկտները ստացված դասի օբյեկտներով: Դուք կարող եք խոսել ամբողջական փոխարինման մասին, և դա հաճախ կոչվում է փոխարինման սկզբունքը. Ինչ-որ իմաստով ժառանգության այս ճանապարհը իդեալական է։ Բազային դասի և ստացված դասի միջև այս տեսակի հարաբերությունը հաճախ կոչվում է հարաբերություն: «ինչ-որ բան է», քանի որ կարելի է ասել «շրջանակը գործիչ է»։ Որոշելու համար, թե որքանով է տեղին լինելու ժառանգությունը, բավական է ստուգել, ​​թե արդյոք դասերի միջև կա «կա» հարաբերություն և որքանով է դա արդարացված:

Այլ դեպքերում ստացված դասի միջերեսը համալրվում է նոր տարրերով, ինչը հանգեցնում է դրա ընդլայնմանը։ Նոր տեսակը դեռ կարող է օգտագործվել բազային տիպի փոխարեն, բայց այժմ այս փոխարինումը իդեալական չէ, քանի որ նոր մեթոդները հասանելի չեն բազային տիպից: Նման կապը նկարագրվում է «նման» արտահայտությամբ (սա իմ տերմինն է); նոր տեսակը պարունակում է հին տիպի միջերեսը, բայց նաև ներառում է նոր մեթոդներ, և չի կարելի ասել, որ այս տեսակները լիովին նույնն են: Որպես օրինակ վերցնենք օդորակիչը:

Ենթադրենք՝ ձեր տունը հագեցած է ամեն ինչով անհրաժեշտ սարքավորումներվերահսկելու սառեցման գործընթացը. Հիմա պատկերացրեք, որ օդորակիչը փչացել է, և դուք այն փոխարինել եք տաքացուցիչով, որը կարող է և՛ տաքացնել, և՛ սառեցնել: Ջեռուցիչը «նման է» օդորակիչին, բայց այն կարող է ավելին անել: Քանի որ ձեր տան կառավարման համակարգը կարող է կառավարել միայն հովացումը, այն սահմանափակ է նոր հաստատության հովացման մասի հետ հաղորդակցվելու հարցում: Նոր օբյեկտի ինտերֆեյսը ընդլայնվել է, և գոյություն ունեցող համակարգը բնօրինակ ինտերֆեյսից բացի այլ բան չի ճանաչում:

Իհարկե, դիտելով այս հիերարխիան, պարզ է դառնում, որ «սառեցման համակարգ» բազային դասը բավականաչափ ճկուն չէ. այն պետք է վերանվանվի «ջերմաստիճանի վերահսկման համակարգ», որպեսզի ներառի նաև ջեռուցում, և դրանից հետո կգործի փոխարինման սկզբունքը։ Այնուամենայնիվ, այս դիագրամը տալիս է օրինակ, թե ինչ կարող է տեղի ունենալ իրականում:

Փոխարինման սկզբունքին ծանոթանալուց հետո կարող է տպավորություն ստեղծվել, որ այս մոտեցումը (լրիվ փոխարինումը) զարգացման միակ ճանապարհն է։ Ընդհանուր առմամբ, եթե ձեր տիպի հիերարխիան աշխատում է այսպես, դա իսկապես լավ է: Բայց որոշ իրավիճակներում բացարձակապես անհրաժեշտ է նոր մեթոդներ ավելացնել ստացված դասի ինտերֆեյսին: Ավելի մանրամասն ուսումնասիրության դեպքում երկու դեպքերն էլ բավականին ակնհայտ են թվում:

Փոխարինելի առարկաներ և պոլիմորֆիզմ

Տիպային հիերարխիա օգտագործելիս հաճախ անհրաժեշտ է լինում որոշակի տեսակի օբյեկտը դիտարկել որպես հիմնական տիպ: Սա թույլ է տալիս գրել կոդ, որը կախված չէ կոնկրետ տեսակներից: Այսպիսով, ձևերի օրինակում մեթոդները պարզապես մանիպուլյացիայի են ենթարկում ձևերը՝ անկախ նրանից՝ դրանք շրջանակներ են, ուղղանկյուններ, եռանկյուններ կամ դեռևս չսահմանված ձևեր: Բոլոր ձևերը կարելի է նկարել, ջնջել և տեղափոխել, իսկ մեթոդները պարզապես հաղորդագրություններ են ուղարկում ձևի օբյեկտին. նրանց չի հետաքրքրում, թե ինչպես է օբյեկտը վերաբերվում ուղերձին:

Նման ծածկագիրը կախված չէ նոր տեսակների ավելացումից, և նոր տիպերի ավելացումն ամենատարածված միջոցն է՝ ընդլայնելու օբյեկտի վրա հիմնված ծրագրերը՝ նոր իրավիճակները կարգավորելու համար: Օրինակ, դուք կարող եք ստեղծել նոր ձևերի ենթադաս (հնգանկյուն), առանց փոխելու մեթոդները, որոնք աշխատում են միայն ընդհանուր ձևերի հետ: Ծրագիրը հեշտությամբ ընդլայնելու ունակությունը՝ ներմուծելով նոր ածանցյալ տեսակներ, շատ կարևոր է, քանի որ այն մեծապես բարելավում է ծրագրի ճարտարապետությունը՝ միևնույն ժամանակ նվազեցնելով ծրագրաշարի պահպանման ծախսերը:

Այնուամենայնիվ, երբ փորձում ենք ածանցյալ տիպերի առարկաները որպես հիմնական տեսակներ նշել (շրջանակները՝ որպես պատկեր, հեծանիվը՝ որպես փոխադրամիջոց, կորմորանը՝ որպես թռչուն և այլն), առաջանում է մեկ խնդիր։ Եթե ​​մեթոդը պատրաստվում է ընդհանուր թվին ասել, որ ինքն իրեն նկարի, կամ տրանսպորտային միջոցին հետևի որոշակի ընթացք, կամ թռչունին թռչի, ապա կոմպիլյատորը չի կարող հստակ իմանալ, թե կոդի որ մասը կկատարվի: Սա է ամբողջ խնդիրը. երբ հաղորդագրություն է ուղարկվում, ծրագրավորողը չի ցանկանում իմանալ, թե ինչ կոդը է կատարվում. Նկարչության մեթոդը կարող է հավասար հաջողությամբ կիրառվել շրջանագծի, ուղղանկյունի և եռանկյունու վրա, և օբյեկտը կկատարի ճիշտ կոդը՝ կախված իր բնորոշ տեսակից:

Եթե ​​ձեզ հարկավոր չէ իմանալ, թե որ կոդն է կատարվում, ապա երբ ավելացնում եք նոր ենթատեսակ, դրա իրականացման կոդը կարող է տարբեր լինել՝ չպահանջելով փոխել այն մեթոդը, որից այն կանչվել է: Եթե ​​կոմպիլյատորը հստակ չգիտի, թե ինչ կոդը պետք է գործարկի, ի՞նչ է անում:

AT հաջորդ օրինակըառարկա BirdController (թռչունների կառավարում) կարող է աշխատել միայն ընդհանուր օբյեկտների հետ թռչուն (թռչուն), չիմանալով դրանց ճշգրիտ տեսակը: Տեսանկյունից BirdController սա հարմար է, քանի որ դրա համար օգտագործվող օբյեկտի տեսակը ստուգելու համար հատուկ կոդ գրելու կարիք չկա թռչուն , կարգավորել որոշ հատուկ վարքագիծ: Ինչպե՞ս է պատահում, որ երբ զանգում եք move () մեթոդը՝ առանց հստակ տեսակը նշելու թռչուն , կատարվում է ճիշտ գործողություն՝ օբյեկտը սագ (սագը) վազում է, թռչում կամ լողում, իսկ առարկան Պինգվին (պինգվին) վազե՞լ, թե՞ լողալ:

Պատասխանը բացատրվում է հիմնական հատկանիշըօբյեկտ-կողմնորոշված ​​ծրագրավորում. կոմպիլյատորը չի կարող նման գործառույթներ կանչել ավանդական եղանակով: Ոչ OOP կոմպիլյատորի կողմից ստեղծված գործառույթներ կանչելիս օգտագործեք վաղ կապում- Շատերը չգիտեն այս տերմինը պարզապես այն պատճառով, որ այլ տարբերակ չեն պատկերացնում։ Վաղ կապի դեպքում կոմպիլյատորը ստեղծում է ֆունկցիայի կանչ տրված անուն, և կապակցիչը կապում է այս զանգը կատարվող կոդի բացարձակ հասցեին։ OOP-ում ծրագիրը չի կարողանում որոշել կոդի հասցեն մինչև գործարկման ժամանակը, ուստի օբյեկտին հաղորդագրություն ուղարկելիս պետք է այլ մեխանիզմ աշխատի։

Այս խնդիրը լուծելու համար օբյեկտի վրա հիմնված ծրագրավորման լեզուները օգտագործում են հայեցակարգը ուշ կապում. Երբ դուք հաղորդագրություն եք ուղարկում օբյեկտին, կանչվող կոդը հայտնի չէ մինչև գործարկման ժամանակը: Կոմպիլյատորը միայն համոզվում է, որ մեթոդը գոյություն ունի, ստուգում է տեսակները նրա պարամետրերի և վերադարձի արժեքի համար, բայց չգիտի, թե ինչ տեսակի կոդը կկատարվի:

Ուշ կապում իրականացնելու համար, Javaբացարձակ զանգի փոխարեն օգտագործում է հատուկ կոդի հատվածներ: Այս կոդը հաշվարկում է մեթոդի մարմնի հասցեն՝ հիմնվելով օբյեկտում պահվող տեղեկատվության վրա (գործընթացը շատ մանրամասն ներկայացված է պոլիմորֆիզմի մասին 7-րդ գլխում): Այսպիսով, յուրաքանչյուր օբյեկտ կարող է տարբեր կերպ վարվել՝ կախված այս հատուկ կոդի բովանդակությունից: Երբ դուք հաղորդագրություն եք ուղարկում, օբյեկտն իրականում որոշում է, թե ինչ անել դրա հետ:

Որոշ լեզուներ պահանջում են, որ դուք հստակորեն նշեք, որ մեթոդը պետք է օգտագործի ճկուն ուշ պարտադիր մեխանիզմ (in C++դրա համար կա բանալի բառ Վիրտուալ) Այս լեզուներում մեթոդները դինամիկորեն կապված չեն լռելյայնորեն: AT Javaուշ կապը կատարվում է լռելյայն, և ձեզ հարկավոր չէ հիշել որևէ հիմնաբառ ավելացնելու մասին՝ պոլիմորֆիզմ ապահովելու համար:

Հիշեք ձևերի օրինակը: Դասերի ընտանիքը (հիմնված նույն ինտերֆեյսի վրա) ցուցադրվել է այս գլխի ավելի վաղ գծապատկերում: Պոլիմորֆիզմը ցուցադրելու համար մենք կգրենք կոդի հատված, որն անտեսում է տիպի առանձնահատկությունները և աշխատում է միայն հիմնական դասի վրա: Այս կոդը առանձնացված է տիպի առանձնահատկություններից, ուստի ավելի հեշտ է գրել և հասկանալ: Եվ եթե ժառանգության միջոցով ավելացվի նոր տեսակ (օրինակ՝ վեցանկյուն), ապա ձեր գրած ծածկագիրը նոր տեսակի գործչի համար կաշխատի նույնքան լավ, որքան առկա տիպերի կոդը: Այսպիսով, ծրագիրը դառնում է ընդարձակելի:

Ենթադրենք, դուք գրել եք Javaհետևյալ մեթոդը (շուտով կսովորեք, թե ինչպես դա անել).

void doSomething (ձևի ձև) (
shape.erase(); // ջնջել
//...
shape.draw(); // նկարել
}

Մեթոդն աշխատում է ընդհանրացված թվով ( ձեւավորել ), այսինքն՝ դա կախված չէ գծվող կամ ջնջվող օբյեկտի որոշակի տեսակից։ Այժմ մենք օգտագործում ենք մեթոդի կանչը անել ինչ որ բան() հաղորդման մեկ այլ հատվածում.

Շրջանակի շրջան = new Circle() ; // շրջան
Եռանկյունի եռանկյուն = new Triangle() ; // եռանկյուն
Line line = new Line(); // տող
doSomething (շրջանակ) ;
doSomething (եռանկյուն) ;
doSomething (տող);

Մեթոդների զանգեր անել ինչ որ բան() ավտոմատ կերպով աշխատում է ճիշտ՝ անկախ օբյեկտի իրական տեսակից:

Սա իրականում բավականին կարևոր փաստ է։ Դիտարկենք տողը.

doSomething (շրջանակ) ;

Այստեղ տեղի է ունենում հետևյալը. մեթոդ, որը ակնկալում է օբյեկտ ձեւավորել , «շրջանակ» օբյեկտը փոխանցվում է ( Շրջանակ ) Քանի որ շրջանից ( Շրջանակ ) միաժամանակ գործիչ է ( ձեւավորել ), ապա մեթոդը անել ինչ որ բան() և նրան վերաբերվում է որպես գործչի: Այլ կերպ ասած, ցանկացած հաղորդագրություն, որը մեթոդը կարող է ուղարկել ձեւավորել , նույնպես ընդունված է Շրջանակ . Այս գործողությունը լիովին անվտանգ է և նույնքան տրամաբանական:

Մենք վերաբերվում ենք ածանցյալ տիպի հետ գործ ունենալու այս գործընթացին, կարծես այն լինի հիմնական տիպ: վերափոխում. Խոսք վերափոխումնշանակում է, որ օբյեկտը դիտվում է որպես այլ տեսակի պատկանող, և բարձրացողԴա պայմանավորված է նրանով, որ ժառանգության դիագրամներում բազային դասերը սովորաբար վերևում են, իսկ ստացված դասերը՝ ներքևում: Սա նշանակում է, որ բազային տիպի փոխարկումը գծապատկերի երկայնքով դեպի վեր շարժում է, և հետևաբար այն «վերև» է:

Օբյեկտ-կողմնորոշված ​​ծրագիրը գրեթե միշտ պարունակում է upcast, քանի որ այդպես դուք ձերբազատվում եք օբյեկտի ճշգրիտ տեսակը իմանալու անհրաժեշտությունից, որի հետ աշխատում եք: Նայեք մեթոդի մարմնին անել ինչ որ բան() :

shape.erase();
// ...
shape.draw();

Նկատի ունեցեք, որ այն չի ասում «եթե դու օբյեկտ ես Շրջանակ , արա դա, իսկ եթե օբյեկտ ես Քառակուսի արա այս ու այն»: Նման կոդ յուրաքանչյուր հնարավոր տեսակի համար առանձին գործողություններով ձեւավորել շփոթեցնող կլինի և պետք է փոխվի ամեն անգամ, երբ նոր ենթատեսակ ավելացվի ձեւավորել . Եվ այսպես, դուք պարզապես ասում եք. «Դու ֆիգուր ես, և ես գիտեմ, որ դու կարողանում ես նկարել և ջնջել քեզ, լավ, արա դա և ինքդ հոգ տանել մանրամասների մասին»:

Մեթոդի կոդում անել ինչ որ բան() Հետաքրքիրն այն է, որ ամեն ինչ ճիշտ է ստացվում: Երբ կոչվում է նկարել () օբյեկտի համար Շրջանակ այլ կոդ է կատարվում, և ոչ թե այն, որն աշխատում է, երբ կանչվում է նկարել () օբյեկտների համար Քառակուսի կամ տող , եւ երբ նկարել () դիմել է անհայտ գործչի ձեւավորել , ճիշտ վարքագիծն ապահովվում է իրական տիպի օգտագործմամբ ձեւավորել . Այն գտնվում է ամենաբարձր աստիճանըհետաքրքիր է, քանի որ, ինչպես նշվեց մի փոքր ավելի վաղ, երբ կոմպիլյատորը ստեղծում է կոդ անել ինչ որ բան() , այն հստակ չգիտի, թե ինչ տեսակների հետ է աշխատում: Համապատասխանաբար, կարելի է ակնկալել, որ մեթոդի տարբերակները կկոչվեն նկարել () և ջնջել () բազային դասից ձեւավորել , ոչ թե դրանց տարբերակները կոնկրետ դասերից Շրջանակ , Քառակուսի կամ տող . Եվ այնուամենայնիվ ամեն ինչ ճիշտ է աշխատում՝ շնորհիվ պոլիմորֆիզմի։ Կոմպիլյատորը և գործարկման համակարգը հոգում են բոլոր մանրամասները. այն ամենը, ինչ դուք պետք է իմանաք, այն է, որ դա տեղի կունենա... և ավելի կարևոր է, թե ինչպես կարելի է ծրագրեր ստեղծել այս մոտեցմամբ: Երբ դուք հաղորդագրություն եք ուղարկում օբյեկտին, օբյեկտը կընտրի ճիշտ վարքագիծը՝ օգտագործելով upcast:

Մեկ արմատային հիերարխիա

Հայտնվելուց կարճ ժամանակ անց C++ OOP-ի հարցը սկսեց ակտիվորեն քննարկվել. Արդյո՞ք բոլոր դասերը պետք է ժառանգվեն մեկ բազային դասից: AT Java(ինչպես գրեթե բոլոր այլ OOP լեզուներում, բացառությամբ C++) Այս հարցին տրվեց դրական պատասխան։ Ամբողջ տիպի հիերարխիան հիմնված է մեկ հիմնական դասի վրա Օբյեկտ . Պարզվեց, որ մեկ արմատային հիերարխիան շատ առավելություններ ունի.

Մեկ արմատավորված հիերարխիայի բոլոր օբյեկտները ունեն ընդհանուր ինտերֆեյս, այնպես որ, մեծ հաշվով, դրանք բոլորը կարող են դիտարկվել որպես մեկ հիմքում ընկած տեսակ: AT C++ընտրվել է մեկ այլ տարբերակ՝ այս լեզվում ընդհանուր նախահայր գոյություն չունի։ Հին կոդի հետ համատեղելիության առումով այս մոդելն ավելի է համապատասխանում ավանդույթին։ Գ, և դուք կարող եք մտածել, որ այն ավելի քիչ սահմանափակ է: Բայց հենց որ առաջանա լիարժեք օբյեկտի վրա հիմնված ծրագրավորման անհրաժեշտություն, դուք պետք է ստեղծեք ձեր սեփական դասի հիերարխիան, որպեսզի ստանաք նույն առավելությունները, որոնք ներկառուցված են այլ OOP լեզուների մեջ: Եվ ցանկացած նոր դասի գրադարանում դուք կարող եք հանդիպել ինչ-որ անհամատեղելի ինտերֆեյսի: Այս նոր ինտերֆեյսները ձեր ծրագրի ճարտարապետության մեջ ներառելը լրացուցիչ ջանք կպահանջի (և, հնարավոր է, բազմակի ժառանգություն): Արժե՞ արդյոք լրացուցիչ «ճկունությունը»: C++նմանատիպ ծախսեր? Եթե ​​դրա կարիքն ունեք (օրինակ. մեծ ներդրումներկոդի մշակման համար Գ), ուրեմն պարտվող չես լինի։ Եթե ​​զարգացումը սկսվում է զրոյից, ապա մոտեցումը Javaավելի արդյունավետ տեսք ունի:

Մեկ արմատային հիերարխիայի բոլոր օբյեկտները երաշխավորված են որոշ ընդհանուր ֆունկցիոնալությամբ: Դուք գիտեք, որ որոշակի հիմնական գործողություններ կարող են իրականացվել համակարգի ցանկացած օբյեկտի վրա: Բոլոր օբյեկտները հեշտությամբ ստեղծվում են դինամիկ կույտի վրա, և փաստարկների փոխանցումը մեծապես պարզեցված է:

Մեկ արմատային հիերարխիան շատ ավելի հեշտ է դարձնում աղբահանության իրականացումը` ամենակարեւոր բարելավումներից մեկը Javaհամեմատ C++. Քանի որ տիպի տեղեկատվությունը երաշխավորված է, որ առկա է ցանկացած օբյեկտում գործարկման ժամանակ, համակարգում երբեք չի լինի օբյեկտ, որի տեսակը հնարավոր չէ որոշել: Սա հատկապես կարևոր է համակարգային գործողություններ կատարելիս, ինչպիսիք են բացառությունները և ծրագրավորման ավելի ճկունությունը:

Տարաներ

Հաճախ նախապես հայտնի չէ, թե քանի առարկա կպահանջվի որոշակի խնդիր լուծելու համար և որքան ժամանակ դրանք գոյություն կունենան։ Անհասկանալի է նաև, թե ինչպես պահել նման առարկաները: Որքա՞ն հիշողություն պետք է հատկացվի այս օբյեկտները պահելու համար: Անհայտ է, քանի որ այս տեղեկատվությունը հասանելի կլինի միայն ծրագրի գործարկման ընթացքում:

Օբյեկտ-կողմնորոշված ​​ծրագրավորման բազմաթիվ խնդիրներ լուծված են պարզ գործողությունԴուք ստեղծում եք մեկ այլ տեսակի օբյեկտ: Նոր օբյեկտի տեսակը, որը լուծում է այս կոնկրետ խնդիրը, պարունակում է հղումներ դեպի այլ օբյեկտներ: Իհարկե, զանգվածները, որոնք աջակցվում են լեզուների մեծ մասում, նույնպես կարող են խաղալ այս դերը: Այնուամենայնիվ, նոր օբյեկտը, որը սովորաբար կոչվում է կոնտեյներ(կամ հավաքածու, բայց ներս Javaտերմինն օգտագործվում է այլ իմաստով) կամքը անհրաժեշտության դեպքում ընդլայնվում է՝ տեղավորելու այն, ինչ դուք դնում եք դրա մեջ: Հետևաբար, ձեզ հարկավոր չի լինի ժամանակից շուտ իմանալ, թե քանի օբյեկտի համար է նախատեսված տարայի տարողությունը: Պարզապես ստեղծեք կոնտեյներ, և այն կզբաղվի մանրամասներով:

Բարեբախտաբար, լավ OOP լեզուն գալիս է պատրաստի տարաների հավաքածուով: AT C++դա ստանդարտ գրադարանի մի մասն է C++, երբեմն կոչվում է գրադարան ստանդարտ կաղապարներ (Ստանդարտ կաղապարների գրադարան, STL). Կարճ խոսակցությունգալիս է տարաների շատ լայն տեսականիով: Javaպարունակում է նաև տարաներ իր ստանդարտ գրադարանում: Որոշ գրադարանների համար բավարար է համարվում բոլոր կարիքների համար մեկ բեռնարկղ ունենալը, իսկ մյուսներում (օրինակ՝ ներս Java) կան տարբեր բեռնարկղեր բոլոր առիթների համար՝ մի քանի տարբեր տեսակի ցուցակներ Ցուցակ (տարրերի հաջորդականության պահպանման համար), քարտեզներ Քարտեզ (հայտնի է նաև որպես ասոցիատիվ զանգվածներ, թույլ են տալիս առարկաները կապել այլ օբյեկտների հետ), ինչպես նաև հավաքածուներ հավաքածու (յուրաքանչյուր տեսակի համար եզակի արժեքներ տրամադրելով): Կոնտեյներային գրադարանները կարող են նաև պարունակել հերթեր, ծառեր, կույտեր և այլն:

Դիզայնի տեսանկյունից ձեզ իսկապես անհրաժեշտ է կոնտեյներ, որը կարող է լուծել ձեր խնդիրը: Եթե ​​կոնտեյների մեկ տեսակը բավարարում է բոլոր կարիքները, այլ տեսակներ օգտագործելու պատճառ չկա: Երկու պատճառ կա, թե ինչու պետք է ընտրել առկա տարաներից: Նախ, բեռնարկղերը ապահովում են մի շարք միջերեսներ և փոխազդեցություններ: Դույլի վարքագիծը և միջերեսը տարբերվում է հերթիից, որն այլ կերպ է վարվում, քան հավաքածուն կամ ցուցակը: Այս տարաներից մեկն ի վիճակի է ապահովել ավելին, քան արդյունավետ լուծումձեր առաջադրանքը մնացածի համեմատ: Երկրորդ, տարբեր կոնտեյներներ կատարում են նույն գործողությունները տարբեր ձևերով: լավագույն օրինակը- սա ArrayList և LinkedList . Երկուսն էլ պարզ հաջորդականություններ են, որոնք կարող են ունենալ նույնական միջերեսներ և վարքագիծ: Բայց որոշ գործողություններ էապես տարբերվում են կատարման ժամանակով: Ենթադրենք կամայական տարրի նմուշառման ժամանակը ArrayList միշտ մնում է նույնը, անկախ նրանից, թե որ տարրն է ընտրված: Այնուամենայնիվ, մեջ LinkedList Անբարենպաստ է պատահական մուտքի հետ աշխատելը. որքան ավելի ցած է գտնվում տարրը ցանկում, այնքան ավելի մեծ է ուշացումը առաջացնում դրա որոնումը: Մյուս կողմից, եթե Ձեզ անհրաժեշտ է տարր տեղադրել ցանկի մեջտեղում, LinkedList դա անել ավելի արագ, քան ArrayList . Այս և այլ գործողություններ են տարբեր արդյունավետությունկախված ներքին կառուցվածքըկոնտեյներ. Ծրագրի պլանավորման փուլում դուք կարող եք ընտրել ցանկը LinkedList , և այնուհետև, օպտիմալացման գործընթացում, անցեք ArrayList . Շնորհիվ ինտերֆեյսի վերացական բնույթի Ցուցակ նման անցումը կպահանջի կոդի նվազագույն փոփոխություններ:

Պարամետրացված տեսակներ (գեներիկներ)

Ազատ արձակումից առաջ Java SE5բեռնարկղերը կարող էին պահել միայն տվյալներ Օբյեկտ - միակ ունիվերսալ տեսակը Java. Մեկ արմատային հիերարխիա նշանակում է, որ ցանկացած օբյեկտ կարելի է համարել որպես Օբյեկտ , այնպես որ տարան տարրերով Օբյեկտ հարմար է ցանկացած առարկաների պահպանման համար Պարզունակ տեսակները չեն կարող պահվել տարաներում, բայց մեխանիզմի շնորհիվ ավտոմատ փաթեթավորում(ավտոբոքսինգ) Java SE5այս սահմանափակումը էական չէ: Այս թեման ավելի մանրամասն կքննարկվի ավելի ուշ գրքում:.

Նման կոնտեյների հետ աշխատելիս դուք պարզապես դրա մեջ դնում եք օբյեկտների հղումներ, իսկ ավելի ուշ դրանք առբերում: Բայց եթե բեռնարկղը կարող է միայն պահվել Օբյեկտ , ապա երբ հղում է դրվում մեկ այլ տեսակի օբյեկտի, փոխակերպում դեպի Օբյեկտ , այսինքն՝ օբյեկտի «անհատականության» կորուստ։ Այն ետ բերելիս հղում եք ստանում Օբյեկտ , ոչ թե տարայի մեջ դրված տեսակի մասին հղում: Ինչպե՞ս այն վերածել կոնտեյների մեջ տեղադրված կոնկրետ տեսակի առարկայի:

Խնդիրը լուծվում է նույն տեսակի փոխակերպմամբ, բայց այս անգամ դուք չեք օգտագործում upcast (ժառանգության հիերարխիան մինչև բազային տիպ): Այժմ դուք օգտագործում եք ժառանգության հիերարխիան (երեխայի տիպի) փոխակերպելու մեթոդը: Այս մեթոդըկանչեց ներքև փոխակերպում. Վերածանցման դեպքում հայտնի է, որ շրջանագիծը պատկեր է, ուստի հայտնի է, որ փոխարկումն ապահով է, սակայն հակառակ ձուլման դեպքում (երեխայի տիպին) հնարավոր չէ նախապես ասել, թե արդյոք օրինակը ներկայացնում է Օբյեկտ առարկա Շրջանակ կամ ձեւավորել , այնպես որ ներքևումն անվտանգ է միայն այն դեպքում, եթե հստակ գիտեք օբյեկտի տեսակը:

Այնուամենայնիվ, վտանգը այնքան էլ մեծ չէ. սխալ տիպի իջեցումը կհանգեցնի գործարկման ժամանակի սխալի կոչմանը բացառություն(տես ներքեւում). Բայց երբ բեռնարկղից օբյեկտների հղումներ եք վերցնում, դուք պետք է ինչ-որ կերպ հիշեք դրանց օբյեկտների իրական տեսակը, որպեսզի կատարեք ճիշտ ներքևում:

Downcasting-ը և գործարկման տիպի ստուգումը պահանջում են լրացուցիչ ժամանակ և լրացուցիչ ջանք ծրագրավորողից: Կամ գուցե դուք կարող եք ինչ-որ կերպ ստեղծել կոնտեյներ, որը գիտի պահվող օբյեկտների տեսակը և այդպիսով կվերացնի տիպի փոխարկման անհրաժեշտությունը և հնարավոր սխալները: Լուծումը կոչվում է մեխանիզմ տեսակի պարամետրացում. Պարամետրացված տեսակները դասեր են, որոնք կոմպիլյատորը կարող է ավտոմատ կերպով հարմարեցնել որոշակի տեսակների հետ աշխատելու համար: Օրինակ, կոմպիլյատորը կարող է կարգավորել պարամետրացված կոնտեյներ՝ միայն ձևերը պահելու և առբերելու համար ( ձեւավորել ).

Ամենակարևոր փոփոխություններից մեկը Java SE5աջակցություն է պարամետրացված տեսակների ( ջեներիկներ) Պարամետրացված տեսակները հեշտությամբ ճանաչելի են անկյունային փակագծերով, որոնք պարամետրերի տիպի անուններն են պարունակում. օրինակ՝ կոնտեյներ ArrayList , որը նախատեսված է առարկաներ պահելու համար ձեւավորել , ստեղծվում է այսպես.

ArrayList< Shape >ձևեր = նոր ArrayList< Shape > () ;

Գրադարանի շատ ստանդարտ բաղադրիչներ նույնպես փոփոխվել են՝ օգտագործելու ընդհանուր տեսակներ: Ինչպես շուտով կտեսնեք, ընդհանուր տիպերը հայտնվում են այս գրքի նմուշային ծրագրերից շատերում:

Օբյեկտների ստեղծում, օգտագործում և դրանց կյանքի տևողությունը

Մեկը քննադատական ​​ասպեկտներաշխատանք առարկաների հետ՝ դրանց ստեղծման և ոչնչացման կազմակերպում: Յուրաքանչյուր օբյեկտի գոյության համար պահանջվում են որոշ ռեսուրսներ, առաջին հերթին հիշողություն: Երբ օբյեկտն այլևս կարիք չունի, այն պետք է ոչնչացվի, որպեսզի նրա զբաղեցրած ռեսուրսները հասանելի դառնան ուրիշներին: Պարզ իրավիճակներում առաջադրանքը դժվար չի թվում՝ դուք ստեղծում եք օբյեկտ, օգտագործում այն ​​այնքան ժամանակ, որքան անհրաժեշտ է, ապա ոչնչացնում եք այն: Այնուամենայնիվ, գործնականում հաճախ տեղի են ունենում ավելի բարդ իրավիճակներ:

Ասենք, օրինակ, որ դուք օդային երթեւեկության կառավարման համակարգ եք մշակում: (Նույն մոդելը վերաբերում է նաև պահեստում, կամ տեսահոլովակների վարձույթի համակարգին, կամ թափառող կենդանիների բուծմանը:) Սկզբում ամեն ինչ պարզ է թվում. օդային երթևեկության կառավարման որոշակի տարածքի կոնտեյներ: Ինչ վերաբերում է ռեսուրսների բացթողմանը, ապա համապատասխան օբյեկտը պարզապես ոչնչացվում է, երբ ինքնաթիռը հեռանում է հետագծման գոտուց։

Բայց, հավանաբար, կա մեկ այլ ինքնաթիռի գրանցման համակարգ, և այս տվյալները չեն պահանջում այնպիսի մեծ ուշադրություն, ինչպիսին հիմնական գործառույթըկառավարում։ Միգուցե դա օդանավակայանից հեռացող բոլոր փոքր ինքնաթիռների թռիչքային պլանի գրառումներն են: Այսպես է հայտնվում փոքր ինքնաթիռների երկրորդ կոնտեյները. ամեն անգամ, երբ համակարգում նոր օդանավային օբյեկտ է ստեղծվում, այն նույնպես ներառվում է երկրորդ կոնտեյների մեջ, եթե օդանավը փոքր է: Հաջորդը, որոշ ֆոնային գործընթաց աշխատում է այս կոնտեյների օբյեկտների հետ նվազագույն զբաղվածության պահին:

Այժմ խնդիրն ավելի է բարդանում. ինչպե՞ս գիտեք, թե երբ ջնջել օբյեկտները: Նույնիսկ եթե դուք ավարտված եք օբյեկտի հետ, հնարավոր է, որ մեկ այլ համակարգ դեռ փոխազդում է դրա հետ: Նույն հարցը ծագում է մի շարք այլ իրավիճակներում և ծրագրային համակարգերում, որտեղ անհրաժեշտ է հստակորեն ջնջել օբյեկտները դրանց հետ աշխատանքի ավարտից հետո (օրինակ՝ C++), այն դառնում է բավականին բարդ։

Որտե՞ղ են պահվում օբյեկտի տվյալները և ինչպե՞ս է որոշվում դրանց կյանքի տևողությունը: AT C++Արդյունավետությունն առաջին տեղում է, ուստի ծրագրավորողին տրվում է ընտրություն: Ձեռքբերման համար Մաքսիմում արագությունկատարման վայրը և կյանքի տևողությունը կարող են որոշվել ծրագիրը գրելու պահին: Այս դեպքում օբյեկտները դրվում են կույտի վրա (այդպիսի փոփոխականները կոչվում են ավտոմատ) կամ դեպի ստատիկ պահեստային տարածք: Այսպիսով, հիմնական գործոնը օբյեկտների ստեղծման և ոչնչացման արագությունն է, և դա կարող է անգնահատելի լինել որոշ իրավիճակներում: Այնուամենայնիվ, դա գալիս է ճկունության գնով, քանի որ օբյեկտների թիվը, դրանց ժամկետը և տեսակները պետք է հստակ հայտնի լինեն ծրագրի նախագծման փուլում: Ավելի լայն պրոֆիլի խնդիրներ լուծելիս՝ համակարգչային նախագծման համակարգերի մշակում
(CAD), գույքագրման հսկողություն կամ օդային երթևեկության վերահսկում. այս մոտեցումը կարող է չափազանց սահմանափակ լինել:

Երկրորդ ճանապարհը դինամիկ կերպով օբյեկտներ ստեղծելն է հիշողության տարածքում, որը կոչվում է «կույտ» ( կույտ) Այս դեպքում օբյեկտների թիվը, դրանց ճշգրիտ տեսակները և կյանքի ժամկետը մնում են անհայտ մինչև ծրագրի մեկնարկը: Այս ամենը որոշվում է «թռիչքի վրա», երբ ծրագիրը աշխատում է: Եթե ​​ձեզ նոր օբյեկտ է անհրաժեշտ, ապա անհրաժեշտության դեպքում այն ​​պարզապես ստեղծում եք կույտի վրա: Քանի որ կույտը կառավարվում է դինամիկ կերպով, ծրագրի կատարման ընթացքում կույտից հիշողություն հատկացնելու համար շատ ավելի երկար է պահանջվում, քան հիշողության բաշխման ժամանակ: (Հիշողությունը կույտի վրա տեղաբաշխելու համար պահանջվում է ընդամենը մեկ մեքենայի հրահանգ, կույտի ցուցիչը ներքև տեղափոխելը և այն ազատելը կատարվում է այս ցուցիչը վերև տեղափոխելու միջոցով: Կույտի վրա հիշողություն հատկացնելու համար պահանջվող ժամանակը կախված է պահեստի կառուցվածքից):

Դինամիկ մոտեցումը ենթադրում է, որ օբյեկտները մեծ են և բարդ, ուստի հիշողության բաշխման և տեղաբաշխման համար պահանջվող լրացուցիչ ժամանակը էական ազդեցություն չի ունենա դրանց ստեղծման գործընթացի վրա: Այնուհետև լրացուցիչ ճկունությունը շատ կարևոր է ծրագրավորման հիմնական խնդիրների լուծման համար։

AT Javaօգտագործվում է միայն երկրորդ մոտեցումը Առանձնահատուկ դեպք են պարզունակ տեսակները, որոնք կքննարկվեն հաջորդիվ։. Հիմնաբառը օգտագործվում է ամեն անգամ, երբ ստեղծվում է օբյեկտ: նոր դինամիկ օրինակ կառուցելու համար:

Այնուամենայնիվ, կա ևս մեկ գործոն, այն է` օբյեկտի կյանքի տևողությունը: Այն լեզուներում, որոնք աջակցում են կույտի վրա օբյեկտների ստեղծմանը, կոմպիլյատորը որոշում է, թե ինչքան ժամանակ է օգտագործվում օբյեկտը և կարող է ինքնաբերաբար ոչնչացնել այն: Այնուամենայնիվ, երբ օբյեկտը ստեղծվում է կույտի վրա, կոմպիլյատորը պատկերացում չունի օբյեկտի կյանքի տևողության մասին: Նման լեզուներով C++, օբյեկտի ոչնչացումը պետք է հստակորեն շրջանակված լինի ծրագրում. եթե դա չկատարվի, հիշողության արտահոսք է տեղի ունենում (ծրագրերի ընդհանուր խնդիր C++) AT Javaկա մի մեխանիզմ, որը կոչվում է աղբահանություն; այն ավտոմատ կերպով հայտնաբերում է, երբ օբյեկտն այլևս չի օգտագործվում և ոչնչացնում է այն: Աղբահանը շատ հարմար է, քանի որ այն փրկում է ծրագրավորողին մեծ դժվարություններից: Ամենակարևորն այն է, որ աղբահանիչը ձեզ ավելի մեծ վստահություն է տալիս, որ հիշողության արտահոսքի նենգ խնդիրը չի ներթափանցել ձեր ծրագրում (որը բերել է մեկից ավելի նախագծեր: C++).

AT Javaաղբահավաքը նախագծված է այնպես, որ կարողանա ինքնուրույն լուծել հիշողությունը ազատելու խնդիրը (սա չի ազդում օբյեկտի կյանքի ավարտի այլ ասպեկտների վրա): Աղբահանը «գիտի», երբ օբյեկտն այլևս չի օգտագործվում և օգտագործում է իր գիտելիքները հիշողությունը ավտոմատ կերպով տեղաբաշխելու համար: Այս փաստի շնորհիվ (հետև այն փաստին, որ բոլոր օբյեկտները ժառանգում են մեկ բազային դասից Օբյեկտ և ստեղծվում են միայն կույտի վրա) Javaշատ ավելի հեշտ է, քան ծրագրավորումը C++. Մշակողը պետք է վերցնի ավելի քիչ որոշումներև հաղթահարել ավելի քիչ խոչընդոտներ:

Բացառությունների կառավարում. գործ ունենալ սխալների հետ

Ծրագրավորման լեզուների վաղ օրերից ի վեր սխալների հետ վարվելը եղել է ամենաբարդ թեմաներից մեկը: Սխալների հետ աշխատելու լավ մեխանիզմ մշակելը շատ դժվար է, ուստի շատ լեզուներ պարզապես անտեսում են այս խնդիրը՝ թողնելով այն ծրագրային գրադարանների մշակողներին: Վերջիններս տալիս են կիսատ լուծումներ, որոնք գործում են շատ իրավիճակներում, բայց հաճախ կարելի է պարզապես շրջանցել (սովորաբար դրանց վրա պարզապես ուշադրություն չդարձնելով): Բացառությունների հետ կապված բազմաթիվ մեխանիզմների հիմնական խնդիրն այն է, որ դրանք հիմնվում են ծրագրավորողի բարեխղճորեն հետևելու կանոններին, որոնք չեն կիրառվում լեզվով: Եթե ​​ծրագրավորողը անփույթ է, և դա հաճախ է պատահում, երբ աշխատանքը շտապում է, նա հեշտությամբ կարող է մոռանալ այդ մեխանիզմների մասին:

Բացառությունների մշակման մեխանիզմը ստեղծում է սխալների մշակումը հենց ծրագրավորման լեզվի մեջ կամ նույնիսկ օպերացիոն համակարգ. Բացառություն է համարվում այն ​​օբյեկտը, որը նետվում է սխալի վայրում, որը կարող է այնուհետև «բռնվել» համապատասխան բացառությունների մշակողի կողմից, որը նախատեսված է որոշակի տեսակի սխալների համար: Բացառությունների մշակումը, կարծես, սահմանում է ծրագրի կատարման զուգահեռ ուղի, որն ուժի մեջ է մտնում, երբ ինչ-որ բան չի ընթանում ըստ պլանի: Եվ քանի որ այն սահմանում է կատարման առանձին ուղի, սխալների մշակման կոդը չի խառնվում սովորական կոդի հետ: Սա հեշտացնում է ծրագրեր գրելը, քանի որ պետք չէ անընդհատ ստուգել հնարավոր սխալները: Բացի այդ, բացառությունը նման չէ մեթոդով վերադարձված թվային սխալի կոդի կամ խնդրահարույց իրավիճակի դեպքում սահմանված դրոշի, վերջինս կարելի է անտեսել։ Բացառությունը չի կարելի անտեսել, այն երաշխավորված է ինչ-որ տեղ կարգավորելու համար: Վերջապես, բացառությունները թույլ են տալիս վերականգնել ծրագրի բնականոն աշխատանքը սխալ գործողությունից հետո: Ծրագիրը պարզապես դադարեցնելու փոխարեն կարող եք շտկել իրավիճակը և շարունակել այն գործարկել; դրանով իսկ բարձրացնելով ծրագրի հուսալիությունը:

Բացառության բեռնաթափման մեխանիզմը Javaառանձնանում է մնացած լեզուներից, քանի որ այն ներկառուցվել է լեզվի մեջ հենց սկզբից և մշակողի պարտականությունն է օգտագործել այն: Սա սխալների մասին հայտնելու միակ ընդունելի միջոցն է: Եթե ​​դուք չեք գրում կոդ բացառությունների պատշաճ մշակման համար, ապա կոմպիլյացիայի ժամանակ կստանաք սխալ: Նման հետևողական մոտեցումը երբեմն մեծապես հեշտացնում է սխալների կառավարումը:

Հարկ է նշել, որ բացառությունների մշակումը օբյեկտի վրա հիմնված լեզվի հատկանիշ չէ, չնայած այս լեզուներում բացառությունը սովորաբար ներկայացված է օբյեկտով: Նման մեխանիզմ գոյություն ուներ նույնիսկ նախքան օբյեկտ-կողմնորոշված ​​լեզուների հայտնվելը։

Զուգահեռ ծրագրավորում

Ծրագրավորման հիմնարար հասկացություններից մեկը միաժամանակ բազմաթիվ գործեր անելու գաղափարն է: Շատ առաջադրանքներ պահանջում են, որ ծրագիրը ընդհատի իր ընթացիկ աշխատանքը, որոշ այլ խնդիր լուծի և հետո վերադառնա հիմնական գործընթացին: Խնդիրը լուծվել է տարբեր ձևերով.
Սկզբում ծրագրավորողները, ովքեր տիրապետում էին մեքենայի ճարտարապետությանը, գրում էին ընդհատումների մշակման ընթացակարգեր, այսինքն՝ հիմնական գործընթացի կասեցումը կատարվում էր ապարատային մակարդակով։ Այս լուծումը լավ էր աշխատում, բայց այն բարդ էր և ոչ շարժական, ինչը շատ ավելի դժվարացրեց նման ծրագրերի տեղափոխումը նոր տեսակի համակարգիչներ:

Երբեմն ընդհատումները իսկապես անհրաժեշտ են ժամանակի համար կարևոր առաջադրանքների գործողությունները մշակելու համար, բայց կա առաջադրանքների մի ամբողջ դաս, որտեղ պարզապես անհրաժեշտ է առաջադրանքը բաժանել մի քանի առանձին կատարվող մասերի, որպեսզի ծրագիրն ավելի արագ արձագանքի արտաքին ազդեցություններին: Ծրագրի այս առանձին կատարված մասերը կոչվում են հոսքեր, և ամբողջ սկզբունքը կոչվում է զուգահեռականություն(համաժամանակյա), կամ զուգահեռ հաշվարկ. Միաժամանակության ընդհանուր օրինակ է օգտագործողի միջերեսը: Թելային ծրագրում օգտագործողը կարող է սեղմել կոճակը և ստանալ արագ պատասխան՝ չսպասելով ծրագրի ավարտին ընթացիկ գործողությունը:

Սովորաբար, թելերը պարզապես սահմանում են, թե ինչպես է մեկ պրոցեսորի ժամանակը հատկացվում: Բայց եթե օպերացիոն համակարգը աջակցում է մի քանի պրոցեսորների, ապա յուրաքանչյուր շարանը կարող է վերագրվել առանձին պրոցեսորի; ահա թե ինչպես է ձեռք բերվում իրական զուգահեռությունը։ Զուգահեռության լավ առանձնահատկություններից մեկն այն է, որ լեզվի մակարդակով ծրագրավորողը կարիք չունի իմանալու, թե համակարգում կա մեկ կամ մի քանի պրոցեսոր: Ծրագիրը տրամաբանորեն բաժանված է թելերի, և եթե մեքենան ունի մեկից ավելի պրոցեսոր, այն ավելի արագ է աշխատում առանց որևէ հատուկ կարգավորումների:

Այս ամենից տպավորություն է ստեղծվում, որ հոսքերը շատ հեշտ են օգտագործել։ Բայց կա մի որսում՝ ընդհանուր ռեսուրսներ: Եթե ​​մի քանի թելեր փորձում են միաժամանակ մուտք գործել նույն ռեսուրսը, խնդիրներ են առաջանում: Օրինակ, երկու գործընթացները չեն կարող միաժամանակ տեղեկատվություն ուղարկել տպիչին: Կոնֆլիկտը կանխելու համար ընդհանուր ռեսուրսները (օրինակ՝ տպիչը) պետք է կողպված լինեն օգտագործման ընթացքում: The Thread-ը կողպում է ռեսուրսը, ավարտում է դրա գործողությունը, այնուհետև արձակում է կողպեքը, որպեսզի մեկ ուրիշը կարողանա մուտք գործել ռեսուրս:

Լեզվի մեջ ներկառուցված համաժամանակյա աջակցություն Java, և ելքի հետ Java SE5այն զգալի աջակցություն է ավելացրել գրադարանային մակարդակում:

Javaև ինտերնետ

Եթե Javaայլ ծրագրավորման լեզու է, հարց է առաջանում՝ ինչո՞ւ է այն այդքան կարևոր և ինչո՞ւ է այն ներկայացվում որպես հեղափոխական քայլ ծրագրային ապահովման մշակման գործում։ Ավանդական ծրագրավորման առաջադրանքների տեսանկյունից պատասխանն անմիջապես ակնհայտ չէ։ Չնայած լեզուն JavaՕգտակար է ինքնուրույն հավելվածներ կառուցելիս, դրա ամենակարևոր հավելվածը եղել և մնում է ցանցի ծրագրավորումը համաշխարհային ցանց.

Ի՞նչ է համացանցը:

Առաջին հայացքից համացանցը բավականին առեղծվածային է թվում նորաստեղծ տերմինների առատության պատճառով, ինչպիսիք են «ճամփորդել», «ներկայություն» և «հիմնական էջեր»: Հասկանալու համար, թե ինչ է սա, օգտակար է հասկանալ մեծ պատկերը, բայց նախ պետք է հասկանալ հաճախորդի/սերվերի համակարգերի փոխազդեցությունը, որոնք ամենաշատերից են: դժվար առաջադրանքներհամակարգչային հաշվարկ:

Հաճախորդի/Սերվերի հաշվարկ

Հաճախորդ/սերվեր համակարգերի հիմքում ընկած հիմնական գաղափարն այն է, որ դուք ունեք տեղեկատվության կենտրոնացված պահեստ, սովորաբար տվյալների բազայի տեսքով, և այդ տեղեկատվությունը տրամադրվում է մարդկանց որոշ խմբի կամ համակարգիչների խնդրանքով: Հաճախորդ/սերվեր համակարգում առանցքային դեր է խաղում տեղեկատվության կենտրոնացված պահեստը, որը սովորաբար թույլ է տալիս փոփոխել տվյալները այնպես, որ այդ փոփոխությունները տարածվեն տեղեկատվության օգտագործողներին: Բոլորը միասին՝ տեղեկատվության շտեմարան, ծրագրային ապահովում, որը տարածում է տեղեկատվություն, և համակարգիչը (համակարգիչները), որոնց վրա պահվում են ծրագրակազմն ու տվյալները, կոչվում է սերվեր։ Օգտագործողի մեքենայի ծրագրակազմը, որը շփվում է սերվերի հետ, ստանում է տեղեկատվությունը, մշակում այն ​​և այնուհետ պատշաճ կերպով ցուցադրում, կոչվում է հաճախորդ:

Այսպիսով, հաճախորդի/սերվերի հաշվարկման հիմնական հայեցակարգն այնքան էլ բարդ չէ: Խնդիրներն առաջանում են, քանի որ մեկ սերվերը միաժամանակ փորձում է սպասարկել բազմաթիվ հաճախորդների: Որպես կանոն, լուծման մեջ ներգրավված է տվյալների բազայի կառավարման համակարգը, և մշակողը փորձում է «օպտիմալացնել» տվյալների կառուցվածքը՝ դրանք բաշխելով աղյուսակներում: Բացի այդ, համակարգը հաճախ հաճախորդին թույլ է տալիս նոր տեղեկատվություն ավելացնել սերվերին: Իսկ դա նշանակում է, որ հաճախորդի նոր տեղեկատվությունը պետք է պաշտպանված լինի տվյալների բազայում պահպանման ընթացքում կորստից, ինչպես նաև այն այլ հաճախորդի տվյալների հետ վերագրանցելու հնարավորությունից։ (Սա կոչվում է գործարքների մշակում:) Երբ դուք փոխում եք հաճախորդի ծրագրակազմը, դուք պետք է ոչ միայն այն կազմեք և փորձարկեք, այլև տեղադրեք հաճախորդի մեքենաների վրա, ինչը կարող է լինել շատ ավելի դժվար և թանկ, քան դուք կարող եք մտածել: Հատկապես դժվար է կազմակերպել աջակցություն բազմաթիվ տարբեր օպերացիոն համակարգերի և համակարգչային ճարտարապետության համար: Ի վերջո, անհրաժեշտ է հաշվի առնել ամենակարեւոր գործոնըսերվերը կարող է միաժամանակ ստանալ հարյուրավոր հարցումներ, և ամենափոքր ուշացումը սպառնում է լուրջ հետևանքներով: Լատենտությունը նվազեցնելու համար ծրագրավորողները փորձում են բաշխել հաշվարկները, հաճախ նույնիսկ հաճախորդի մեքենայի վրա, իսկ երբեմն դրանք փոխանցելով լրացուցիչ սերվերային մեքենաներ՝ օգտագործելով այսպես կոչված. միջին ծրագրակազմ (միջին ծրագրակազմ) (Պրոքսի ծրագրերը նաև հեշտացնում են ծրագրերի պահպանումը:)

Մարդկանց միջև տեղեկատվության տարածման պարզ գաղափարն ունի իր իրականացման բարդության այնքան մակարդակ, որ, ընդհանուր առմամբ, դրա լուծումն անհասանելի է թվում: Եվ այնուամենայնիվ, դա կենսական նշանակություն ունի. ծրագրավորման բոլոր առաջադրանքների մոտ կեսը հիմնված է դրա վրա: Այն ներգրավված է խնդիրների լուծման մեջ՝ սկսած պատվերի մշակումից և կրեդիտ քարտով գործարքներից մինչև բոլոր տեսակի տվյալների տարածում՝ գիտական, պետական, բաժնետոմսերի գնանշումներ... ցանկն անվերջ է: Նախկինում յուրաքանչյուր նոր առաջադրանքի համար պետք է առանձին լուծում ստեղծեիր: Այս լուծումները հեշտ չէ ստեղծել, նույնիսկ ավելի դժվար է օգտագործել, և օգտագործողը պետք է սովորեր նոր ինտերֆեյս յուրաքանչյուր նոր ծրագրի հետ: Հաճախորդի/սերվերի հաշվարկման խնդիրն ավելի լայն մոտեցում է պահանջում:

Վեբը նման է հսկա սերվերի

Փաստորեն, վեբը մեկ հսկայական հաճախորդ/սերվեր համակարգ է: Այնուամենայնիվ, սա դեռ ամենը չէ. միասնական ցանցբոլոր սերվերները և հաճախորդները գոյակցում են միաժամանակ: Այնուամենայնիվ, այս փաստը չպետք է հետաքրքրի ձեզ, քանի որ սովորաբար դուք միանում և շփվում եք միայն մեկ սերվերի հետ (նույնիսկ եթե այն պետք է փնտրեք ամբողջ աշխարհում):

Սկզբում օգտագործվում էր տեղեկատվության պարզ միակողմանի փոխանակում: Դուք հարցում եք կատարել սերվերին, այն ձեզ ուղարկել է ֆայլ, որը ձեր դիտող ծրագիրը (այսինքն՝ հաճախորդը) մշակել է ձեզ համար։ Բայց շուտով սերվերից պարզապես ստատիկ էջեր ստանալը բավարար չէր: Օգտատերերը ցանկանում էին լիարժեք օգտվել հաճախորդի/սերվերի համակարգից, հաճախորդից տեղեկատվություն ուղարկել սերվերին, օրինակ՝ թերթելու սերվերի տվյալների բազան, սերվերին նոր տեղեկատվություն ավելացնելու կամ պատվերներ տեղադրելու համար (որը պահանջում էր անվտանգության հատուկ միջոցներ) . Մենք անընդհատ նկատում ենք այս փոփոխությունները վեբ մշակման գործընթացում:

Վեբ զննարկման գործիքները (բրաուզերները) մեծ առաջընթաց էին. նրանք ներմուծեցին տեղեկատվության հասկացությունը, որը նույն կերպ ցուցադրվում է ցանկացած տեսակի համակարգչի վրա։ Այնուամենայնիվ, առաջին բրաուզերները դեռ պարզունակ էին և արագ դադարեցին բավարարել պահանջները: Պարզվեց, որ դրանք առանձնապես ինտերակտիվ չեն և դանդաղեցրել են ինչպես սերվերների, այնպես էլ ամբողջ ինտերնետի աշխատանքը. ցանկացած գործողության համար, որը պահանջում է ծրագրավորում, պետք է տեղեկատվություն ուղարկել սերվերին և սպասել, որ այն մշակի: Երբեմն ստիպված էիր մի քանի րոպե սպասել միայն, որպեսզի պարզես, որ հարցումից մեկ տառ ես բաց թողել: Քանի որ զննարկիչը միայն դիտող էր, այն չէր կարող կատարել նույնիսկ ամենապարզ ծրագրավորման առաջադրանքները: (Մյուս կողմից, սա երաշխավորում է անվտանգությունը. օգտագործողը պաշտպանված էր վիրուսներ կամ սխալներ պարունակող ծրագրերի գործարկումից):

Այս խնդիրների լուծման համար կիրառվել են տարբեր մոտեցումներ։ Սկզբից, գրաֆիկական ցուցադրման ստանդարտները բարելավվել են, որպեսզի բրաուզերները կարողանան ցուցադրել անիմացիաներ և տեսանյութեր: Մնացած առաջադրանքները պահանջում էին հաճախորդի մեքենայի վրա՝ բրաուզերի ներսում ծրագրեր գործարկելու հնարավորություն: Սա կոչվում է հաճախորդի կողմից ծրագրավորում:

Հաճախորդի կողմից ծրագրավորում

Սկզբում սերվեր-բրաուզեր փոխազդեցության համակարգը նախատեսված էր ինտերակտիվ բովանդակության համար, սակայն այս ինտերակտիվության աջակցությունն ամբողջությամբ վստահված էր սերվերին: Սերվերը ստեղծեց ստատիկ էջեր հաճախորդի բրաուզերի համար, որը պարզապես մշակեց և ցուցադրեց դրանք: Ստանդարտ HTMLաջակցում է ամենապարզ մուտքագրումները՝ տեքստային դաշտեր, ռադիո կոճակներ, վանդակներ, ցուցակներ և բացվող պատուհաններ, ինչպես նաև կոճակներ, որոնք կարող են անել միայն երկու բան՝ վերակայել ձևի տվյալները և ուղարկել դրանք սերվերին: Ուղարկված տեղեկատվությունը մշակվում է ինտերֆեյսի կողմից CGI (ընդհանուր դարպասի միջերես), աջակցվում է բոլոր վեբ սերվերների կողմից: Հարցման տեքստը ցույց է տալիս CGIինչպես վարվել տվյալների հետ: Ամենից հաճախ, ըստ պահանջի, ծրագիր է գործարկվում սերվերի cgi-bin գրացուցակից: (Բրաուզերում էջի հասցեի տողում, ձևի տվյալները ներկայացնելուց հետո, երբեմն կարող եք տեսնել ենթատողը նիշերի խառնաշփոթի մեջ. cgi-bin.) Նման ծրագրերը կարելի է գրել գրեթե բոլոր լեզուներով։ Սովորաբար օգտագործվող Պերլ, քանի որ այն ուղղված է տեքստին և նաև մեկնաբանվող լեզու է, հետևաբար այն կարող է օգտագործվել ցանկացած սերվերի վրա՝ անկախ պրոցեսորի տեսակից կամ օպերացիոն համակարգից։ Այնուամենայնիվ, լեզուն Պիթոն(Իմ սիրելի լեզուն - գնալ www.Python.org) աստիճանաբար նրանից հետ է գրավում «տարածք» իր հզորության և պարզության շնորհիվ։

Շատ հզոր վեբ սերվերներ այսօր գործում են ամբողջությամբ հիմնված CGI; սկզբունքորեն այս տեխնոլոգիան թույլ է տալիս լուծել գրեթե ցանկացած խնդիր: Այնուամենայնիվ, վեբ սերվերները կառուցված են CGIծրագրերը դժվար է պահպանել և ունեն արձագանքման խնդիրներ: Արձագանքման ժամանակը CGI-Ծրագիրը կախված է ուղարկված տեղեկատվության քանակից, ինչպես նաև սերվերի և ցանցի ծանրաբեռնվածությունից: (Նշված բոլոր գործարկման պատճառով CGIծրագիրը կարող է երկար տևել): Համացանցի վաղ դիզայներները չէին կանխատեսում, թե որքան արագ կսպառվեն համակարգի ռեսուրսները, քանի որ այն օգտագործվում էր տարբեր ծրագրերում: Օրինակ, դրանում իրական ժամանակի գրաֆիկներ ցուցադրելը գրեթե անհնար է, քանի որ իրավիճակի ցանկացած փոփոխության դեպքում անհրաժեշտ է կառուցել նոր GIF ֆայլ և փոխանցել այն հաճախորդին: Անկասկած, դուք ունեցել եք ձեր սեփական դառը փորձառությունները, օրինակ՝ պարզապես ձևի տվյալները ներկայացնելուց: Դուք սեղմում եք կոճակը՝ տեղեկատվություն ուղարկելու համար; սերվերը սկսվում է CGI- ծրագիր, որը հայտնաբերում է սխալ, առաջացնում HTML- էջ, որը պատմում է ձեզ այդ մասին, այնուհետև ուղարկում է այս էջը ձեր ուղղությամբ. դուք պետք է նորից մուտքագրեք տվյալները և նորից փորձեք: Սա ոչ միայն դանդաղ է, այլ պարզապես անէլեգանտ է:

Խնդիրը լուծվում է հաճախորդի կողմից ծրագրավորմամբ: Որպես կանոն, բրաուզերներն աշխատում են հզոր համակարգիչների վրա, որոնք ունակ են լուծելու խնդիրների լայն շրջանակ և ստանդարտ մոտեցմամբ՝ հիմնված HTMLհամակարգիչը պարզապես սպասում է հաջորդ էջին սպասարկվելուն: Հաճախորդի կողմից ծրագրավորմամբ զննարկիչին տրվում է այն ամբողջ աշխատանքը, որը կարող է անել, և օգտագործողի համար դա թարգմանվում է ավելի արագ վեբ զննարկման և ավելի լավ ինտերակտիվության:

Այնուամենայնիվ, հաճախորդի ծրագրավորման քննարկումը շատ չի տարբերվում ընդհանրապես ծրագրավորման մասին քննարկումներից: Պայմանները նույնն են, բայց հարթակները տարբեր են. զննարկիչը նման է խիստ կրճատված օպերացիոն համակարգի: Դուք պետք է ամեն դեպքում ծրագրավորեք, այնպես որ հաճախորդի կողմից ծրագրավորումը ստեղծում է խնդիրների և լուծումների գլխապտույտ զանգված: Այս բաժինը եզրափակվում է հաճախորդի կողմից ծրագրավորմանը բնորոշ որոշ խնդիրների և մոտեցումների ակնարկով:

Ընդլայնման մոդուլներ

Հաճախորդների ծրագրավորման ամենակարևոր ոլորտներից մեկը դարձել է ընդլայնման մոդուլների մշակումը ( plug-ins) Այս մոտեցումը թույլ է տալիս ծրագրավորողին ավելացնել նոր ֆունկցիոնալություն բրաուզերի մեջ՝ ներբեռնելով փոքր ծրագիր, որը ներկառուցված է բրաուզերում: Փաստորեն, այս պահից բրաուզերը ձեռք է բերում նոր գործառույթ։ (Ընդլայնման մոդուլը բեռնվում է միայն մեկ անգամ:) Փլագինները բրաուզերներին տվել են մի շարք արագ և հզոր նորամուծություններ, բայց նման մոդուլ գրելը հեշտ գործ չէ, և դժվար թե ամեն անգամ նոր կայք ստեղծելիս ցանկանաք ընդլայնումներ ստեղծել: Հաճախորդների ծրագրավորման համար plug-ins-ի արժեքն այն է, որ դրանք փորձառու ծրագրավորողին թույլ են տալիս նոր հնարավորություններ ավելացնել բրաուզերում՝ առանց դրա ստեղծողից թույլտվություն խնդրելու: Այսպիսով, ընդլայնման մոդուլները ապահովում են «հետին դուռ»՝ հաճախորդի կողմից նոր ծրագրավորման լեզուների ինտեգրման համար (չնայած ոչ բոլոր լեզուներն են ներդրված նման մոդուլներում):

Սցենարների լեզուներ

Փլագինների զարգացումը առաջացրել է բազմաթիվ սկրիպտային լեզուներ: Օգտագործելով սկրիպտավորման լեզու, դուք ուղղակիորեն տեղադրում եք հաճախորդի ծրագիրը HTML-էջ, և այն մոդուլը, որը մշակում է այս լեզուն, ավտոմատ կերպով ակտիվանում է այն դիտելիս: Սցենարների լեզուն սովորաբար բավականին հեշտ է սովորել. ըստ էության, սցենարի կոդը տեքստն է, որը մաս է կազմում HTML-էջեր, այնպես որ այն շատ արագ բեռնվում է որպես սերվերին ուղղված մեկ հարցման մաս էջի բեռնման ժամանակ: Դրա գինն այն է, որ յուրաքանչյուրը կարող է դիտել (և գողանալ) ձեր կոդը: Այնուամենայնիվ, քիչ հավանական է, որ դուք նմանակված և բարդ բան գրեք սկրիպտային լեզուներով, ուստի կոդերի պատճենման խնդիրն այնքան էլ վատ չէ:

Սկրիպտավորման լեզու, որն աջակցվում է գրեթե ցանկացած բրաուզերի կողմից՝ առանց լրացուցիչ մոդուլներ տեղադրելու JavaScript(շատ քիչ ընդհանրություններ ունեն Java; անունը օգտագործվել է հաջողության մի կտոր «բռնելու» համար Javaշուկայում): Ցավոք, օրիգինալ իրականացում JavaScriptտարբեր բրաուզերներում բավականին տարբեր էին միմյանցից և նույնիսկ նույն բրաուզերի տարբեր տարբերակների միջև: Ստանդարտացում JavaScript-ի ձևով ECMAScriptօգտակար էր, բայց ժամանակ պահանջվեց, որպեսզի դրա աջակցությունը հայտնվեր բոլոր բրաուզերներում (ի լրումն, ընկերությունը Microsoft-ըակտիվորեն քարոզում էին սեփական լեզուն VBScript, անորոշ կերպով նմանվող JavaScript) Ընդհանուր դեպքում մշակողը պետք է սահմանափակվի նվազագույն հնարավորություններով JavaScriptայնպես որ կոդը երաշխավորված է աշխատել բոլոր բրաուզերներում: Սխալների մշակման և վրիպազերծման կոդի վերաբերյալ JavaScript, ապա սա լավագույն դեպքում բարդ խնդիր է։ Միայն վերջերս մշակողները կարողացան ստեղծել իրական բարդ համակարգգրված է JavaScript(ընկերություն Google, սպասարկում Gmail), և դա պահանջում էր ամենաբարձր ոգևորությունն ու փորձը։

Սա ցույց է տալիս, որ բրաուզերներում օգտագործվող սկրիպտային լեզուները նախատեսված էին մի շարք հատուկ առաջադրանքների համար, հիմնականում՝ ավելի հարուստ և ինտերակտիվ գրաֆիկական ինտերֆեյս ստեղծելու համար ( GUI) Այնուամենայնիվ, սկրիպտավորման լեզուն կարող է օգտագործվել հաճախորդի ծրագրավորման առաջադրանքների 80%-ի համար: Ձեր խնդիրը կարող է լինել հենց այդ 80%-ի մեջ: Քանի որ սկրիպտային լեզուները հեշտ և արագ են ստեղծում ծրագրավորման կոդը, նախ պետք է հաշվի առնել հենց այդպիսի լեզուն, նախքան ավելի բարդ տեխնոլոգիական լուծումների անցնելը, ինչպիսիք են Java.

Java

Եթե ​​սկրիպտավորման լեզուները ստանձնում են հաճախորդի ծրագրավորման առաջադրանքների 80%-ը, ապա ո՞վ կարող է կարգավորել մնացած 20%-ը: Նրանց համար այսօր ամենատարածված լուծումն է Java. Այն ոչ միայն հզոր ծրագրավորման լեզու է, որը մշակված է անվտանգության, պլատֆորմի համատեղելիության և միջազգայնացման նկատառումներով, այլ նաև անընդհատ զարգացող գործիք է նոր առանձնահատկություններով և գրադարաններով, որոնք նրբագեղորեն համապատասխանում են ավանդական բարդ ծրագրավորման առաջադրանքներին՝ բազմաֆունկցիոնալ, տվյալների բազայի հասանելիություն, ցանցային ծրագրավորում և բաշխված հաշվարկ: Հաճախորդների ծրագրավորում Javaհանգում է հավելվածների մշակմանը, ինչպես նաև փաթեթի օգտագործմանը Java Web Start.

Հավելվածը մինի ծրագիր է, որը կարող է աշխատել միայն բրաուզերի ներսում: Ապլետները ավտոմատ կերպով բեռնվում են որպես վեբ էջի մաս (նույն ձևով, որ, օրինակ, գրաֆիկական պատկերները բեռնվում են): Երբ ապլետը ակտիվանում է, այն գործարկում է ծրագիրը: Սա հավելվածի առավելություններից մեկն է. այն թույլ է տալիս ավտոմատ կերպով սերվերից ծրագրեր բաժանել հաճախորդներին հենց այն ժամանակ, երբ օգտագործողին անհրաժեշտ են այդ ծրագրերը, և ոչ նախկինում: Օգտագործողը ստանում է հաճախորդի ծրագրի վերջին տարբերակը՝ առանց վերատեղադրման հետ կապված որևէ խնդիրների և դժվարությունների: Ըստ գաղափարախոսության Java, ծրագրավորողը ստեղծում է միայն մեկ ծրագիր, որն ավտոմատ կերպով աշխատում է բոլոր համակարգիչների վրա, որոնք ունեն ներկառուցված թարգմանիչով բրաուզերներ։ Java. (Սա ճիշտ է գրեթե բոլոր համակարգիչների համար:) Քանի որ Javaամբողջական ծրագրավորման լեզու է, հնարավորինս շատ աշխատանքը պետք է կատարվի հաճախորդի կողմից սերվերին զանգահարելուց առաջ (կամ հետո): Օրինակ, ձեզ հարկավոր չէ ինտերնետով հարցում ուղարկել՝ պարզելու, որ ստացված տվյալների կամ որոշ պարամետրերի մեջ սխալ կա, և հաճախորդի համակարգիչը կարող է արագ գծել ինչ-որ գրաֆիկ՝ չսպասելով, որ սերվերը դա անի և հետ ուղարկել պատկերի ֆայլը: Այս սխեման ոչ միայն ապահովում է արագության և արձագանքման անմիջական առավելություն, այլև նվազեցնում է հիմնական ցանցային տրանսպորտի և սերվերների ծանրաբեռնվածությունը՝ կանխելով ինտերնետի ընդհանուր փորձի դանդաղումը:

Այլընտրանքային տարբերակներ

Անկեղծ ասած, applets Javaչի արդարացրել սկզբնական ոգեւորությունը. Առաջին հայտնվելիս Javaբոլորը շատ ոգևորված էին հավելվածներով, քանի որ դրանք թույլ էին տալիս լուրջ ծրագրավորում հաճախորդի կողմից, բարձրացնում էր արձագանքման հնարավորությունը և նվազեցնում ինտերնետ հավելվածների թողունակությունը: Ապլետներին կանխատեսվում էր մեծ ապագա:

Իրոք, համացանցում կարելի է գտնել մի շարք շատ հետաքրքիր հավելվածներ: Եվ այնուամենայնիվ զանգվածային անցումը ապլեթներին տեղի չունեցավ։ Երևի հիմնական խնդիրն այն էր, որ 10 ՄԲ փաթեթը ներբեռնելը միջավայրը տեղադրելու համար Java Runtime Environment (JRE)չափազանց սարսափելի է սովորական օգտագործողի համար: Այն փաստը, որ ընկերությունը Microsoft-ըչի միացել JREառաքման մեջ Internet Explorer, վերջապես որոշեց ապլետների ճակատագիրը։ Ինչևէ, ապլետներ Javaլայնորեն չեն կիրառվել։

Այնուամենայնիվ, հավելվածներ և հավելվածներ Java Web Startշատ օգտակար են որոշ իրավիճակներում: Եթե ​​վերջնական օգտագործողի համակարգիչների կոնֆիգուրացիան վերահսկվում է (օրինակ, կազմակերպություններում), ապա այս տեխնոլոգիաների օգտագործումը հաճախորդի հավելվածները բաշխելու և թարմացնելու համար միանգամայն արդարացված է. այն խնայում է շատ ժամանակ, աշխատուժ և գումար (հատկապես հաճախակի թարմացումներով):

.NET և C#

Որոշ ժամանակ գլխավոր հավակնորդ Java-ապլետները համարվում էին բաղադրիչներ ActiveXընկերությունից Microsoft-ը, չնայած նրանք իրենց աշխատանքի համար պահանջում էին ներկայություն հաճախորդի մեքենայի վրա Windows. Հիմա Microsoft-ըհակադրվել է Javaլիիրավ մրցակիցներ. դա հարթակ է .NETև ծրագրավորման լեզու #-ից. Հարթակ .NETմոտավորապես նույնն է, ինչ վիրտուալ մեքենան Java(JVM) և գրադարաններ Java, և լեզուն #-իցհստակ նմանություն ունի լեզվին Java. Անկասկած, սա լավագույնն է, որ ստեղծել է Microsoft-ը ծրագրավորման լեզուների և միջավայրերի ոլորտում։ Իհարկե, մշակողները Microsoft-ըորոշակի առավելություն ուներ; նրանք դա տեսել են Javaհաջողվեց, և ինչը չհաջողվեց, և կարող էր հիմնվել այս փաստերի վրա, բայց արդյունքը բավականին արժանի էր: Իր ծնունդից ի վեր առաջին անգամ. Javaիսկական մրցակից կար. Մշակողները՝ սկսած Արևպետք էր նայել #-ից, պարզեք, թե ինչու ծրագրավորողները կարող են ցանկանալ անցնել այս լեզվին և ամեն ջանք գործադրել լրջորեն կատարելագործվելու համար Javaմեջ Java SE5.

AT այս պահինՀիմնական հարցն այն է, թե արդյոք Microsoft-ը թույլ կտա ամբողջական տեղափոխում .NETդեպի այլ հարթակներ: AT Microsoft-ըպնդում են, որ այս հարցում խնդիր չկա, և նախագիծը մոնո ()ապահովում է մասնակի իրականացում .NETհամար Linux. Սակայն, քանի որ այս իրականացումն առայժմ թերի է Microsoft-ըչի որոշում դրա որևէ մասը դուրս նետել, խաղադրույք կատարել .NETքանի որ միջպլատֆորմային տեխնոլոգիան դեռ վաղ է:

Ինտերնետ և ինտրանետ

Վեբն ապահովում է հաճախորդի/սերվերի առաջադրանքների ամենաընդհանուր լուծումը, ուստի իմաստ ունի օգտագործել նույն տեխնոլոգիան կոնկրետ խնդիրներ լուծելու համար. սա հատկապես ճիշտ է ընկերության ներսում հաճախորդի/սերվերի դասական փոխգործակցության համար: Հաճախորդ/սերվերի ավանդական մոտեցումը խնդիրներ ունի հաճախորդի համակարգիչների տեսակների տարբերությունների հետ կապված՝ դրանց ավելացնելով հաճախորդների համար նոր ծրագրեր տեղադրելու դժվարությունը. երկու խնդիրներն էլ լուծվում են բրաուզերների և հաճախորդի կողմից ծրագրավորման միջոցով: Երբ վեբ տեխնոլոգիան օգտագործվում է ընկերության ներսում տեղեկատվական ցանց ստեղծելու համար, նման ցանցը կոչվում է ինտրանետ: Ինտրանետներն ապահովում են շատ ավելի անվտանգություն, քան ինտերնետը, քանի որ դուք կարող եք ֆիզիկապես վերահսկել մուտքը ձեր ընկերության սերվերներ: Սովորելու առումով բրաուզերի հասկացությունից հասկացողին շատ ավելի հեշտ է հասկանալ տարբեր էջեր և հավելվածներ, որպեսզի կրճատվի նոր համակարգերի տիրապետման ժամանակը:

Անվտանգության խնդիրը մեզ բերում է այն ուղղություններից մեկը, որն ինքնաբերաբար առաջանում է հաճախորդի ծրագրավորման մեջ: Եթե ​​ձեր ծրագիրն աշխատում է ինտերնետում, ուրեմն չգիտեք, թե ինչ հարթակում է այն գործելու։ Հատուկ ուշադրություն պետք է դարձնել սխալ ծածկագրի տարածումից խուսափելու համար: Այստեղ մեզ անհրաժեշտ են միջպլատֆորմային և անվտանգ լուծումներ, ինչպիսիք են Javaկամ սցենարի լեզու:

Ինտրանետներն ունեն այլ սահմանափակումներ: Շատ հաճախ ցանցի բոլոր մեքենաներն աշխատում են հարթակի վրա Intel/Windows. Ինտրանետում դուք պատասխանատու եք ձեր կոդի որակի համար և կարող եք շտկել սխալները, երբ դրանք գտնվեն: Բացի այդ, դուք կարող եք արդեն ունենալ լուծումների հավաքածու, որոնք ապացուցված են, որ աշխատում են ավելի ավանդական հաճախորդի/սերվերի համակարգերում, մինչդեռ յուրաքանչյուր թարմացումով նոր ծրագրակազմը պետք է ձեռքով տեղադրվի հաճախորդի մեքենայի վրա: Թարմացումների վրա ծախսված ժամանակը ամենաուժեղ փաստարկն է հօգուտ բրաուզերի տեխնոլոգիաների, որտեղ թարմացումները կատարվում են անտեսանելի և ավտոմատ կերպով (նույնը կարելի է անել Java Web Start) Եթե ​​դուք ներգրավված եք ներքին ցանցի պահպանման մեջ, ավելի խելամիտ է գնալ այն ճանապարհով, որը թույլ է տալիս օգտագործել այն, ինչ արդեն ունեք՝ առանց ծրագրերը նոր լեզուներով վերաշարադրելու:

Երբ բախվում ենք հաճախորդի ծրագրավորման առաջադրանքների հսկայական ծավալին, որոնք կարող են խանգարել ցանկացած դիզայների, ավելի լավ է գնահատել դրանք ծախս/օգուտ հարաբերակցությամբ: Հաշվի առեք ձեր խնդրի սահմանափակումները և փորձեք պատկերացնել այն լուծելու ամենակարճ ճանապարհը։ Քանի որ հաճախորդի ծրագրավորումը դեռևս ծրագրավորում է, զարգացման տեխնոլոգիաները, որոնք խոստանում են ամենաարագ լուծումը, միշտ տեղին են: Այս նախաձեռնողական վերաբերմունքը ձեզ հնարավորություն կտա պատրաստվել ծրագրավորման անխուսափելի խնդիրներին։

Սերվերի կողմից ծրագրավորում

Մեր քննարկումը շրջանցել է սերվերային ծրագրավորման թեման, որը շատերն ամենաշատն են համարում ուժեղ կետ Java. Ի՞նչ է պատահում, երբ հարցում եք ուղարկում սերվերին: Ավելի հաճախ, քան ոչ, հարցումը հանգում է պարզ «ուղարկիր ինձ այս ֆայլը» հարցմանը: Այնուհետև զննարկիչը պատշաճ կերպով մշակում է ֆայլը HTML- Էջի հավանում նկարը Java-ապլետ, սցենարի նման և այլն:

Սերվերին ուղղված ավելի բարդ հարցումը սովորաբար ներառում է տվյալների բազա մուտք գործելը: Ամենատարածված դեպքում պահանջվում է տվյալների բազայի համալիր որոնում, որի արդյունքներն այնուհետև սերվերի կողմից վերածվում են HTML-էջը և ուղարկում է ձեզ: (Իհարկե, եթե հաճախորդը ի վիճակի է կատարել որոշակի գործողություն՝ օգտագործելով Javaկամ սկրիպտավորման լեզու, տվյալները կարող են մշակվել նրա կողմից, որն ավելի արագ կլինի և կնվազեցնի սերվերի ծանրաբեռնվածությունը:) Կամ գուցե անհրաժեշտ լինի գրանցվել տվյալների բազայում, երբ միանում եք խմբին, կամ վճարումը, որը կպահանջի տվյալների բազայի փոփոխություններ: Նման հարցումները պետք է մշակվեն սերվերի որոշ կոդով. Ընդհանրապես, սա այն է, ինչ կոչվում է սերվերային ծրագրավորում: Ավանդաբար սերվերի ծրագրավորումն իրականացվում էր վրա Պերլ, Պիթոն, C++կամ այլ լեզու, որը թույլ է տալիս ստեղծել ծրագրեր CGI, բայց ավելի հետաքրքիր տարբերակներ կան։ Դրանք ներառում են նրանք, որոնք հիմնված են Javaվեբ սերվերներ, որոնք թույլ են տալիս կատարել սերվերի կողմից ծրագրավորում Javaօգտագործելով այսպես կոչված սերվիլետներ: Սերվլետները և նրանց սերունդները JSP-ներ, երկու հիմնական պատճառներն են, թե ինչու են վեբ բովանդակության ընկերությունները շարժվում դեպի Java, հիմնականում այն ​​պատճառով, որ դրանք լուծում են բրաուզերների անհամատեղելիության խնդիրները:

Չնայած բոլոր խոսակցություններին Javaորպես ինտերնետ ծրագրավորման լեզու, Javaիրականում դա ծրագրավորման լիարժեք լեզու է, որն ընդունակ է լուծել այլ լեզուներով լուծված գրեթե բոլոր խնդիրները։ Առավելությունները Javaչեն սահմանափակվում լավ շարժականությամբ. դա ծրագրավորման խնդիրների լուծման համար հարմարություն է, սխալների դիմադրություն, մեծ ստանդարտ գրադարան և երրորդ կողմի բազմաթիվ զարգացումներ՝ և՛ գոյություն ունեցող, և՛ մշտապես առաջացող:

Ամփոփում

Դուք գիտեք, թե ինչ տեսք ունի ընթացակարգային ծրագիրը՝ տվյալների սահմանումներ և ֆունկցիաների կանչեր: Նման ծրագրի նպատակը պարզելու համար անհրաժեշտ է ջանք գործադրել՝ դիտելով գործառույթները և ձեր մտքում մեծ պատկեր ստեղծելով: Հենց դրա պատճառով է, որ նման ծրագրերի ստեղծումը պահանջում է միջանկյալ գործիքների օգտագործում. ինքնին դրանք ավելի շատ ուղղված են համակարգչին, այլ ոչ թե լուծվող խնդրին:

Քանի որ OOP-ը շատ նոր հասկացություններ է ավելացնում ընթացակարգային լեզուներով արդեն հասանելիներին, բնական է ենթադրել, որ կոդը Javaկլինի շատ ավելի բարդ, քան ընթացակարգային լեզվի նմանատիպ մեթոդը: Բայց այստեղ ձեզ սպասվում է հաճելի անակնկալ՝ լավ գրված ծրագիր Javaսովորաբար շատ ավելի հեշտ է հասկանալ, քան դրա ընթացակարգային գործընկերը: Այն ամենը, ինչ դուք տեսնում եք, օբյեկտների սահմանումներ են, որոնք ներկայացնում են որոշումների տարածության հասկացությունները (ոչ համակարգչային իրականացման հայեցակարգերը), և հաղորդագրություններ, որոնք ուղարկվում են այն օբյեկտներին, որոնք ներկայացնում են այդ տարածության գործողություններ: OOP-ի առավելություններից մեկն այն է, որ լավ մշակված ծրագիրը կարելի է հասկանալ պարզապես սկզբնաղբյուրը նայելով: Բացի այդ, դուք սովորաբար պետք է շատ ավելի քիչ կոդ գրեք, քանի որ շատ խնդիրներ արդեն հեշտությամբ կարող են լուծվել: առկա գրադարաններըդասեր.

Օբյեկտ-կողմնորոշված ​​ծրագրավորում և լեզու Javaբոլորի համար հարմար չեն. Շատ կարևոր է նախ պարզել ձեր կարիքները, որպեսզի որոշեք, թե արդյոք անցնելու եք Javaկամ ավելի լավ է ընտրել այլ ծրագրավորման համակարգ (ներառյալ այն, որը ներկայումս օգտագործում եք): Եթե ​​գիտեք, որ տեսանելի ապագայում ձեզ կկանգնեն շատ կոնկրետ կարիքներ կամ ձեր աշխատանքը կենթարկվի սահմանափակումների, Javaչի հաղթահարում, ավելի լավ է դիտարկել այլ հնարավորություններ (մասնավորապես, ես խորհուրդ եմ տալիս ավելի մոտիկից նայել լեզվին Պիթոն,) Ընտրելով Java, դուք պետք է հասկանաք, թե ինչ այլ տարբերակներ կան և ինչու եք ընտրել այս ճանապարհը:

Հաղորդագրությունների փոխանակում.

Ուղարկեք անմիջապես այս կողմին՝ http://website/javabooks/Thinking_in_Java_4th_edition.html Ուղարկեք BB կոդերը՝ Thinking_in_Java_4th_edition
html-հաղորդագրություն: