Օբյեկտ-կողմնորոշված ​​ծրագրավորման 10 սկզբունքներ, որոնք պետք է իմանա յուրաքանչյուր ծրագրավորող

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

Հիշեցում. Habr-ի բոլոր ընթերցողների համար՝ 10 ռուբլի զեղչ՝ Skillbox-ի ցանկացած դասընթացին գրանցվելիս՝ օգտագործելով Habr պրոմո կոդը:

Skillbox-ը խորհուրդ է տալիս. Ուսումնական առցանց դասընթաց «Java մշակող».

ՉՈՐ (Մի կրկնիր ինքդ քեզ)

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

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

Սա անհրաժեշտ է ծածկագիրը պարզեցնելու և դրա պահպանումը հեշտացնելու համար, ինչը OOP-ի հիմնական նպատակն է: Դուք նույնպես չպետք է չարաշահեք միությունը, քանի որ նույն կոդը ստուգում չի անցնի ինչպես OrderId-ի, այնպես էլ SSN-ի հետ:

Կափսուլացնող փոփոխություններ

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

Եթե ​​դուք գրում եք Java-ով, ապա լռելյայն նշանակել մասնավոր մեթոդներ և փոփոխականներ.

Բաց/փակ սկզբունք

Այս սկզբունքը կարելի է հեշտությամբ հիշել՝ կարդալով հետևյալ հայտարարությունը. «Ծրագրային սուբյեկտները (դասեր, մոդուլներ, գործառույթներ և այլն) պետք է բաց լինեն ընդլայնման համար, բայց փակ՝ փոփոխման համար»։ Գործնականում դա նշանակում է, որ նրանք կարող են թույլ տալ փոխել իրենց վարքագիծը՝ առանց սկզբնական կոդը փոխելու։

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

Ահա կոդի օրինակ, որը խախտում է այս սկզբունքը.

Եթե ​​Ձեզ անհրաժեշտ է ինչ-որ բան փոխել դրա մեջ, ապա դա շատ ժամանակ կպահանջի, քանի որ կոդի բոլոր բաժինները, որոնք կապ ունեն ցանկալի հատվածի հետ, պետք է փոխվեն:

Ի դեպ, բաց-փակությունը SOLID-ի սկզբունքներից է։

Միասնական պատասխանատվության սկզբունք (SRP)

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

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

Կախվածության ինվերսիայի սկզբունք (DIP)

Վերևում ներկայացված է կոդի օրինակ, որտեղ AppManager-ը կախված է EventLogWriter-ից, որն իր հերթին սերտորեն կապված է AppManager-ի հետ: Եթե ​​Ձեզ անհրաժեշտ է ծանուցում ցուցադրելու այլ եղանակ՝ լինի դա push, SMS կամ էլփոստ, դուք պետք է փոխեք AppManager դասը:

Խնդիրը կարող է լուծվել DIP-ի միջոցով: Այսպիսով, AppManager-ի փոխարեն մենք խնդրում ենք EventLogWriter, որը մուտքագրվելու է շրջանակի միջոցով:

DIP-ը հնարավորություն է տալիս հեշտությամբ փոխարինել առանձին մոդուլները ուրիշներով՝ փոխելով կախվածության մոդուլը: Սա հնարավորություն է տալիս փոխել մեկ մոդուլը՝ չազդելով մյուսների վրա:

Կազմը ժառանգության փոխարեն

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

Կոմպոզիցիան ձեզ հնարավորություն է տալիս փոխել դասի վարքագիծը գործարկման ժամանակ՝ սահմանելով դրա հատկությունները: Ինտերֆեյսներ իրականացնելիս օգտագործվում է պոլիմորֆիզմ, որն ավելի ճկուն իրականացում է տալիս։

Նույնիսկ Joshua Bloch-ի Effective Java-ն խորհուրդ է տալիս ընտրել կոմպոզիցիան ժառանգականից:

