Alıcılar/Setterlər. Pis. Və dövr

Eqor Buqaenkonun məqaləsi 19 sentyabr 2014-cü il | Göndərilən: Əsas Java Bu köhnə müzakirə Allen Holub tərəfindən 2003-cü ildə məşhur məqaləsində başlamışdır, Getter və setter üsulları niyə pisdir - alıcılar/ayarlayıcılar anti-modeldir və onlardan qaçmalıyıq, yoxsa bu bizim bir şeydir? obyekt yönümlü proqramlaşdırmada ehtiyac duyulur. Bu müzakirəyə iki sentimi əlavə edəcəyəm. Aşağıdakı mətnin mahiyyəti belədir: alıcılar və təyinçilər pis təcrübədir; onlardan istifadə edənlərin heç bir bəhanəsi yoxdur. Ancaq yenə də, anlaşılmazlığın qarşısını almaq üçün, mümkün olan hər yerdə get/set istifadəsindən qaçınmağı təklif etmirəm. Yox. Deyirəm ki, siz onları kodunuza yaxın buraxmamısınız . Bu bəyanat haqqında nə düşünürsünüz? Diqqətinizə layiqdir? 15 ildir get/set modelindən istifadə edirsiniz və hörmətli Java memarısınız? Və heç tanımadığınız adamın bu cəfəngiyyatına qulaq asmaq belə istəmirsiniz? Yaxşı... Mən sizin hisslərinizi başa düşürəm. David West-in "Obyekt Düşüncəsi" kitabına rast gələnə qədər mən də eyni hissləri keçirdim - bu, indiyə qədər oxuduğum obyekt yönümlü proqramlaşdırma üzrə ən yaxşı kitabdır. Elə isə zəhmət olmasa. Sakitləşin və izah etməyə çalışdığımı anlamağa çalışın. Mübahisənin mövzusu Obyekt yönümlü dünyada “aksesuarlara” (alıcı və təyinedicilərin başqa adı) qarşı bir neçə arqument var. Və hamısı çox düzgün arqumentlərdir. Gəlin onlara qısaca nəzər salaq. Soruşun, Deməyin : Allen Holub deyir: "İş görmək üçün lazım olan məlumatı istəməyin; bu məlumatı olan qurumdan işi sizin yerinizə görsün" deyə soruşun. Pozulmuş Encapsulation Prinsip : Bir obyekt digər obyektlər tərəfindən ayrıla bilər, çünki onlar təyinedicilər vasitəsilə hər hansı bir məlumatı obyektə daxil edə bilirlər. Bir obyekt sadəcə öz vəziyyətini kifayət qədər etibarlı şəkildə əhatə edə bilməz, çünki hər kəs bu vəziyyəti dəyişə bilər. Tətbiq Təfərrüatları Açıqlandı : Əgər başqa bir obyektdən bir obyekt əldə edə bilsəniz, onda biz birinci obyektin icra detallarına çox güvənirik. Sabah dəyişərsə (məsələn, nəticə növü), onda kodu dəyişdirməli olacağıq. Yuxarıda göstərilən əsaslandırmaların hamısı, şübhəsiz ki, məntiqlidir, lakin bu, ən vacib məqamı qaçırır. Əsas səhv anlayış Əksər proqramçılar obyektin metodları olan verilənlər strukturu olduğuna inanırlar. Bojidar Bozhanovun məqaləsindən sitat gətirirəm: Getters və Setters pis deyil. Lakin alıcıların və təyinedicilərin yaradıldığı obyektlərin əksəriyyəti sadəcə məlumatları ehtiva edir. Bu yanlış fikir böyük bir anlaşılmazlığın nəticəsidir! Obyektlər "yalnız məlumat saxlamır". Obyektlər metodları əlavə edilmiş məlumat strukturları deyil. Bu "məlumatların saxlanması" anlayışı obyekt yönümlü proqramlaşdırma və prosedur dillərindən, xüsusən C və COBOL-dan gəldi. Bir daha təkrar edəcəyəm: obyekt sadəcə məlumat elementləri və onları manipulyasiya edən funksiyalar toplusu deyil. Obyekt məlumat obyekti deyil. Bəs onda? Top və İt Həqiqi obyekt yönümlü proqramlaşdırmada obyektlər, sizin və mənim kimi canlı varlıqlardır. Onlar öz davranışları, xüsusiyyətləri və həyat dövrü ilə canlı orqanizmlərdir. Canlı orqanizmin bir sətiri ola bilərmi? Siz itə top bağlaya bilərsinizmi? Düşünmə. Ancaq aşağıdakı kod parçası məhz bunu edir:

Dog dog = new Dog();
dog.setBall(new Ball());

Bəs bunu necə bəyənirsiniz? Topu itdən ("almaq") edə bilərsinizmi? Yaxşı, tutaq ki, bacarırsınız. Əgər o yesə və siz onu əməliyyat etdirdiniz. Bu halda, bəli, itdən topu ala ("almaq") mümkün olacaq. Məhz bu barədə danışıram:

