Composition over Inheritance
Object Oriented Programming (OOP) — də, yəni obyektyönümlü proqramlaşdırmada Composition və Inheritance kimi anlayışlar vardır.
Inheritance ilə bəlkə də tanışsınız. Azərbaycan dilinə miras, varislik kimi tərcümə olunur.OOP-nin təməl konseptlərindən biridir.
Bəs Composition nədir ?
Niyə çox zaman proqramçılar Kompozisiyanı Miras almaqdan üstün tuturlar ?
Kompozisiya da obyektlər arasında olan bir relationship (qohumluq) əlaqəsidir. Əslində kompozisiya çox asan əldə edilə bilər.
Sözügedən qohumluq əlaqəsini sadə bir dildə belə izah edə bilərik:
Məsələn, class daxilində bir property (dəyişən), digər classın instance (obyekt və yaxud obyektlərini) özündə saxlayır. Bu obyekt həmin class daxilində sabit, dəyişilməyən olaraq qalır. Yəni, qısaca desək, obyekt, daxilində olduğu class-ın sabit bir parçasına çevrilir. Ondan asılı olur. Əgər biz parent (valideyn) classı silsək daxilindəki olan obyekt-də silinməlidir.
Composition, UML diaqramlarda içi dolu almaz şəkilində göstərilir.
Person class-ı daxilində SocialSecurityData obyektini saxlayır. Bu obyekt yalnız Person classına aiddir.
Ümid edirəm ki, bu hissəyə qədər Composition haqqında məlumat əldə edə bildiniz.
Keçək əsas məsələyə: Niyə məhz Composition over Inheritance ?
Bildiyimiz kimi, child (əsas sinifdən miras alan siniflər) classlar öz parent classlarından method və property -ləri miras alır (nə qədər ki, onlar public və yaxud protected elementlərdir). Bu funksionallıqdan istifadə edərək, biz öz class arxitekturamızı, bazamızı dizayn edə bilərik.
Nümunə üçün diaqramdan istifadə edəcəm. Təsəvvür edin, bir kursunuz var.
Kursun ödənişi 2 cür olmalıdır:
- Sabit
- Saata görə
Gəlin bu tapşırıq üçün diagram hazırlayaq.
Bu miras alma methodundan istifadə edərək çox gözəl nəticə əldə etdim. Hamı xoşbəxtdir, hamı sevinir :)
Sonra kursunuz inkişaf edir, şagirdlər çoxalır.
Düşündünüz ki, kurs, seminarlar və mühazirələrə bölünsün.Nəticədə seminarın və mühazirənin sabit,standart qiyməti və saatlıq qiymətini hesablamaq lazımdır. Aydındır ki, ayrıca olaraq Seminar və Mühazirə classları yaradılmalıdır.Bundan sonra isə, qiymət strategiyası düşünülməlidir.
Bu məqamda belə bir struktur fikirləşmək olar.
Bu strukturu tətbiq edərək, proqramlaşdırmada mövcud olan DRY prinsipini pozmuş oluruq. FixedPrice* və TimedPrice* classları burada təkrarlanır. Bir növ istifadəyə yararsız dizayn əldə etdik. Əgər sabah başqa bir qiymət strategiyasını əlavə etmək istəsəniz yenidən bu classları təkrarlamalı olacaqsınız.
Aydındır, bəs bu problemi necə həll edə bilərik ?
İlk öncə problemi anlamaq lazımdır. Inheritance (miras alma) vasitəsi ilə istifadəyə yararsız bir dizayn əldə etdik. Gördüyümüz kimi, burada əsas problem seminarın və mühazirənin sabit və saatlıq qiymətini hesablamaqdır.
Düşünürəm ki, Composition-dan istifadə edərək bu problemi həll edə bilərik.
Burada Strategy pattern (Strategiya) — dan istifadə edərək, composition vasitəsi ilə qiymət hesablama alqoritmini Dərs (və yaxud kursdan) ayırdıq.
Nəticədə Dərs artıq özünə aid olan proseslərlə məşğuldu.Onu artıq qiymət hesablamaq maraqlandırmır. Dərs, CostStrategy obyektlərindən birini öz daxilində saxlayır. Qiymətin hesablaması prosesi CostStrategy obyektlərindən birinində baş verir.
Bu yanaşma kodun daha səliqəli, anlaşıqlı olmasına kömək edir. İndi isə istədiyim qədər qiymət hesablama strategiyamı əlavə edə bilərəm.
Oxuduğunuza görə minnətdaram.Ümid edirəm ki, bu postdan yeni biliklər əldə etdiniz.
Hörmətlə, Vagif Rufullazada.
