Proqramlaşdırma Prinsipləri (YAGNI, SOLID, KISS, DRY, Delegation)

Programming Principles Every Programmer Must Know

Layihə yazılan vaxt proqramlaşdırma prinsipləri nəzərə alınmalıdır ki,daha sonra layihənin hər hansı hissəsində(module/class/file/method…) edilən dəyişiklik digər hissələrinə ciddi problem yaratmasın.

Texniki tapşırıqda sonradan nə isə dəyişdiriləndə və ya istəyə görə yeni funksionallıqlar əlavə ediləndə sistemimizdə dəyişiklik olan hissədəki update digər hissələrə minimal təsir etməlidir.

Heç bir code yazmadan aşağıdakı anlayışların məntiqini izah etməyə çalışacam bu article-da.

1. YAGNI
2. KISS
3. SOLID
4. DRY
5. Delegate

Let’s start…

YAGNI: You Are’t Gonna Need It

Çox vaxt keçmişdə lazım olduğu üçün yazdığımız amma indi işlətmədiyimiz code-u bəlkə gelecekde lazim olar deye silmirik.

Bu prinsipin əsas məqsədi odurki,refactoring vaxtı hər hansı köhnə code parcasına (method/class/file/some logic) ehtiyyacımız yoxdursa onu silmekden çekinməməliyik.

Əslində bu prinsip birazda uzaqgörənlik tələb edir.

Çünki,əsas məqsədlərindən biridə odurki bir code hissəciyi yazılarkən yalnızca indi lazım olduğuna görə deyil gələcəkdə lazım olub olmayacağınıda nəzərə almalıyıq.

Code-u silməkdən qorxma:) Ən pis halda git reposundan geri qaytara biləcəksən.

KISS: Keep It Simple, Stupid (with other hand Keep It Super Simple)

Albert Einstein said: “If you can’t explain it to a six year old, you don’t understand it well enough.”

Burdakı əsas məqsəd code-un maximum sadə və en junior adamın belə başa düşəcəyi şəkildə yazılmasıdır.

Biraz qəribə səslənsədə code-u oxuyacaq insanı ən stupid insan olaraq düşünüb ən sadə şəkildə yazmaq lazımdır.

Enisteynində dediyi kimi : “Əgər sən birşeyi 6 yaşlı uşağa izah edə bilmirsənsə deməkki hələ onu özun kifayət qədər başa düşməmisən.”

The purpose of software engineering is to reduce complexity, not to create it.
-Pamela Zave

Qısacası mühəndisliyin məqsədi mürəkkəbliyi azaltmaqdır, onu yaratmaq deyil.

SOLID: stands for five principles

Əsəs məqsədi anlaşılır,davam etdirilə və genişləndirilə bilən code yazmaqdır.

Bu prinsipləri proyekt prototype mərhələsindən keçdikdən sonra tətbiq etmək lazımdır.Həmişə hər yerdə tetbiq etməliyik deyə bir şey yoxdur amma əgər tətbiq ediləcəksə mümkün qədər bütün prinsiplərin ödənməsi daha yaxşı hal sayılır.

Aşağıdakı 5 əsas prinsipdən ibarətdir.

S) Single Responsibility Principle

SRP

Hər bir method və ya class-ın yalnız bir məsuliyyəti olmalıdır. 1 class digərinin işini görməməlidir.

Əks halda bu qaydaya uyğun yazılmamış method-da dəyişiklik edəndə istifadə edildiyi hər yerdə o dəyişikliyi tək-tək gözdən keçirməli oluruq.

Component-lərin kiçik hissələr şəklində və 1 məqsədə xidmət edəcək şəkildə yazılışı kodun resuable olmasına və daha asan anlaşılmasına şərait yaradır.

Spagetti code-un qarsısını almaq üçün çox vacib prinsiplərdən biridir.

O) Open-Closed Principle

OCP

Software entities should be open for extension but closed for modification.

1. Open for extension, meaning that the class’s behavior can be extended; and
2. Closed for modification, meaning that the source code is set and cannot be changed.

Hər bir entity(class) əlavələrə açıq olmalı amma köklü dəyisikliklərə bağli olmalıdır.

Yəni, yeni bir feature əlavə edəndə mövcud code-a təsir etmədən edə bilməliyik bunu.

Bu prosesi asanlaşdırmaq üçün adətən Interface və Abstract class-lar istifadə olunur.

L) Liskov Substitution Principle

LSP

The principle defines that objects of a superclass shall be replaceable with objects of its subclasses without breaking the application.

Bu prinsipin mahiyyəti ondan ibarətdirki,hər bir child class lazım gələrsə öz parent class-ını heç bir problem(error) olmadan əvəz edə bilməlidir.

Tətbiqi asan olmayan prinsiplərdən biridir.

I) Interface Segregation Principle

ISP

Əsas məqsədi hər class-ın ehtiyacı olanından daha artıgına access-i olmasının qarşısını almaqdır.Buda code-un daha asan anlaşılmasına şərait yaradır.

Unutmamaq lazımdır ki bir interface impliment edilen zaman içərisindəki bütün method-lar impliment edən class-lar tərəfindən məcburi olaraq override edilir.

Yəni 5 method-u olan bir interface-i impliment edib override olan method-lardan yalnız birini istifadə ediriksə burda bir problem var deməkdir.Çünki geri qalan istifadə etmədiyimiz 4 method-u boşuna override etmiş olduq.

Bu kimi halların qarşısını almaq üçün Interface-ləri mümkün olan biləcək elə kiçik interface-lərə bölməliyik ki, o interface-lərdən hər hansı birini impliment edən class override etdiyi bütün method-ları istifadə etsin.

D) Dependency Inversion Principle

DIP

Dependency Inversion principle means that developers should “depend on abstractions, not on concretions.”

Class-lar konkretlərdən deyil abstraksiyalardan asılı olmalıdır.

Əsas məqsədi sıx əlaqəli modullar arasında Interface-lər və Abstract class-lar istifadə edərək birbaşa əlaqəni zəiflətməkdir.

Yəni, bir birinə ehtiyyacı olan komponentlər arasındakı asılılığı(Depend) mümkün qədər azaltmaq lazımdır.Onlar bir birləri haqqında minimal şeyləri bilməlidirlər.

Bu bir mərkəzi sistemdən hərşeyi idarə etməyə komək edir.

DRY: Don’t Repeat Yourself

DRY

SSOT(Single source of truth) - Bu prinsipe görə hər şeyin yalnız bir mənbəyi olmalıdır.

Yəni bir logic yalniz bir yerdə olmalıdır və hər kəs onu həmin yerdən götürüb işlətməlidir.

Əks halda code təkrarına gətirib çıxarırki buda yeni feature əlavə olunanda və ya komandaya gələn yeni developerin kodu anlaması zamanı boyük vaxt itkisinə səbəb olur.

Delegation

Delegation

Don’t do all stuff by yourself, delegate it to the respective class.

Aşağıdakı hallarda istifadə edilməsi məsləhət görülür:

1. Əgər class daxilindəki methodların sayını azaltmaq istəyiriksə
2. Eyni işi görən birdən çox komponentimiz varsa

Məqsəd bütün feature-ləri bir class da toplamaq əvəzinə fərqli class-lara delegate edib resuble olsun deyə hər feature-ni yalnız bir yerdə yazmaqdır.

Bir növ Inheritance-ə alternativdir deyə bilərik.

Təşəkkürlər diqqətiniz üçün…