Salam dostlar. Bu məqalədə əasasən Obyekt Yönümlü Proqramlaşdırmada SOLID prinsipləri nədir? Niyə bu prinsiplərdən istifadə etməliyik? kimi suallara cavab verməyə çalışmışam. Güman edirəm proqramçılar üçün faydalı məqalə olacaqdır.

Ümumiyyətlə uzunömrlü proqram deyərkən nəyi nəzərdə tuturuq. Bəzi proqramçıların ən yaralı yerlerlərindən biri müştərinin və ya Project Manager-in yazılan proqramın hər hansı funksionallığını bəyənməməsi,  yeni  funksionallıq əlavə edilməsi və ya əksildilməsi qərarının verilməsidir. Bu dəyişiklikləri nəzərə aldıqda isə proqramda gözlənilməz xətalar ortaya çıxır, hətta bəzən proqramı bu dəyişiklik nəticəsində normal işlək vəziyyətə gətirmək mümkün olmur və proqram fəaliyyətini dayandırır.  Bunun əsas səbəbi proqramçı proqramı yazarkan gələcəkdə ola biləcək dəyişiklikləri nəzərə almaması və strukturun səliqəsiz şəkildə qurulmasıdır.

Bu səbəbdən proqramı yazarkən struktur elə qurulmalıdır ki, proqramın müəyyən bir hissəsində edilmiş hər hansı bir dəyişiklik digər hissələrə minimum təsir etsin. Yəni proqram bir-birindən asılı olmayan modullar yığımından ibarət olmalı, lazım gələrsə rahatlıqla  hər hansı modul ləğv edilməli və ya yenisi əlavə olunmalıdır.

Bunu necə etməli?

OOP-da bu problemləri aradan qaldırmaq üçün hazırlanmış və müəyyən standart halına gəlmiş dizayn qəlibləri (Design Patterns) mövcuddur.  Bu qəliblərdən biri Robert Martin-in təqdim etdiyi “Asılılığın İdarəedilməsi” (Dependency Managment)-dir.  Asılılıqların daha yaxşı idarə edilməsi proqramın uzunömrlü olması deməkdir.

OOP dillərində yazılmış, asılılıqların düzgün idarə edilmədiyi proqramlarda ortaya 3 əsas problem çıxır.

1. Sərtlik (Rigidity):Dəyişiklik  və ya əlavələr etmək çox çətindir, çünki proqramın hər bir hissəsi digər hissələrlə kip əlaqəlidir.
2. Qırılqanlıq (Fragility):Dəyişiklik edərkək proqram gözlənilməz yerlərdən qırılır və problemlər ortaya çıxır.
3. Sabitlik (Immobility):Hər hansı modulu təkrar istifadə etmək mümkün olmur.

Bu problemlərlə qarşılaşmamaq üçün SOLID prinsipləri köməyimizə çatır.  SOLID sözü 5 prinsipin hər birinin baş hərflərindən əmələ gəlmişdir. Gəlin bu prinsipləri başa düşməyə çalışaq.

S – Single Responsibility Principle:

Proqramda hər bir obyektin yalnız bir məsuliyyəti olmalıdır. Yəni hər hansı metod və ya class yaradarkən həmin obyektin gələcəkdə yalnız bir vəzifəsi olacağını qarantiləməkdir.  Bir neçə vəzifədən ibarət obyektdə edilən kiçik dəyişiklik zamanı bütün vəzifələrə görə həmin dəyişikliyi tək-tək tətbiq etmək lazımdır. Bu zaman böyük proyektlərdə proqramçı çıxılmaz vəziyyətlərə gəlib çıxacaqdır.

O – Open/Closed Principle(OCP): Obyekt inkişafa, əlavələrə açıq, ancaq dəyişikliklərə bağlı olmalıdır. Məncə bu cümlə OCP-ni ən yaxşı şəkildə izah edir.

L – Liskov ‘s Substitution Principle(LSP): 

       Hər hansı bir obyekt özündən törəmiş obyekt ilə yerlərini heç bir problem çıxmadan dəyişə bilməlidir. Əgər bu dəyişikliyə mane olan metod, obyekt, dəyişən və s. varsa, dəyişiklik zamanı xəta baş verərsə bu xətaya səbəb olan obyekt silinməli və ya yeri dəyişdirilməlidir.

I – Interface Segregation Principle (ISP):   Bu prinsipə interfeyslər üçün Single Responsibility prinsipi desək yanilmarıq. Bildiyiniz kimi obyektlər interfeysləri “implement” edərkən həmin interfeysin bütün metodlarını əzmək (override) məcburiyyətindədir. Əgər bu interfeysi implement edən class oradakı hər hansı bir metodu istifadə etməyəcəksə bu metodu boş yerə override etməsi prinsipal olaraq düzgün deyil.

Bu zaman həmin metodu başqa interfeysə ayırmaq lazımdır. Belə ki, interfeyslər də parçalanaraq bir məsuliyyətləri olacaq şəklə gətirilməlidir.

D – Dependency Inversion Principle(DIP): Bu prinsipdə iki əsas məsələ qarşıya qoyulur.

1. High-level modules should not depend on low-level modules. Both should depend on abstractions:Yüksək səviyyəli modullar aşağı səviyyəli modullardan asılı olmamalıdır. Hər ikisi abstraksiyalardan asılı olmalıdır.

1. Abstractions should not depend on details. Details should depend on abstractions:Abstraksiyalar detallardan asılı olmamalıdır. Detallar abstraksiyalardan asılı olmalıdır.

Sadaladığımız iki məsələ ondan ibarətdir ki, normalda DIP – ə uyğun yazılmayan proqramda obyektlər, ana class-lar, alt class-lar, metodlar və s. arasında bir çox asılılıqlar meydana çıxır. Sonradan proqrama yeni funksionallıqların əlavə olunması lazım gəldikdə kodların təkrarlanması, hər bir class-da bir-bir yeni funksionallığın əlavə edilməsi işimizi çətinləşdirir.

Qısa olaraq DIP-in məğzi bu sıx əlaqəli (tightly coupled) modullar arasına interfeyslər, abstrakt class-lar əlavə edərək birbaşa əlaqələri zəiflətməkdir (loose coupling).

Beləliklə, Obyekt Yönümlü Proqramlaşdırma dilləri üçün dizayn qəlibləri (Design Pattern) qaçınılmazdır.