Ծրագրավորման DRY սկզբունք
Ծրագրավորման DRY (Don’t repeat yourself) սկզբունքը ենթադրում է մեծ համակարգի, օրինակ, ձեր մշակած ծրագրային ապահովման բաժանումը ավելի փոքր, չկրկնվող բաղադրիչների: Եթե ունեք մի քանի բաղադրիչներ, որոնք կատարում են նույն խնդիրները, ապա համաձայն DRY սկզբունքի պետք է նվազեցնել դրանց քանակը, իդեալական դեպքում, որպեսզի յուրաքանչյուր բաղադրիչ չկրկնվի:
Այն բանից հետո, երբ համակարգը բաժանվել է բաղադրիչների, որոնք պատասխանատու են հստակ սահմանված խնդիրների կատարման համար, դրանք կարելի է կազմակերպել դասերի մեջ, ինչը կոչվում է մոդուլային ճարտարապետություն:
Համակարգը DRY սկզբունքով ճիշտ կառուցելու համար անհրաժեշտ է պահպանել հետևյալ կանոնները:
- Նախքան նախագծի վրա աշխատանքը սկսելը պատկերացրեք այն գրաֆիկական սխեմայի տեսքով, բաժանված տեսողական բաղադրիչների:
- Նախագծի բարդ բաղադրիչի վրա աշխատելիս, այն նույնպես պետք է գրաֆիկորեն ներկայացնել UML դիագրամի կամ նմանատիպ միջոցների տեսքով:
- Գրաֆիկական սխեմայում պետք է հստակ նշել նախագծի յուրաքանչյուր բաղադրիչի հիերարխիան և դերը:
- Նաև սխեմայում պետք է նշել ձեր բաղադրիչների կապը նախագծի մյուս մասնակիցների բաղադրիչների հետ, ինչպես նաև թե նախագծի որ ճյուղերը կլինեն ընդհանուր կամ մասնավոր:
- Անհրաժեշտ է խուսափել կոշտ կապերից բաղադրիչների միջև, քանի որ դրանք բացասաբար են ազդում նախագծի ամբողջ ճարտարապետության արդյունավետության վրա:
Տես նաև
-
SOLIDսկզբունքը,
որը տալիս է առաջարկություններ օբյեկտային ուղղված ծրագրավորման հիման վրա -
KISSսկզբունքը,
որը ենթադրում է ծրագրային ապահովման բարդացումից հրաժարում -
YAGNIսկզբունքը,
որը ենթադրում է ծրագրային ապահովման ավելորդ ֆունկցիոնալությունից հրաժարում -
CQSսկզբունքը,
որը յուրաքանչյուր ֆունկցիայի համար սահմանում է միայն մեկ հրաման -
LoDսկզբունքը,
որը կիրառվում է ծրագրային ապահովման մշակման ժամանակ -
պատասխանատվության տարանջատման սկզբունքը,
որը կիրառվում է ծրագրային ապահովման մշակման ժամանակ