Statik methodlar bilan yangi yozilgan eski kod (Instant legacy code with static methods).
Published: 2022-12-14 13:17:56

> _Disclaimer: Maqoladagi barcha so'zlar va fikrlar mening ancha vaqtdan buyon kuzatuvlarim natijasida hosil bo'lgan tahlillar hulosaasi va subyektiv fikrlarim. Har bir keltirilgan ma'lumot va faktlar barcha holatlarga mos kelishiga kafolat bermayman_

## Kirish
**Qisqacha izoh:** Ko'plab dasturlash tillari bir yoki birqancha dasturlash falsafalarini qo'llab quvvatlashi xozirgi kunda barchamizga ma'lum. Shu jumladan xozirgi davrga kelib dasturlash falsafalari yoki paradigmalari ham ancha muncha ko'payib ketdi. Tendensiyalar o'zgaryabti va texnalogiyalarda ham ancha evalution sodir bo'layabti. Avvalari dasturlashda compilerlar muammosi bo'lgan bo'lsa va buning yechimi C tili bo'lgan bo'lsa xozirgi zamonda tendensiya o'zgardi talab ham compilerga emas balki yaxshi kompozitsiya qilish mumkin bo'lgan falsafaga qaratila boshladi. Avvallari ASM C davrlarida falsafa muhim bo'lmagan bo'lsa xozirgi kunda falsafa yoki paradim muhimlik darajasi yuqoriga o'sib borayabti. 

### Nimaga ?
Biz eski bundan oldingi taxminan 90 yilar o'rtasini xisobga olsak u paytlar eng katta muammolardan biri resurs bo'lgan. Fizik resurslar xozirgidan ko'ra ancha muncha cheklangan bo'lgan shu qatori loyihalar hajmi ham unchalik keng qamrovli bo'lmagan. Shu sababdan tezlik va hajmga aloqador ko'rsatkichlar juda katta axamiyatga ega bo'lgan. Shu sababdan quality masalalariga juda ko'p etibor qilinmagan. Keyinchalik dasturlashda ham falsafa paradigmalar rivojlana boshladi. Boshqacha falsafaga asoslangan tillar paydo bo'ldi. Masalan Simula, Smalltalk ushbu tillar Object Oriented paradigmasining taqdim qilishdi. Tillar rivojlanishi bilan paralell ravishta texnalogiyalar ham ancha evolutionga uchradi. Huddi shunday loyihalar va ularning hajmi ham juda kattalashdi. Dasturchi engineerlar uchun code yozishdan boshqa bilim ko'nikmalar ham kerak bo'la boshladi. O'zi ishlatadigan tildan tashqari umumiy Paradigma fa dasturlash falsafalarini o'rganish kerak bo'ldi. Loyihaga ham birqancha kriteriyalarda talablar qo'yila boshlandi. Bir loyiha ustida yuzlab minglab insonlar ishlay boshlagandan keyin tendensiyalar ancha o'zgarib ketdi. 
Endi tarixni yegishtirib asosiy mavzuga qaytsak )). ASM va C kabi tillarni o'rniga nima uchun yangi tillar chiqdi ? Asosiy moxiyatlardan biri ushbu tillar kop energiya sarflanadigan va birmuncha murakkabroq. Shu bilan bir qatorda dasturlash va tillar rivojlanishining boshida communityning juda katta qismi bir tomonlama qarashgan yani procedurial. 

Procedurial programming haqida qisqacha:
Ushbu dasturlash paradigmasi biror ish jarayonida ketma ket ma'lum functionallar yordamida amalga oshirishga qaratilgan uslub. Bizga Algorithmlarni tushuntirishayotganda aytilganiday 

O'zbek tilida quyidagi tarifni eshitgan edim:

_"Algoritm – berilgan natijaga erishish uchun qilinishi kerak boʻlgan aniq koʻrsatmalar ketma-ketligi."_

Bazi manbalarda esa quyidagicha tariflangan:

_"Algoritm - bu muammoni hal qilish yoki hisoblash uchun ishlatiladigan protsedura. Algoritmlar apparat yoki dasturiy ta'minotga asoslangan tartiblarda ko'rsatilgan harakatlarni bosqichma-bosqich bajaradigan ko'rsatmalarning aniq ro'yxati sifatida ishlaydi. Algoritmlar ITning barcha sohalarida keng qo'llaniladi."_

Juda ham ko'plab tariflar mavjud va ularning katta qismida ushbu tariflar procedurial qarashlarni ilgari suryabti. 

Ho'sh nima muammo ? Procedurial programmingning nimasi yomon ?
Man ushbu paradigma va uning falsafasini tanqid qilishdan yoki argumentlarni keltirishdan oldin bir kichik manbani ulashishni xoxladim.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mqn0mxon6g2za1u274tg.png)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/97gugnh8m0e755z2j6pl.png)


