1. Şirkət haqqında hekayə
Sizə bir hekayə danışmaq istəyirəm ki, bu hekayə OOP-nin böyük sistemlərin mürəkkəbliyi ilə necə mübarizə apardığını göstərir. Bununla siz OOP-nin əsas məqsədini daha yaxşı anlayacaqsınız.
Bir zamanlar, kosmosda malların çatdırılması ilə məşğul olan kiçik bir şirkət var idi...
Onun adı Galaxy Rush idi. Orada 5 nəfər işləyirdi. Bir nəfər maliyyə işləri ilə məşğul olurdu, biri anbarda, biri çatdırılmada, biri reklam işləri ilə, digəri isə bütün bunların idarəçiliyini həyata keçirirdi.
Onlar çox çalışqan idi və hər şey yaxşı alınırdı. Şirkət yaxşı nüfuza sahib idi və çoxlu pul qazanırdı. Amma hər il sifarişlər artırdı, buna görə də direktor əlavə işçilər işə götürməyə məcbur oldu. Bir neçə nəfər anbara, bir neçə nəfər çatdırmaya, bir kassir və bir reklam işləri üçün yeni işçi.
Və problemlər burada başladı. İnsanların sayı artdı, və onlar bir-birlərinə mane olmağa başladılar.
Marketinq mütəxəssisi bütün pulları yeni reklam kampaniyasına xərcləyir, və kassada təcili göndərilməsi lazım olan malların alınması üçün pul qalmır.
Anbarda hər ay bir dəfə gətirilən 10 qutu yeni hiper-motor var. Kuryer, bir hiper-motor gətirmək üçün getdi, və digər müştəridən gələn 10 hiper-motor sifarişi bir ay daha gözləməyə məcbur oldu. Birinci kuryer, digər kuryerin icra etdiyi sifariş haqqında sadəcə xəbərsiz idi.
Direktorun yeni köməkçisi tədarük üçün kuryeri gəmi ilə göndərir, və qalan hər kəs gəminin geri qaytarılmasını gözləyir. Çoxlu təcili çatdırmalar var, amma bu köməkçi yalnız tədarük məsələləri ilə məşğul olur və öz işini yaxşı yerinə yetirməyə çalışır. İnsan nə qədər yaxşı işləyirdisə, bir o qədər də o, digərlərinə mane olurdu.
Vəziyyəti təhlil etməyə çalışaraq, direktor anladı ki, gəmi, pul və mallar kimi vacib resurslar səmərəsiz istifadə olunur, və bu qayda ilə – «kim birinci götürdü, onun oldu». Hər kəs ümumi resursları öz işi üçün istifadə edə bilərdi, digər işçiləri və hətta bütün şirkəti risk altına salaraq.
Nəsə etmək lazım idi, və direktor şirkətini bir neçə şöbəyə ayırmağa qərar verdi. Çatdırılma şöbəsi, marketinq şöbəsi, tədarük şöbəsi, maliyyə şöbəsi və ehtiyatlar şöbəsi yaradıldı. Artıq heç kim gəmini sadəcə götürə bilməzdi. Çatdırılma şöbəsinin rəhbəri bütün sifarişlər haqqında məlumat alırdı və gəmini şirkət üçün ən sərfəli sifarişi götürən kuryerə verirdi. Anbar da hər hansı bir kuryerin istənilən malı götürməsinə icazə vermir, bu prosesi nəzarət altında saxlayırdı. Maliyyə şöbəsi reklam üçün pul verməyə bilərdi, əgər yaxın zamanda tədarük lazım olduğunu bilirdilər. Hər şöbənin bir ictimai siması vardı – onun rəhbəri. Hər şöbənin daxili strukturu onun daxili məsələsi idi. Əgər kuryer malı götürmək istəyirdisə, o, anbardan deyil, anbarın müdirindən soruşurdu. Yeni bir sifariş gəldikdə isə, onu çatdırılma şöbəsinin direktoru (public person) alırdı, kuryer (private person) yox.
Başqa sözlə, direktor resursları və onlarla aparılan əməliyyatları qruplara (şöbələrə) bölüşdürdü, və digər şəxslərə şöbələrin daxili strukturlarına müdaxilə etməyə icazə vermədi. Yalnız müəyyən şəxslərlə əlaqə qurmaq mümkün idi.
OOP baxımından bu, proqramı obyektlərə bölmə prosesidir. Funksiyalardan və dəyişənlərdən ibarət monolit proqram, obyektlərdən ibarət proqram halına gəlir. Obyektlər isə həm dəyişənləri, həm də funksiyaları özündə cəmləşdirir.
Problem ondadır ki, hər hansı bir işçi hər hansı bir resursdan nəzarətsiz istifadə edə və hər hansı bir şəxsə əmr verə bilərdi. Biz kiçik bir məhdudiyyət tətbiq etdik, amma daha çox nizam əldə etdik. Və hər şeyi daha yaxşı idarə edə bildik.
Böl və idarə et – təmiz görkəmdə.
2. Proqramların yaradılması prosesi
Mən ООП-ın başqa bir üstünlüyünü açan başqa bir mühüm məqama toxunmaq istəyirəm. Bilirsən, proqramlar binalardan daha çox heyvan kimidir. Onları tikmirlər, onları böyüdürlər. Proqramlaşdırma — daimi dəyişikliklərdir. Tikinti zamanı yaxşı bir planınız ola bilər və dəqiq ona riayət edə bilərsiniz. Ancaq proqram hazırlamaq zamanı bu belə işləmir.
Çox vaxt proqramlaşdırmada bir şeyi ilkin olaraq nəzərdə tutduğun yolla etmək mümkün deyil və bir çox şeyi yenidən işləmək lazım gəlir. Daha da çox hallarda müştərinin tələbləri dəyişir.
Bəs əgər layihə müştərisi çox dəqiq bir spesifikasiya verdiyinə görə? O zaman işlər daha da pis olur. Məhsulun zamanla vəziyyətinə baxın.
Məhsulun uğuru müştərinin onun yeni versiyasını, sonra isə daha bir versiyasını buraxmaq istəməsinə gətirib çıxaracaqdır. Və, əlbəttə ki, artıq mövcud məhsula «kiçik dəyişikliklər» əlavə etmək lazım olacaqdır. Ona görə də məhsulun hazırlanması — daimi dəyişikliklər zənciridir. Zaman miqyası sadəcə fərqlidir. Hər yeni versiya həftədə bir dəfə, ayda bir dəfə və ya altı ayda bir dəfə çıxarıla bilər.
Bəs bütün bunlardan hansı nəticəni çıxarmaq olar? Məhsulun daxili strukturu elə vəziyyətdə saxlanılmalıdır ki, əhəmiyyətli (və ya çox da əhəmiyyətli olmayan) dəyişiklikləri minimal səylərlə həyata keçirmək mümkün olsun.
Obyektlərin əlaqəliyi
Amma bunu etmək düşündüyündən daha çətindir. Artıq dediyimiz kimi, proqram obyektlərdən ibarətdir və bu obyektlər bir-biri ilə qarşılıqlı əlaqədədir. Gəlin proqramımızın bütün obyektlərini lövhəyə çəkin, onları qalın nöqtələrlə təsvir edin. Həmçinin, hər bir obyektin (nöqtənin) onu əlaqələndirən digər obyektlərə (nöqtələrə) istiqamətlənən oxlar çəkin.
İndi obyektləri (nöqtələri) qruplara birləşdirəcəyik. Nöqtələr öz aralarındakı əlaqələr digər nöqtələrlə əlaqələrdən daha çox olduqda, onlar bir qrupa birləşdirilməlidir. Əgər nöqtədən çıxan oxların əksəriyyəti onun qrupundakı digər nöqtələrə gedirsə, onda qruplaşdırma düzgün aparılmış hesab olunur. Eyni qrupdakı nöqtələr güclü əlaqəli, müxtəlif qruplardakı nöqtələr isə zəif əlaqəli adlandırılacaqdır.
Zəif əlaqə prinsipi
Bu «zəif əlaqə prinsipi» adlanır. Proqram bir neçə hissəyə, çox vaxt qatlara bölünür, onların məntiqi daxili qurumları ilə sıx şəkildə bağlıdır və başqa qatlar/hissələrlə çox zəif bağlıdır. Adətən, qatların qarşılıqlı əlaqəsi çox tənzimlənmiş olur. Bir qat ikinci qata müraciət edə və onun yalnız kiçik bir hissəsini istifadə edə bilər. Eyni «şöbələrə bölmə» prinsipidir, amma daha böyük miqyasda.
Bu, şöbənin təşkilatlanmasını, effektivliyini artırmasını, ora daha çox insan cəlb etməyimizi təmin etməyə imkan verir, amma əgər digər şöbələrlə qarşılıqlı əlaqə protokolunu dəyişməsək, etdiyimiz bütün dəyişikliklər lokal qalacaq. Heç kimə yenidən təhsil almaq lazım olmayacaq. Bütün sistemi yenidən qurmağa ehtiyac qalmayacaq. Əgər ümumi qarşılıqlı əlaqə mexanizmləri uğurlu seçilirsə, hər bir şöbə daxili optimallaşdırma ilə məşğul ola bilər.
Uğurla seçilib. Bəs uğurla seçilməsə nə baş verəcək? Onda «dəyişmə ehtiyatı» tez bir zamanda tükənəcək və bütün sistemi yenidən qurmaq lazım olacaq. Bunu zaman-zaman etmək lazımdır. Gələcəkdə nə olacaq bilmək olmaz, lakin yenidənqurma sayını minimuma endirmək olar.
Abstraksiya Prinsipi
Şöbələrin strukturlarını və onların qarşılıqlı əlaqə üsullarını seçmək «Abstraksiya prinsipi»-dir. Proqramlaşdırmada bu prinsipi proqramı hansı hissələrə bölmək və bu hissələrin necə qarşılıqlı əlaqədə olacağını müəyyən etmək üçün istifadə edirlər. Bu prinsipi əldə edilən hissələri bölmək üçün tətbiq etmək olar, ta ki proqramı ayrı-ayrı siniflərə bölənədək.
Bu hissələrin daxili strukturunu gizlətmək və digər hissələrlə qarşılıqlı əlaqəni ciddi şəkildə məhdudlaşdırmaq — İnkapsulyasiya-dır. İnkapsulyasiya + Abstraksiya — ООП-in əsas daşlarıdır. Yaxşı bir proqram mütləq bu iki prinsipə əməl etməlidir. Gələcəkdə digər prinsipləri nəzərdən keçirəcəyik və onların bizə hansı üstünlüklər verdiyini anlayacağıq.
GO TO FULL VERSION