Dog dog = new Dog();
Ball ball = dog.getBall();

Və ya daha gülünc bir misal:

Dog dog = new Dog();
dog.setWeight("23kg");

Bunu real həyatda təsəvvür edə bilərsinizmi? Sanki hər gün yazırsan? Əgər belədirsə, deməli siz prosedur proqramçısısınız. Sadəcə etiraf et. David West kitabının 30-cu səhifəsində belə deyir: Uğurlu prosedur tərtibatçısını uğurlu obyektiv tərtibatçıya çevirmək üçün ilk addım lobotomiyadır. Lobotomiyaya ehtiyacınız varmı? Mənə mütləq lazım idi və Uestin “Obyekt Düşüncəsi” kitabını oxuyarkən aldım. Obyektiv Düşüncə Bir obyekt kimi düşünməyə başlayın və siz dərhal bu metodların adını dəyişəcəksiniz. Əldə edə biləcəyiniz şey budur:

Dog dog = new Dog();
dog.take(new Ball());
Ball ball = dog.give();

İndi biz itə topu bizdən ala bilən və istəsək geri verə bilən əsl heyvan kimi yanaşırıq. Hər halda, qeyd edirəm ki, it NULL-u qaytara bilməz. İtlər sadəcə NULL-un nə olduğunu bilmirlər! Obyektiv düşüncə (düşünmə) kodunuzdan dərhal NULL istinadları silir. Çarlz Kriçton tərəfindən Wanda adlı balıq (1988). Bundan əlavə, obyektiv düşüncə, nümunəmizdəki "itin çəkisi" kimi bir obyektin dəyişməzliyinə səbəb olacaqdır. Kodu belə bir şey yenidən yazardınız:

Dog dog = new Dog("23kg");
int weight = dog.weight();

İt dəyişməz canlı orqanizmdir ki, kənarda heç kimə onun çəkisini, ölçüsünü, adını və s. dəyişməyə icazə verməyəcək. İstəyə görə çəkisini və ya adını "deyə bilər". Obyektin müəyyən “daxili” xassələri üçün sorğuları ifşa edən ictimai metodlarda səhv heç nə yoxdur. Lakin bu üsullar “alıcı” deyil və onlar heç vaxt “almaq” prefiksini almamalıdırlar. Biz itdən “çıxmırıq”. Biz onun adını bilmirik. Bizə onun adını söyləməsini xahiş edirik. Fərqi görürsən? Burada hətta semantikadan danışmırıq. Proqramlaşdırmaya prosessual yanaşmanı obyekt yönümlü yanaşmadan fərqləndiririk. Prosedur proqramlaşdırmasında biz verilənlərlə işləyirik, onları manipulyasiya edirik, əldə edirik, təyin edirik və lazım gələrsə silirik. Biz cavabdehik və məlumat sadəcə passiv komponentdir. Bir it bizim üçün heç bir şey deyil - sadəcə "məlumat ehtiva edir". Onun öz həyatı yoxdur. Biz ondan lazım olan hər şeyi sərbəst şəkildə əldə edə (əldə edə) və istənilən məlumatı ona yerləşdirə (qoya bilərik). C, COBOL, Paskal və digər prosedur dilləri belə işləyir (işləyir). Və obyekt yönümlü dünyada vəziyyət tamamilə əksinədir. Burada biz cisimlərə canlı orqanizmlər kimi yanaşırıq, öz doğum tarixi və ölüm anı, istərsəniz öz şəxsiyyəti və vərdişləri ilə. Biz itdən bizə bir məlumat (məsələn, çəkisi) verməsini istəyə bilərik və o, məlumatı bizə qaytara bilər. Ancaq həmişə itin aktiv komponent olduğunu unutmayın. Tələbdən sonra nə olacağına o qərar verir. Və buna görə də obyektin metodlarının set və ya get ilə başlaması tamamilə yanlışdır. Və bu, hətta bir çox insanın düşündüyü kimi, kapsulyasiyanın pozulması ilə bağlı deyil. Bu, ya bir obyekt kimi düşündüyünüz, ya da hələ də Java sintaksisi ilə COBOL yazmağınızla əlaqədardır. PS . Bəli, siz soruşa bilərsiniz: "Bəs JavaBeans, JPA, JAXB və get/setdən asılı olan bir çox digər Java API-ləri?" Ruby-də aksessuar yaratmağı asanlaşdıran daxili funksiya haqqında nə demək olar? Yaxşı, sizə nə deyim... bəxtiniz çatmır. Prosedur COBOL-un ibtidai dünyasında qalmaq real obyektlərin ecazkar dünyasını başa düşmək və əhatə etməkdən daha asandır. P.P.S. _ Deməyi unutdum, bəli, təyinedici vasitəsilə asılılıqların daxil edilməsi də dəhşətli bir anti-patterndir. Ancaq bu barədə daha çox növbəti yazıda! Orijinal məqalə