Yuqoridagi rasmlarda [Linux kernel source code](https://github.com/torvalds/linux)

Loyiha aynan procedurial paradimg asosida qurilgan va juda ham katta Judayam ! Yuqorida 10 minglab qator yozilgan codelarni ko'rishingiz mumkin.

Loyihada biror o'zgarishlar qilish anchagina qiyin undan tashqari tushunish ham. Shu bilan birga loyihaga on boarding ham birmuncha mashaqqatli ish. Lekin lekin yuqorida aytilgandan procedurial programming paradigmlari implement qilingan va deyarli to'liq ushbu falsafa asosida qurilgan. Texnik jixatdan ushbu loyihani o'rtacha dasturchi qo'llab quvvatlashi yoki biror o'zgarish kiritishi anchagina qiyin masala. Ushbu dasturchi C tilini yaxshi bilgan taqdirda ham project hajmi kattaligi undagi filelar va linelar juda kattaligi sababdan support yoki contributing anchagina qiyin. Lekin source code yaxshiroq yozilgan ekanini ham eslatib o'tish o'rinli.

Procedurial programming falsafasi umumiy biror product ishlab chiqish nuqtai nazaridan ham ish bermay qo'ydi ayniqsa xozirgi zamonda. Bunga asosisy sabab procedurial decomposition. Yani protesudurial kompozitsiyalar va dizayn anchagina mashaqqatli va yaxshi kompozitsiya qilish deyarli ilojisiz masala. Chunki procedurial like compositionlarda focus biror bir procedureni amalga oshiradigan functionallarga asoslangan buyoqda esa resonsibilitylarni taqsimlash maintanable code yozish anchagina qiyin abstraktsiya anchagina past lekin xozirgi zamonda esa dasturlarda abstraktsiya darajasi yuqorilashib borayabti. Xozir aspect oriented yechimlar kop tomonlama o'zini oqlab kelayabti. Bu kabi muammolarni project kattalashganida va uni contributorlari ko'payganida sezish mumkin. Yuqoridagi Linux kernel ham aynan shu maqsadda share qilindi. Pure functional yoki procedurial falsafalar juda ko'p holatlarda kengayish qo'llab quvvatlash imkoniyatlarini kamayishiga sabab bo'ladi.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oeczqiymeb43nl810iyb.png)

### Static methodlar anti pattern.

Static methodlarning anti pattern ekaniga eng asosiy sabablardan bir bu OOP ning eng asosiy prinspi bo'lmish Encapsulation buzulishi xisoblanadi. Procedurial yoki functional programmingda ko'proq functionlar ishlasa functionlar functionlarni ishlatsa. Object oriented falsafa bo'yicha asosiy focus objectlarga qaratiladi. Objectlar koproq encapsulated objectlar bilan ishlaydi. Kichik kichik functionalga ega bo'lgan Encapsulated objectlardan tashkil topadi umumiy loyiha.

Static methodlar va yana bazi anti Object oriented feauturelar esa asosan Old school contributor va authorlar tomonidan o'ylab topib implement qilingan narsalar deb o'ylayman (IMHO).
Koplab tillarda shunday featurelar qo'llab quvvatlanadi va eski falsafaga asoslangan yangi tillarga aylanib qolishyabti.
C++ C#, Java, PHP tillari OOP ni yaxshi implement qilishga xarakat qilgan ammo dasturchilar tomonidan OOP paradigmlari yaxshi tushunilmagani va implement qilinmagani uchun hali ham  Ushbu tillarda yozishsa ham C kabi ASM kabi code yozishyabti.
Bir misol orqali objectlar va static methodlarni tushuntirib berishga xarakat qilaman.
Misol:

```
// Interval.xm

class Interval {
   left: i32
   right: i32
   
   public diff() i32 {
     return Math.abc(right - left)
   }
}

```
Instant legacy code :)

Yuqorida oddiy interval object. Aytaylik sizga intervallar bilan ishlaydigan object kerak va uni shunday ko'rinishda taqdim qildingiz. Ammo buyoqda yana bir muammo bor bu muammo shundaki `diff()` methodi ichidagi `Math.abc()` static methodi szni `diff()` methodingiz va `Interval` objectingiz yomon compozition bo'lishiga sabab bo'lmoqda. Buni biroz refactor qilish kerak. Sababi bu kabi compositionlarda Objectlar objectlar bilan emas balki Objectlar functionlar bilan yoki functionlar objectlar bilan ishlamoqda. Bunday mix composition oqibatida Object orieted prinsplar buzuladi.

```
// Interval.xm

class Interval {
   left: i32
   right: i32
   
   public diff() Int32 {
     return new Abc(right - left)
   }
}

```
Little Elegant code :)

Biroz refactoringdan keyin ko'rishimiz mumkinki biz `Math.abc()` methodi o'rniga `Abc` Degan objectga murojat qilayabmiz. Yechimning ishlashi deyarli o'zgarmadi. Ammo buyoqda paradigmaga muvofiq Object oriented yechim xosil bo'ldi. Shu bilan bir qatorda bizragi objectlar yana boshqa objectlardan foydalanyabti `diff()` methodi ham object qaytariyatbi toza integer emas :). Ammo bu yechimni ham yana refactor qilish mumkin masalan ecapsulated params ham object bo'lsa yanayam yaxshi bo'ladi.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kkjopa3i095nzt4e900z.png)



## Shunday qilib...

Xozirgi xolatda bunday muammolardan to'liq qutilish deyarli imkonsiz ayniqsa traditional C like tillarda. Ammo biz Object oriented composition qilishni xoxlasak maksimal darajada ushbu paradigmaning prinsplarini implement qilishimiz va ularga rioya qilishimiz kerak. Static methodlar objectlar encapsulated bo'lmasligiga taminlaydi ular asosidagi classlar esa shunchaki birqancha procedurelar to'plami kabi ishlaydi. Procedural paradigmada yuqorida aytib o'tilgani kabi juda katta functionlar yoki mayda functionlardan tashkil topgan katta functionlar deb qaraladi. OOP da esa kichik objectlardan tashkil topgan objectlar ularda asosiy focus constructorlarga qaratiladi methodlar esa anchagina kichik bo'ladi. Static methodlardan tashqari yana ko'plab boshqa anti pattern componentlar feauturelar mavjud bularni ham alohida yoritish kerak Biz yangi narsalarni eski dunyo qarashga asoslanib quradigan bo'lsak hech narsa o'zgarmaydi faqatina yanada yomonlashadi ))). Shu sababdan dunyo qarashlarni ham yangilash ancha foydali.

Etiboringiz uchun Rahmat :)

Happy Coding !

Telegram: [Kanalim](https://t.me/programming_everyone)