Բարբարա Լիսկովի փոխարինման սկզբունքը (LSP)

Մեկ այլ սկզբունք SOLID գործիքակազմից: Այն նշում է, որ ենթատիպերը պետք է փոխարինելի լինեն սուպերտիպին։ Այսինքն՝ մեթոդներն ու գործառույթները, որոնք աշխատում են սուպերդասի հետ, պետք է կարողանան աշխատել առանց խնդիրների նրա ենթադասերի հետ։

LSP-ն կապված է ինչպես միասնական պատասխանատվության սկզբունքի, այնպես էլ համատեղ պատասխանատվության սկզբունքի հետ: Եթե ​​դասը տրամադրում է ավելի շատ ֆունկցիոնալություն, քան ենթադասը, ապա վերջինս չի աջակցի որոշ գործառույթների՝ խախտելով այս սկզբունքը։

Ահա մի կոդ, որը հակասում է LSP-ին:

Տարածքը (Ուղղանկյուն r) մեթոդը հաշվարկում է ուղղանկյունի մակերեսը: Ծրագիրը կխափանվի Square-ի գործարկումից հետո, քանի որ Square-ն այստեղ ուղղանկյուն չէ: LSP սկզբունքի համաձայն, գործառույթները, որոնք օգտագործում են հղումներ բազային դասերի, պետք է կարողանան օգտագործել ստացված դասերի օբյեկտները՝ առանց լրացուցիչ հրահանգների։

Այս սկզբունքը, որը ենթատիպի հատուկ սահմանումն է, առաջարկվել է Բարբարա Լիսկովի կողմից 1987 թվականին «Տվյալների վերացում և հիերարխիա» խորագրով կոնֆերանսի հիմնական նոտայում, որտեղից էլ նրա անվանումը:

Ինտերֆեյսի բաժանման սկզբունք (ISP)

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

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

Քանի որ ինտերֆեյս գրելը բարդ խնդիր է, աշխատանքն ավարտելուց հետո այն փոխելը՝ առանց որևէ բան խախտելու, դժվարություն կլինի:

Java-ում ISP սկզբունքի առավելությունն այն է, որ բոլոր մեթոդները նախ պետք է իրականացվեն, և միայն դրանից հետո դրանք կարող են օգտագործվել դասերի կողմից։ Հետեւաբար, սկզբունքը հնարավորություն է տալիս նվազեցնել մեթոդների քանակը:

Ծրագրավորում ինտերֆեյսի համար, ոչ թե իրականացման

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

Դուք պետք է օգտագործեք ինտերֆեյսի տեսակը փոփոխականների, վերադարձի տեսակների կամ մեթոդի փաստարկի տեսակի համար: Օրինակ՝ SuperClass-ի օգտագործումը, քան SubClass-ը:

Այն է:

Ցուցակի համարներ= getNumbers();

Բայց չէ:

ArrayList թվեր = getNumbers();

Ահա վերը քննարկվածի գործնական իրականացումը:

Պատվիրակության սկզբունքը

Ընդհանուր օրինակը Java-ում հավասար() և hashCode() մեթոդներն են: Երբ անհրաժեշտ է համեմատել երկու օբյեկտ, այս գործողությունը պատվիրակվում է համապատասխան դասի փոխարեն հաճախորդին:

Սկզբունքի առավելությունն այն է, որ կոդի կրկնօրինակում չկա, և վարքագիծը փոխելը համեմատաբար պարզ է: Դա վերաբերում է նաև միջոցառումների պատվիրակությանը:

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

Skillbox-ը խորհուրդ է տալիս.

• Գործնական դասընթաց «Mobile Developer PRO».
• Կիրառական առցանց դասընթաց «Տվյալների վերլուծաբան Python-ում».
• Երկու տարվա գործնական դասընթաց «Ես վեբ ծրագրավորող PRO եմ».

Source: www.habr.com