Oop nədir. OOP üçün obyekt yönümlü proqramlaşdırma beşiyindəki əsas anlayışlar

Oop nədir. OOP üçün obyekt yönümlü proqramlaşdırma beşiyindəki əsas anlayışlar

ümumi məlumat

OOP, 80-ci əsrdə görünən bir proqramlaşdırma tərzidir. Prosessual dillərdən fərqli olaraq, onların emal edilməsi üçün məlumat və təlimatlar ayrıca mövcuddur, obyekt yönümlü proqramlaşdırmada, bu məlumat bir mahiyyətə birləşdirilir.

OOO-nun əsas prinsipləri

Miras

OOP-in ikinci prinsipi - miras bir sinifin faktiki tətbiq edilməsinin təkrarlanması olmadan digərinin metodlarından istifadə etmək imkanıdır. Vərəsəlik mənbə kodunun ehtiyatından qurtulmağa imkan verir.

Polimorfizm

OOP-ın başqa bir prinsipi - polimorfizm. Onun istifadəsi o deməkdir ki, müxtəlif dərəcəli mürəkkəblik obyektləri ilə manipulyasiya üçün, hadisələrə fərqli reaksiya verəcək və eyni zamanda vəzifələri düzgün yerinə yetirəcək bir interfeys yarada bilərsiniz.

Oop dilləri

OOP prinsipləri, proqram və tətbiqlərin əhəmiyyətli bir hissəsini inkişaf etdirən C ++ və Java kimi ən populyar proqramlaşdırma dillərində istifadə olunur. Daha az istifadə olunan dillər var - bu Delphi, Obyekt Paskal, Yaqut və digərləridir.

Kritika oop

Bu metodologiya istiqamətində əsasən müsbət ifadələrə baxmayaraq, tez-tez OO oop prinsipləri tənqidlərə məruz qalır. Oopun çatışmazlıqları olduğu kimi.

Birincisi, keçidin mürəkkəbliyi. OOP prinsiplərini başa düşmək üçün, çox vaxt lazımdır, xüsusən də yalnız prosedur proqramlaşdırma dilləri ilə yaxından işləyəcək insanlar.

İkincisi, dezavantaj daha mürəkkəb sənədlərdir, çünki bu, yalnız dərsləri və obyektləri təsvir etmək, həm də onların həyata keçirilməsinin xüsusi hallarını təsvir etmək lazımdır.

Üçüncüsü, metodların həddindən artıq çox yönlü olması, mənbə kodunun və proqramların hazırlanmasının bu vəziyyətdə bu vəziyyətdə funksiyalar və imkanları ilə çox yüklənməsinə səbəb ola bilər. Bundan əlavə, yaddaş paylanması baxımından səmərəsizlik var. Ancaq ətrafdakı oop proqramçılarının rəylərindən asılı olmayaraq, daim böyüyür və dillərin sürətlə inkişaf edir.

Obyekt yönümlü dillərdə necə proqramlaşdırılacağını bilmirəm. Öyrənmədi. Java-da 5 illik sənaye proqramlaşdırmadan sonra hələ də obyekt yönümlü üslubda yaxşı bir sistem yaratmağı hələ bilmirəm. Sadəcə başa düşmürəm.

Dürüstcə necə olmağı öyrənməyə çalışdım. Nümunələri öyrəndim, Kod Açıq Mənbə Layihələrini oxuyun, başımda incə anlayışlar qurmağa çalışdım, lakin keyfiyyətli obyekt yönümlü proqramlar yaratmaq prinsiplərini başa düşmədim. Bəlkə də başqası onları başa düşdü, amma mən deyil.

Mənə anlaşılmazlığa səbəb olan bəzi şeylər var.

Oopun nə olduğunu bilmirəm

Ciddi. Oopun əsas fikirlərini formalaşdırmaq mənim üçün çətindir. Funksional proqramlaşdırma şəraitində əsas fikirlərdən biri dövlətin olmamasıdır. Struktur - parçalanma. Modulda - işlək bloklarda funksionalın ayrılması. Bu paradiqmaların hər hansı birində dominant prinsiplər kodun 95% -ə tətbiq olunur və dil istifadə etməyə təşviq etmək üçün hazırlanmışdır. Oop üçün bu cür qaydaları bilmirəm.
  • Abstraksiya
  • Kasadlama
  • Miras
  • Polimorfizm
Qaydalar toplusuna baxır, elə deyilmi? Beləliklə, budur, halların 95% -də təqib etmək lazım olan çox qaydalar varmı? Hmm, daha yaxından baxaq.

Abstraksiya

Abstraksiya güclü bir proqramlaşdırma vasitəsidir. Böyük sistemlər qurmağa və onlara nəzarəti qorumağa imkan verən şeydir. Heç olmasa belə bir vasitə ilə silahlanmadığı təqdirdə bu günün bugünkü proqram səviyyəsinə yaxın olmayacağımız mümkün deyil. Ancaq abstraksiya oopla necə əlaqəlidir?

Birincisi, abstraksiya yalnız OOP və ümumilikdə proqramlaşdırma bir atribut deyil. Abstraksiya səviyyələrinin yaradılması prosesi demək olar ki, insan biliklərinin bütün sahələrinə paylanır. Beləliklə, molekulyar quruluşunun təfərrüatlarına girmədən materiallar haqqında mühakimə edə bilərik. Və ya edildiyi materiallar deyil, maddələr haqqında danışın. Və ya bir kompüter, bir təyyarə turbin və ya insan bədəni kimi mürəkkəb mexanizmlər haqqında mübahisə edin, bu qurumların fərdi təfərrüatlarını xatırlamıram.

İkincisi, proqramlaşdırma tarixində ilk hesab olunan ADU Lavleisin qeydlərindən başlayaraq, proqramlaşdırma üzrə abstraksiyalar həmişə idi. O vaxtdan bəri insanlar əvvəllər proqramlarında, tez-tez yalnız ən sadə məna daşıyan proqramlarında abstraksiya yaratdılar. Beləliklə, Abelson və Sassman, istenmeyen kitablarında, yalnız prosedur və əlaqəli siyahıları olan mürəkkəb nömrələrə və hətta polinomiyalara dəstək olan tənliklərin həlli sisteminin necə yaradılmasını təsvir edir. Beləliklə, abstraksiya oopu hansı əlavə vasitələr daşıyır? Heç bir fikrim yoxdur. Subprogramme kodu seçin? Bu, hər hansı bir yüksək səviyyəli dildədir. Subroutinləri bir yerdə birləşdirin? Bunun üçün kifayət qədər modul. Tiplifik? Oopdan çox əvvəl idi. Tənzimləmə tənlikləri sistemi olan bir nümunə yaxşı göstərir ki, abstraksiya qurma səviyyələri bu qədər çox deyil, proqramçıların qabiliyyətlərindən olduğu kimi dil vasitələrindən çox deyil.

Kasadlama

Həyata keçirilməsində əsas viser encapsulasiyası. Müştəri kodu yalnız interfeysi görür və yalnız bu sayıla bilər. Bu, həyata keçirilməni dəyişdirmək qərarına gələ bilən inkişaf etdiricilərin əllərini açır. Və həqiqətən də sərindir. Ancaq sual yenidən budur, sonra oop? Hər şey Yuxarıda göstərilən paradiqmalar həyata keçirilməni gizlədir. Header sənədlərində interfeysi vurğuladığınız, Oberon, Oberon, modul üçün yerli və metodları yerli hala gətirməyə imkan verir, nəhayət, bir çox dildə abstraksiya, sadəcə tətbiqetməni də icrasını əhatə edən subroutinlər vasitəsi ilə qurulur. Üstəlik, obyekt yönümlü dillər çox vaxt İncapsulyasiya qaydasını pozmaqXüsusi metodlar vasitəsilə məlumatlara giriş təmin etməklə - Java-da Getters və Sırala, C # və s. (Şərhlərdə proqramlaşdırma dillərində bəzi obyektlərin OOP baxımından obyektlərin olmadığı aşkar edildi: Məlumat ötürmə obyektləri məlumat ötürülməsinə cavabdehdir və buna görə də oopun tam varlıqları deyil və buna görə də orada Encapsulasiyanı qorumağa ehtiyac yoxdur. Digər tərəfdən, memarlığın elastikliyini qorumaq üçün imkan vermək daha yaxşıdır. Beləliklə, hər şey asan deyil.) Bundan əlavə, piton kimi bəzi obyekt yönümlü dillər, bir şey gizlətməyə çalışmayın Ümumiyyətlə, ancaq bu kodu istifadə edərək inkişaf etdiricilərin rasionallığını hesablayın.

Miras

Vərəsəlik oop sayəsində həqiqətən səhnəyə çıxan bir neçə yeni şeylərdən biridir. Xeyr, obyekt yönümlü dillər yeni bir fikir yaratmadı - miras başqa bir paradiqmada tam şəkildə həyata keçirilə bilər - ancaq OOP əvvəlcə bu konsepsiyanı dilin səviyyəsinə gətirdi. Meyvanın açıq və üstünlükləri: nə vaxt təqribən Bəzi sinif üçün uyğundur, nəsil yarada və funksionallığının bir hissəsini ləğv edə bilərsiniz. C ++ və ya Scala kimi birdən çox mirasını dəstəkləyən dillərdə (sonuncuda - əlamətlər hesabına), digər istifadə seçimi görünür - mixinlər, kiçik siniflər, "qəbul etmə" funksiyasını yeni bir sinfə təqdim etməyə imkan verir Kod.

Beləliklə, oopu digərləri arasında bir paradiqma kimi ayıran şey budur? Hmm ... Əgər belədirsə, niyə nadir hallarda real kodda istifadə edirik? Unutmayın, mən dominant paradiqmanın qaydalarını təqdim edən kodun 95% -ni danışdım? Zarafat etmədim. Funksional proqramlaşdırma, kodun ən azı 95% -i yan təsirləri olmadan dəyişməz məlumat və funksiyalardan istifadə edir. Modullarda, demək olar ki, bütün kod məntiqi olaraq modullarla qablaşdırılır. Yazıq qurulmuş struktur proqramlaşdırma, Daekstra, proqramın bütün hissələrini kiçik hissələrə bölməyə çalışın. Vərəsəlik daha az yaygındır. 10% kodda ola bilər, bəzi hallarda (məsələn, çərçivə siniflərindən miras qaldıqda) - 70% -də ola bilər, lakin daha çox deyil. Çünki əksər hallarda bu sadəcə lazım deyil.

Üstəlik, miras təhlükəli Yaxşı dizayn üçün. Kitabdakı dörd (oopun təbliğçisi) dəstəsi, onu heyətlə əvəz etmək mümkün olduğunu tövsiyə edir. Məşhur dillərdə mövcud olan formada miras indi kövrək bir dizayna aparır. Bir əcdaddan miras alan, sinif artıq başqalarından miras qala bilməz. Atanın dəyişməsi də təhlükəlidir. Əlbəttə ki, özəl / qorunan dəyişdiricilər var, lakin sinifin necə dəyişə biləcəyini və müştəri kodunun necə istifadə edə biləcəyini təxmin etmək üçün açılmamış ekstrasensorluq qabiliyyətlərini də tələb edirlər. Vərəsəlik o qədər təhlükəli və əlverişsizdir ki, böyük çərçivələr (məsələn, Java-da yaz və Ejb kimi) onlardan imtina edir, başqalarına, obyekt yönümlü vasitələr (məsələn, metaproqrominq). Nəticələri bu qədər gözlənilməzdir ki, bəzi kitabxanalar (guava kimi) miraslarına miras alan və yeni gediş dilində miras iyerarxiyasından imtina etmək qərara alındı.

Polimorfizm

Bəlkə də polimorfizm obyekt yönümlü proqramlaşdırmada ən yaxşı şeydir. Polimorfizm sayəsində tipli şəxsin obyekti "Shandorkin Adam Impolitoviç" və obyekt tipli nöqtəsi kimi görünür ". "Mat1 * Mat2" yazmağa və adi nömrələrin məhsuluna bənzər matris məhsullarını əldə etməyə imkan verən odur. Onsuz, şəbəkədən, fayldan və ya cizgilərdən, fayldan və ya satırlardan bəhs etmədən, giriş axınından məlumatı oxuya bilməzdi. İnterfeyslərin olduğu hər yerdə, polimorfizm də nəzərdə tutulur.

Həqiqətən polimorfizmi sevirəm. Buna görə də, onun problemləri barədə əsas dillərdə də danışmayacağam. Mən də göndərmə yanaşmasının darlığı haqqında yalnız növü və bunun necə edilə biləcəyi barədə susacağam. Əksər hallarda, lazım olduğu kimi işləyir və bu artıq pis deyil. Sual budur: Polimorfizm, oopu digər paradiqmalardan fərqləndirən prinsipi isə? Məndən soruşsanız (və bu mətni oxudusunuzsa, bu, soruşduğumuzu düşünə biləcəyimiz deməkdir, "yox" cavabını verərdim. Və səbəb hər şey kodda istifadə nisbətindədir. Yəqin ki, interfuzalar və polimorfik metodlar bir az daha çox mirasdır. Adi prosedur üslubunda yazılmış sətirlərin sayı ilə işğal edilmiş kodun satırlarının sayını müqayisə edin - ikincisi həmişə daha böyükdür. Belə bir proqramlaşdırma tərzini təşviq edən dillərə baxaraq, onlara polimorf adlandıra bilmirəm. Polmorfizmin dəstəyi ilə dillər - Bəli, normaldır. Ancaq polimorf dilləri deyil.

(Ancaq bu mənim fikrimdir. Həmişə razı ola bilərsiniz.)

Beləliklə, abstraksiya, encapsulation, miras və polimorfizm - bütün bunlar OOP-dadır, amma bu heç bir şey onun xas olan atributudur. Onda bir oop nədir? Obyekt yönümlü proqramlaşdırmanın mahiyyətinin əslində, obyektləri (olduqca məntiqli) və dərslərdə olduğu güman edilir. Bu, kod və məlumatları, eləcə də proqramdakı obyektlərin real dünyanın mahiyyətini əks etdirməsi fikri birləşdirmək fikridir. Bu fikrə qayıdacağıq, amma başlanğıc üçün bir neçə xalları I ilə qıracağıq.

Kimin oop soyuducu?

Əvvəlki hissədən, proqramlaşdırma dillərinin obyekt yönümlü proqramlaşdırma üsulu ilə çox fərqli ola biləcəyini görmək olar. Bütün dillərdə OOP-ın bütün tətbiqetmələrini bir dəst götürsəniz, çox güman ki, bütün əlamətlər üçün bir ümumi bir şey tapa bilməzsiniz. Bu zooparkı birtəhər məhdudlaşdırmaq və əsaslandırmaq üçün aydınlıq gətirmək, yalnız bir qrup - sırf yönümlü dillərdə, yəni Java və C # yaşayacağam. Bu vəziyyətdə "saf obyekt yönümlü" termini dilin digər paradiqaları dəstəkləmir və ya eyni OOP vasitəsilə tətbiq etməsi deməkdir. Məsələn, piton və ya yaqut, mən təmiz olmayacağam, çünki Bir sinif bəyanatı olmadan onlara asanlıqla tam hüquqlu bir proqram yaza bilərsiniz.

Java və C # -də Oopun mahiyyətini daha yaxşı başa düşmək üçün, bu paradiqmanın digər dillərdə həyata keçirilməsinə dair nümunələr üzərində çalışırıq.

SmallTalk. Müasir həmkarlarından fərqli olaraq, bu dildə oopu həyata keçirmək üçün dinamik yazma və istifadə olunan mesaj ötürmə tərzi var idi. Çağırış metodları əvəzinə, obyektlər bir-birinin mesajlarını göndərdi və alıcının nə gəldiyini emal edə bilmədikdə, sadəcə başqasına bir mesaj göndərdi.

Ümumi lisp. Əvvəlcə CL eyni paradiqma yapışdı. Geliştiricilərin bundan sonra `(obj göndər" ni biraz mesaj) yazmaq qərarına gəldilər - bu çox uzun və metoduna (bəzi üsul) adlandırmaq üçün notation dəyişdirildi. Bu gün, ümumi LISP inkişaf etmiş bir obyekt yönümlü bir proqramlaşdırmanı var Bir çox miras, multimeter və metaklar üçün dəstək ilə sistem (CLO). Fərqli bir xüsusiyyət, cl-dəki Oopun obyektlərin ətrafında deyil, ümumiləşdirilmiş funksiyaların ətrafında olmasıdır.

Klojure. Clojure, 2 obyekt yönümlü proqramlaşdırma sistemi - Java-dan miras qalan, ikincisi, multimethodlara və daha çox bənzər bir şəkildə var.

R. Statistik məlumatların təhlili üçün bu dildə 2 obyekt yönümlü proqramlaşdırma sistemi - S3 və S4 var. Hər ikisi də dildə miras qalır (təəccüblü deyil, bu r-nin kommersiya slopland sandıq satılmasıdır). S4 üçün ən çox, oopun müasir əsas dillərində reallaşdırılması ilə qarşılaşır. S3 daha yüngül bir seçimdir, elementar, dilin özü: bir ümumi funksiya yaranan obyektin "sinif" atributu ilə sorğuları göndərilir.

JavaScript. Digər bir sintaksis istifadə etsə də, kiçiktalka bənzər ideologiyaya görə. Vərəsəlik əvəzinə, prototiping istifadə edir: İstədiyiniz əmlak və ya obyektin özündə meydana gələn bir üsul yoxdursa, sorğu prototip obyektinə (bütün JavaScript obyektlərinin prototipi əmlakına) ötürülür. Prototipin metodlarından birini dəyişdirərək, bütün sinif obyektlərinin davranışının dəyişdirilməsi maraqlıdır (çox gözəl, məsələn, "Tobase64" sinif sinifini əlavə etmək kimi görünür).

Python. Ümumiyyətlə, o, eyni konsepsiyaya əsas anlayışa riayət edir, lakin bundan əlavə, bu, atribut axtarışının JavaScript və ya SmallTalk-da olduğu kimi başqa bir obyektə ötürülməsini dəstəkləyir.

Haskell. Haskell-də ümumiyyətlə heç bir dövlət yoxdur və buna görə də adi anlayışdakı əşyalar. Bununla birlikdə, bir növ OOP hələ də var: məlumat növləri (növləri) bir və ya daha çox növ növə aid ola bilər (tip siniflər). Məsələn, Haskell'in demək olar ki, hər növü bir EQ sinifində (2 obyektin müqayisə əməliyyatları üçün cavabdeh) və bütün nömrələr əlavə olaraq num siniflərində (ədədlər üzrə əməliyyatlar) və ord (əməliyyatlar)<, <=, >\u003d,\u003e). Menstrum dilləri növləri uyğun siniflər (məlumatlar) və tipli siniflər - interfeyslərdir.

Dövlət və ya vətəndaşsız?

Ancaq daha çox ümumi obyekt yönümlü proqramlaşdırma sistemlərinə qayıdın. Heç vaxt başa düşmədiyim şey, obyektlərin daxili vəziyyəti olan əlaqəsidir. OOP-ı öyrənmədən əvvəl hər şey sadə və şəffaf idi: bir neçə əlaqəli məlumatları saxlayan strukturlar var, prosedurlar (funksiyalar) var, emal edir. Gəzmək (it), çıxarın (hesab, məbləğ). Sonra obyektlər gəldi və bu da heç nə idi (proqramları oxumaq daha çətin olsa da, itim [kimin?] Və hesabı vurdu. Sonra məlumatların gizlədilməsi barədə məlumat əldə etdim. Mən hələ də köpək gəzə bilərdim, amma yeməyinin tərkibini görə bilmədim. Yemək heç bir hərəkət etməmişdir (yəqin ki, bu yeməyi yazmaq mümkün idi. (Köpək) yazın, amma yenə də itimin yemək yediyini və əksinə deyiləm). Yemək yalnız məlumatlardır və yalnız onlara daxil olmaq üçün (və itim) lazım idi. Hər şey sadəcə. Ancaq paradiqma çərçivəsində, 90-cı illərin sonundakı köhnə jeansda olduğu kimi, artıq mümkün deyildi.

Yaxşı, tamam, məlumat əldə etmək metodlarımız var. Gəlin bu kiçik özünü aldatma və həqiqətən gizlədiyimiz məlumatların olduğunu iddia edək. Ancaq indi bilirəm ki, obyektlər ilk növbədə məlumatlar, sonra, bəlkə də onların emal üsullarıdır. Proqramları dizayn edərkən səy göstərməli olduğunuz şeylərə necə yazmağı başa düşdüm.

Maariftenmentdən zövq almağa vaxtım yox idi, çünki internetdə vətəndaşsızdır, bu, parlaqlıqla əhatə olunmuşdur və t və l hərfləri üzərində asılmışdır). Ədəbiyyatın qısa bir araşdırması, şəffaf idarəetmə axınının və obyektin tutarlılığını izləməməsi lazım olan sadə bir nəzarət axınının gözəl bir dünyasını açdı. Əlbəttə ki, dərhal bu gözəl dünyaya toxunmaq istədim. Bununla birlikdə, bu, hər hansı bir qaydadan tamamilə imtina etmək idi - indi itin özü gəzdirməməsi və ya bunun üçün xüsusi bir keçid meneceri tələb olunduğu aydın deyildi; Hesabın lazım olub-olmaması, ya da bank bütün işlərin öhdəsindən gələ bilər və əgər varsa, pulu statik və ya dinamik şəkildə yazmalıdır və s. İstifadə seçimlərinin sayı eksponent olaraq və gələcəkdə bütün variantlar ciddi refaktorun ehtiyacına səbəb ola bilər.

Hələ də bir obyektin vətəndaşlığı olmayan nə vaxt verildiyini və yalnız bir məlumat konteyneri olduqda bilmədiyini bilmirəm. Bəzən göz qabağındadır, amma ən çox yox.

Tipifikasiyası: statik və ya dinamik?

C # və Java kimi dilləri haqqında müəyyən edə bilməyəcəyim başqa bir şey, onlar statik və ya dinamik olaraq yazılmışdır. Yəqin ki, əksər insanlar 'nə cəfəngiyat! Əlbəttə ki, statik olaraq yazılmışdır! Tərtib zamanı növləri yoxlanılır! " Ancaq həqiqətən bu qədər asandır? Doğrudanmı, bir proqramçı, metod parametrlərində qeydiyyatdan keçən X, X-nin X T Type X obyektləri olacağına əmin ola bilərmi? Doğru - edə bilməz, çünki X metodunda, X parametrini köçürə bilərsiniz ya da varisi. Görünür, buna görə nə? X heis-lər hələ də X. metodları metodları ilə eyni metodlara sahib olacaqlar, lakin işin məntiqi tamamilə fərqli ola bilər. Ən çox yayılmış hal, bu, bir uşaq sinfi X-dən daha çox ehtiyac duyduğu zaman, metodumuzun optimallaşdırılmasına inanmaq olar (əgər belə bir ssenari sizin üçün qeyri-real görünsə, bəzi inkişaf etmiş açıq mənbəyə bir plugin yazmağa çalışın Kitabxana - ya memarlıq və kitabxana alqoritmlərinin təhlili üçün bir neçə həftə vaxt keçirəcəksiniz və ya sadəcə uyğun bir imza ilə metodları qaldıracaqsınız). Nəticədə, proqram işləyir, lakin iş sürəti bir sifariş verir. Tərtib edənin baxımından hər şey düzgündür. Bu davranışın dəyişdirilə bilməsinə baxmayaraq, bir çox yerdə Java varisliyi adlanan Scala'nın, bir çox yerlərdə yalnız göstərilən tipin arqumentlərinə icazə verdiyi əhəmiyyətlidir.

Başqa bir problem, Java-da hər hansı bir obyektin əvəzinə və C #-də hər hansı bir nullable obyektin əvəzinə ötürülə bilən nulldur. NULL bir anda hər növə aiddir və eyni zamanda heç bir şeyə aid deyil. Null, nə sahələr, nə də metodları yoxdur, buna görə ona hər hansı bir müraciət (null yoxlanılması istisna olmaqla) bir səhvə səbəb olur. Deyəsən hər şey buna vərdiş edir, ancaq Haskell (və eyni Scala) ilə müqayisə etmək üçün xüsusi növlərdən (bəlkə də haskelldə, SCAL-da seçim etmək üçün), digər dillərdə null geri qaytara biləcəklər. Nəticədə Haskell haqqında tez-tez "Proqramı tərtib etmək çətindir, amma yenə də baş verərsə, bu, düzgün işləyir."

Digər tərəfdən, əsas dillər açıq şəkildə dinamik yazılmır və buna görə də bu cür xüsusiyyətlərə interfeyslərin sadəliyi və prosedurların elastikliyinə sahib deyil. Nəticədə Python və ya Lisp üslubunda yazmaq da mümkünsüz olur.

Fərq nədir, bütün qaydalar hələ də bilinirsə, bu yazmağın adı nədir? Fərq, hansı tərəfdən memarlıq dizaynına yaxınlaşacaqdır. Uzun müddət bir mübahisə, bir sistem necə qurulacaq: bir çox növ və az funksiya və ya bir neçə növ və bir çox funksiya varmı? İlk yanaşma Haskelldə, ikincisi LISP-də fəal istifadə olunur. Müasir obyekt yönümlü dillərdə bir şey istifadə olunur. Pis olduğunu söyləmək istəmirəm - yəqin ki, onun üstünlükləri var (sonunda, Java və C # çox dilli platformalar üçün bunu unutmamalısınız), amma hər dəfə yeni bir layihəyə başlayanda Dizayn və ya funksionallıqdan necə dizayn etməyə başlamaq barədə düşünürəm.

Və daha da ...

Tapşırığı necə modelləşdirməyi bilmirəm. OOP-in proqramda real dünyanın obyektlərini göstərməyə imkan verdiyi güman edilir. Ancaq əslində, bir itim var (iki qulaq, dörd pail və yaxası ilə) və bank hesabı (menecer, katiblər və nahar fasiləsi ilə) və proqramda, mahala, mahala kabineti ... yaxşı, başa düşdün. Və nöqtə deyil, proqramın real dünyanın obyektlərini əks etdirməyən köməkçi dərsləri var. Fakt budur ki nəzarət axını dəyişir. Gəzən adam məni bir it ilə gəzməkdən məmnunluqdan məhrum edir və bir ruhsuz banckschta (Hey, keçən həftə pulu dəyişdiyim şirin qız haradadır?).

Bəlkə snob edərəm, amma iti və ya bank hesabımı təsvir etsəm də, kompüterdəki məlumatlar sadəcə məlumat olsaydı, daha çox xoş idim. Məlumatlarla, real dünyaya gəlmədən rahat olanı edə bilərəm.

Funksionallığı necə parçalayacağını da bilmirəm. Python və ya C ++ içərisində, bir simli bir nömrəyə çevirmək üçün kiçik bir xüsusiyyətə ehtiyacım olsaydı, mən yalnız faylın sonunda yazdım. Java və ya C # -də, onu ayrı bir stringutils sinifində dözmək məcburiyyətindəyəm. Qısa-oo dillərində, ita bradkeri iki dəyəri funksiyadan geri qaytarmaq üçün elan edə bilərdim (hesabdakı məbləği və tarazlığı silindi). OOP dillərində, tam hüquqlu bir çıxış yazısı yaratmalı olacağam. Bir layihə üzrə yeni bir şəxs üçün (və ya bir həftə sonra məni də hətta məni) bu sinif sistem memarlığında vacib və əsaslı kimi görünəcəkdir. 150 fayl və eyni vacib və fundamental - oh bəli, şəffaf memarlıq, əla abstraksiya səviyyəsi.

Effektiv proqramları necə yazmağı bilmirəm. Effektiv proqramlar kiçik yaddaşdan istifadə edir - əks halda zibil kollektoru daim edamı yavaşlatacaqdır. Ancaq ən sadə əməliyyatı obyekt yönümlü dillərdə etmək üçün bir çox obyekt yaratmalısınız. Bir HTTP istəyini etmək üçün bir obyekt tipi URL, sonra HTTPConnection tipli bir obyekt, sonra obyekt növü tələbi yaratmaq lazımdır ... Yaxşı, başa düşürsən. Prosessual proqramlaşdırmada, sadəcə bir neçə proseduru onu yığın üzərində yaradılan quruluşu keçərək adlandırardım. Çox güman ki, yaddaşda yalnız bir obyekt yaradılacaq - nəticənin saxlanması üçün yaradılacaqdır. OOP-da daim yaddaşı tıxanmalıyam.

Bəlkə də oop həqiqətən gözəl və zərif bir paradiqmadır. Bəlkə də bunu başa düşmək üçün kifayət qədər ağıllı deyiləm. Yəqin ki, obyekt yönümlü bir dildə həqiqətən gözəl bir proqram yarada biləcək birisi var. Yaxşı, mən yalnız onlara həsəd apara bilərəm.

Obyekt yönümlü əsas prinsiplər və mərhələləri

proqramlaşdırma

Proqramlaşdırma nəzəriyyəsində OOP proqramın təqdimatına əsaslanan kompleks proqram yaratmaq texnologiyası kimi müəyyən edilir, bunların hər biri müəyyən bir növ (sinif) bir nümunəsi olan obyektlər dəsti şəklindədir və dərslər bir iyerarxiya meydana gətirir

vərəsəlik xüsusiyyətləri.

Bu cür bir sistemdəki proqram obyektlərinin qarşılıqlı əlaqəsi mesaj göndərməklə həyata keçirilir.

QEYD.Proqramın belə bir təqdimatı ilk dəfə 60-cı illərdə görünən mürəkkəb simula sistemlərinin simulyasiya modelləşdirilməsi dilində istifadə edilmişdir.

Təbii modelləşdirmə dilləri Proqramın təqdim edilməsi metodu başqa bir ixtisaslaşdırılmış modelləşdirmə dilində - Smallalk dilində (70-ci illərdə) hazırlanmışdır, sonra da sonra hazırlanmışdır

Səhifə 2 of 51

OOO-nun əsas prinsipləri

paskal, C ++, məsələn, universal proqramlaşdırma dillərinin yeni versiyalarında istifadə olunur

Ooosun əsas üstünlüyü- Modullar arasında ötürülən məlumatların miqdarının artması və azalma sayının azaldılması,

modul proqramlaşdırma ilə müqayisədə. Bu, məlumatların daha tam lokalizasiyası və emalı subprogrammalarla inteqrasiya edilməsi səbəbindən nail olunur,

fərdi hissələrin praktik olaraq müstəqil inkişafı aparmağa imkan verir

proqramın (obyektləri).

Bundan əlavə, obyekt yanaşması kimi inkişafın yeni texnoloji vasitələrini təklif edir vərəsəlik, polimorfizm, kompozisiya, doldurma,

mürəkkəb əşyaların dizaynına daha sadə olan. Nəticədə kodların təkrar göstəricisi əhəmiyyətli dərəcədə artır,

müxtəlif tətbiqlər və inkişaf etdiricilər üçün obyekt kitabxanaları yaratmaq imkanı, artan mürəkkəblik sistemlərinin yaradılması üçün əlavə imkanlar təqdim olunur.

OOP-ın əsas dezavantajı, proqram sisteminin daha mürəkkəb bir təşkili səbəbindən sürəti azaldılır.

OOP aşağıdakı PR və N C və N S: Abstrakion-a əsaslanır,

giriş məhdudiyyəti, modulilik, iyerarxiya, tipifikasiya, paralelizm,

sabitlik.

Hər prinsipin nə olduğunu düşünün.

A b s t r a g və r in və n və e- Problemin mövzusunda abstraksiyaların ayırması prosesi. Abstraksiya, bütün digər obyektlərin bütün növlərindən fərqləndirən bəzi obyektlərin vacib xüsusiyyətləridir və

beləliklə, bu obyektin xüsusiyyətlərini daha da nəzərdən keçirmək və təhlil baxımından dəqiq müəyyənləşdirin. Tərifinə görə, həqiqi obyektin istifadə olunan abstraksiyası həll olunan vəzifədən əhəmiyyətli dərəcədə asılıdır, bir halda, digər çəkidə, mövzu şəklində maraqlanacağıq

Üçüncüsü - dördüncüsündə edilən materiallar - hərəkət qanunu

51-dən 3-ü

OOO-nun əsas prinsipləri

mövzu və s. Abstraksiya səviyyəsinin mövcud səviyyəsi, abstraksiyanın bütün xüsusiyyətlərini birləşdirməyi əhatə edir (analiz olunan obyektin vəziyyətinə aid olduğu kimi,

və davranışını müəyyənləşdirmək) bir proqram vahidində bəziləri

mücərrəd tip (sinif).

Giriş məhdudiyyəti- bütövlükdə bunun vacib xüsusiyyətlərinə təsir göstərməyən abstraksiya həyata keçirilməsinin fərdi elementlərini gizlətmək.

Girişin məhdudlaşdırılması ehtiyacı, abstraksiya şərhi ilə iki hissə arasındakı fərqi əhatə edir:

İnterfeys kənardan mövcud olan mövcud abstraksiya elementlərinin (dövlətin əsas xüsusiyyətləri və davranış xüsusiyyətləri) bir sıradir;

İcra - Abstraksiya həyata keçirilmə elementlərinin kənarından (davranışının icrası üçün daxili təşkilat və mexanizmlərin daxili təşkilatı) xaricində əlçatmaz bir sıra.

OOP-da giriş məhdudiyyəti inkişaf etdiriciyə imkan verir:

istifadə olunan abstraksiyaların həyata keçirilməsinin xüsusiyyətləri ilə sistemdəki sistemin dizaynını həyata keçirmir;

düzgün mütəşəkkil bir sistemdə digər obyektlərdə dəyişiklik tələb etməyəcəyi fərdi obyektlərin tətbiqini dəyişdirmək asandır.

Mövzunun bütün xüsusiyyətlərini (vəziyyəti və davranış komponentləri) bir abstraksiya və bu xüsusiyyətlərin həyata keçirilməsinə imkan yaratmaq üçün məhdudiyyətlərin birləşməsi kaplama adını aldı.

M o d o l n o s t b- Proqram inkişafı prinsipi,

icrasını fərdi hissələr şəklində (modullar) şəklində cəlb etmək. Modullarda bir sistem parçalanması edərkən, modullar arasındakı xarici bağlantıların sayının azaldılmasını təmin edən, məntiqi ilə əlaqəli hissələri birləşdirmək istənir. Prinsipi miras qaldı.

51-dən 41-ə qədər

OOO-nun əsas prinsipləri

modul proqramlaşdırma, bunun ardınca dizayn və dizaynını asanlaşdırır və

dİQQƏT Proqramı.

Və e r a r x və mən - sıralanmış və ya sifariş edilmiş abstraksiya sistemi.

İerarxiya prinsipi, proqram sistemlərinin inkişafında iyerarxiyaların istifadəsini əhatə edir.

OOP iki növ iyerarxiyadan istifadə edir.

Hiyerarxiya "Bütöv / hissə"- Bəzi mücərrədlərin daxil olduğunu göstərir

baxılan abstraksiya, bunun bir hissəsi kimi, məsələn, lampa bir baza, közərmə ipləri və qabıqlardan ibarətdir. Hiyerarxiyanın bu versiyası, sistemin müxtəlif mərhələlərində (məntiqi səviyyədə - fənni səviyyəsində, fiziki səviyyədə, modullarda sistemin parçalanması zamanı subyekt sahəsinin parçalanması zamanı istifadə olunur Multiprocess sistemində fərdi proseslərin seçilməsi zamanı).

İerarxiya "Ümumi / Şəxsi"- Bəzi abstraksiya, məsələn, "Yemək masası -" başqa bir abstraksiya haqqında xüsusi bir hal olduğunu göstərir.

xüsusi bir masa növü "və" masalar konkret mebel növüdür. " Tərəfindən istifadə olunur

mürəkkəb siniflər, mürəkkəb siniflər, onlara yeni xüsusiyyətlər əlavə etmək və bəlkə də dəqiqləşdirmələr mövcuddur.

OOP-ın ən vacib mexanizmlərindən biri də ümumi / özəllik iyerarxiyasındakı xüsusiyyətlərin mirasıdır. Vərəsəlik, onlardan biri digər və ya bir neçə digər mücərrədin struktur və ya funksional hissəsindən istifadə etdikdə (müvafiq olaraq sadə və birdən çox)

miras).

T və p və c və c və c və i - obyektlərin xüsusiyyətlərinə qoyulan məhdudiyyət və

müxtəlif növ abstraksiyaların əvəzlənməsinin qarşısını alır (və ya belə bir əvəz ehtimalının güclü şəkildə daralması). Hər bir proqram obyekti üçün sıx yazaraq (dəyişən, subroutine, parametr və s.)

bir çox əməliyyatı təyin edən bir növ elan etdi

51-dən 51-ə qədər

OOO-nun əsas prinsipləri

müvafiq proqram obyekti. Aşağıdakı Paskal əsaslı proqramlaşdırma dilləri ciddi və c əmzik kimi istifadə olunur -

yazma orta dərəcəsi.

Yazma prinsipindən istifadə edərək aşağıdakıları təmin edir:

proqram obyektləri üzərində qəbuledilməz əməliyyatlar ilə əlaqəli səhvlərin erkən aşkarlanması (bu əməliyyatın obyektində bu əməliyyatın məqbul olduğunu yoxlayarkən proqramın tərtib mərhələsində aşkar edilmişdir);

sadələşdirilmiş sənədlər;

daha səmərəli kod yaratmaq imkanı.

Növü proqram obyektinə statik olaraq bağlana bilər (obyekt növü tərtib mərhələsində müəyyən edilmişdir - erkən bağlama)və dinamik (obyekt növü yalnız proqram zamanı müəyyən edilir - sonradan bağlama).Proqramlaşdırma dilində gecikmiş gecikmiş tətbiq etmək, dəyişənlər yaratmağa imkan verir - müxtəlif siniflərə aid əşyalara göstəricilər (polimorf obyektləri),dilin imkanlarını əhəmiyyətli dərəcədə genişləndirir.

P a r və l l l l və z m- Bir neçə mücərrədin əmlakı eyni zamanda aktiv vəziyyətdə olmaq, i.E. Bəzi əməliyyatları həyata keçirin.

Çözümü bəzi ardıcıllıqların eyni vaxtda həyata keçirilməsini tələb edən bir sıra vəzifələr var. Bu kimi vəzifələrə,

məsələn, birdən çox prosesin avtomatik idarə olunmasının vəzifələri daxildir.

Həqiqi paralelizm yalnız hər bir prosesi ayrı bir prosessor tərəfindən yerinə yetirmək mümkün olduqda bu tip multiprocessor sistemlərində vəzifələri həyata keçirərkən əldə edilir. Bir prosessor olan sistemlər, müxtəlif proseslərin idarə edilməsi vəzifələri arasında prosessor vaxtını ayıraraq paralelliyi təqlid edir. İstifadə olunan əməliyyat sistemi növündən asılı olaraq (çox multiproqram)

51-dən 6-cı səhifə

OOO-nun əsas prinsipləri

vaxt ayırması ya sistem tərəfindən hazırlanmışdır (içəridə)

Ms dos) və ya istifadə olunan OS (hər ikisi Windows sistemlərində).

U s t o th h və t ilə t ilə- Bu proqram obyektini və / və ya kosmosda yaradılan bu proqram obyektini və / və ya kosmosda yaranan, bu proqramda meydana gələn, yaradılan ünvandan asılı olmayaraq, vaxtında mövcud olan abstraksiya mülkiyyəti.

Fərqli:

Cuting kimi bəzi hərəkətlərin aralıq nəticələrini saxlayan müvəqqəti obyektlər;

∙ Subpprogramların içərisində olan yerli obyektlər, ömrü boyuogrogrogrogrogrogramın içərisindən hesablanır;

Proqram yaddaşa yüklənərkən mövcud olan qlobal obyektlər;

Proger məlumatları proqram iş seansları arasında xarici yaddaş sənədlərində saxlanılan obyektləri saxladı.

Yuxarıda göstərilən prinsiplərin hamısı bir dərəcə və ya digərinə obyekt yönümlü dillərin müxtəlif versiyalarında həyata keçirilir.

Obyekt yönümlü proqramlaşdırma dilləri. Dil hesab olunur obyekt yönümlü Yeddi prinsipin ilk dördü həyata keçirilmişdirsə.

Xüsusi yer Obyekt modellərini Delphi və C ++ qurucusu. Bu modellər MS DOS üçün EPO təcrübəsini ümumiləşdirin və bəzi yeni fondlar daxil edin,

daha mürəkkəb sistemlərin səmərəli yaradılmasını təmin etmək. Bu modellər əsasında Windows tətbiqetmələrini inkişaf etdirmək üçün vizual mühitlər yaradılıb.

Windows altındakı proqramlaşdırma mürəkkəbliyi əhəmiyyətli dərəcədə idarə edildi

obyektlərin xüsusi kitabxanaları yaratmaqla, "gizli" proqramlaşdırma texnikasının bir çox elementləri yaradır.

51-dən çox

OOO-nun əsas prinsipləri

OOP istifadə edərək proqram sistemlərinin inkişaf mərhələləri.

OOP istifadə edərək proqram təminatının inkişafı prosesi dörd mərhələ ehtiva edir: analiz, dizayn, təkamül, modifikasiya.

Bu mərhələləri nəzərdən keçirin.

Və n və l və h Təhlilin məqsədi problemin maksimum tam təsviridir. Bu mərhələdə tapşırığın mövzunun subyektinin təhlili aparılır, sistemin obyektin parçalanması və obyektlərin davranışının ən vacib xüsusiyyətləri müəyyənləşdirilir (Abstraktlar təsviri). Təhlilə görə, proqram məhsulunun struktur diaqramı inkişaf etdirilir, bu da aralarında ötürülən əsas obyektləri və mesajları göstərir və abstraksiya təsviri təsvir edilmişdir.

Layihə. Fərqli:

məntiqi dizaynmüəyyən edilmiş qərarların praktik olaraq əməliyyat şərtlərindən (işləmə sistemi və istifadə olunan avadanlıqlardan asılı deyil;

fiziki dizayngöstərilən amillərin nəzərə alınması lazım olan.

Məntiqi dizayndərslərin quruluşunu inkişaf etdirməkdir:

obyektlərin obyektlərinin komponentlərinin və obyektlərin davranışının aspektlərini həyata keçirən metodların alqoritmlərinin saxlanması sahələri müəyyən edilir. Eyni zamanda, siniflərin yuxarıda göstərilən inkişaf metodlarından istifadə olunur (miras,

tərkibi, doldurma, polimorfizm və s.). Nəticə dərslərin və dərslərin təsvirini əks etdirən, siniflərin iyerarxiyası və ya cədvəli, siniflərin təsviridir.

Fiziki dizaynmodullarda sinif təsvirlərini birləşdirərək, onların bağlantısının (statik və ya dinamik layout), avadanlıqla necə qarşılıqlı əlaqə qurmağı müəyyənləşdirərək

Əməliyyat sistemi və / və ya digər proqram (məsələn,

verilənlər bazası, şəbəkə proqramları), paralel emal sistemləri üçün proseslərin sinxronizasiyasını təmin etmək və s.

Səhifə 8-dən 51

OOO-nun əsas prinsipləri

E - mən l u t i s və t e m ilə.Bu mərhələli şəkildə həyata keçirilmə prosesidir və

dərsləri layihəyə qoşmaq. Proses əsas proqramın yaradılması və ya gələcək proqram məhsulunun layihəsi ilə başlayır. Aşağıdakı siniflər daha sonra kobud yaratmaq üçün tətbiq olunur, amma mümkünsə,

gələcək sistemin prototipi. Test edildi və debuged.

Məsələn, bu prototip proqram təminatının əsas interfeysinin həyata keçirilməsini özündə cəmləşdirən bir sistem olaraq xidmət edə bilər (Sistemi itkin sistemə mesajların köçürülməsi sistemində icra edilmir). Nəticədə, məsələn, tələblərə aydınlıq gətirmək üçün müştəriyə göstərilən sağlam bir məhsul prototipi alırıq. Növbəti siniflər qrupu, məsələn, bəzi menyu elementinin həyata keçirilməsi ilə əlaqəli sistemlə əlaqəlidir.

Yaranan seçim, sistemin bütün imkanlarını həyata keçirmədən əvvəl və s.

Mərhələli həyata keçirilmənin istifadəsi, proqram məhsulunun sınaq və ayırmasını əhəmiyyətli dərəcədə asanlaşdırır.

Modifikasiya. Bu, yeni funksionallıq əlavə etmək və ya sistemin mövcud xüsusiyyətlərini dəyişdirmək prosesidir. Ümumiyyətlə,

dəyişikliklər, OOP istifadə edərkən, adətən xüsusi çətinliklər olmadan başa çatdıqda, adətən, yerli əraziyə təsir edən bir interfeysini dəyişdirərək, dəyişməz interfeysini tərk edir.

İnterfeysdəki dəyişiklik də çox çətin bir iş deyil, lakin onun həlli, proqramın digər siniflərində dəyişiklik tələb edəcək obyektlərin qarşılıqlı əlaqəsi proseslərini uyğunlaşdırmaq ehtiyacına səbəb ola bilər. Bununla birlikdə, modul proqramı ilə müqayisədə interfeysdəki parametrlərin sayının azalması bu prosesi xeyli asanlaşdırır.

Modifikasiyanın sadəliyi, proqram sistemlərini böyük müvəqqəti və maddi ehtiyatlar tərəfindən sərf olunan sistemlərin ömrü boyu artıran əməliyyat şərtlərini dəyişdirmək üçün nisbətən asanlıqla uyğunlaşdırmağa imkan verir.

51-dən 9-a qədər

OOO-nun əsas prinsipləri

OOP-ın bir xüsusiyyəti odur ki, obyektin obyekti və ya qrupu ayrıca inkişaf etdirə bilər və buna görə də onların dizaynı müxtəlif mərhələlərdə ola bilər. Məsələn, interfeys dərsləri artıq həyata keçirilir və obyekt siniflərinin quruluşu hələ də müəyyən edilmişdir.

Tipik olaraq, dizayn analiz prosesində subyekt sahəsinin hər hansı bir parçası tam təsvir edildikdə dizayn başlayır.

Obyekt yanaşmasının əsas texnikalarının obyektin parçalanması ilə başlanmasına baxılması.

Obyektin parçalanması

Yuxarıda qeyd edildiyi kimi, OOP texnologiyasından istifadə edərkən qərar şəklində təqdim olunur fərdi funksional elementlərin qarşılıqlı əlaqəsinin nəticəsibəzi sistem təqlid edən proseslər,

tapşırığın mövzu bölgəsində nə baş verir.

Belə bir sistemdə, hər bir funksional element, problemin həlli prosesində bəzi giriş effekti (mesaj adlanır) alaraq,

Əvvəlcədən müəyyən edilmiş hərəkətləri yerinə yetirir (məsələn, öz dövlətinizi dəyişə, bəzi hesablamaları yerinə yetirə bilər, bir pəncərə və ya cədvəl çəkin və digər elementlərə təsir etmək üçün növbə ilə). Tapşırıq həlli prosesi idarə edir mesajların ardıcıllığı.Bu mesajları əşyadan əşyaya ötürməklə, sistem lazımi hərəkətləri həyata keçirir.

Sistemin, parametrlər və davranışların funksional elementləri, müstəqil davranış probleminin vəziyyəti ilə müəyyən edilir

(İ.E., "ablering", alınan mesajlardan və elementin vəziyyətindən asılı olaraq bəzi hərəkətləri yerinə yetirmək üçün) obyektlərin adını aldı.

Problemin mövzu sahəsini mesaj mübadiləsi toplusu şəklində təmsil edən prosesi deyilir obyekt parçalanması.

51-dən 10-a qədər

OOO-nun əsas prinsipləri

Hər bir halda obyekt parçalanmasını həyata keçirərkən hansı obyektlərin və mesajların söz mövzusu olduğunu başa düşmək üçün, bu, ilk obyekt yanaşmasının mürəkkəb sistemlərin davranışının təqlid modellərinin inkişafı üçün təklif olunduğunu xatırlamaq lazımdır. Bu cür sistemlərin obyektlərinin toplusu, simulyasiya edilmiş prosesləri təhlil edərkən ümumiyyətlə müəyyən edilir.

Misal. Obyekt parçalanması (təqlid modeli)

qaz doldurma məntəqəsi). Yanacaqdoldurma yerlərinin növbəsinin uzunluğunun yanacaq doldurma yerləri, hər bir yanacağın xidmət parametrləri və yanacaq doldurma üçün tətbiqlərin intensivliyini və yanacağın yanacağının bağlanması ilə maraqlanacağımızı bildirək (eyni tipli yanacağın yanacağını düşünürük) ).

Bu növün vəzifələri ümumiyyətlə təqlid modellərindən istifadə edərək həll olunur. Model, xüsusi bir prosesi müəyyən bir parametrlə, paralel olaraq müəyyənləşdirərək simulyasiya edir. Xidmət parametrlərinin müxtəlif dəyərləri və ya tətbiqlərin alınması ilə təqlid prosesini təkrarlamaq, tədqiqatçı təhlil olunan asılılığın qrafiklərinin qurulması xüsusiyyətlərinin müəyyən dəyərlərini alır.

Üç doldurma yeri olan yanacaqdoldurma məntəqəsinin istismarı prosesi diaqram kimi təmsil oluna bilər.

Obyekt yönümlü dillərdə necə proqramlaşdırılacağını bilmirəm. Öyrənmədi. Java-da 5 illik sənaye proqramlaşdırmadan sonra hələ də obyekt yönümlü üslubda yaxşı bir sistem yaratmağı hələ bilmirəm. Sadəcə başa düşmürəm.

Dürüstcə necə olmağı öyrənməyə çalışdım. Nümunələri öyrəndim, Kod Açıq Mənbə Layihələrini oxuyun, başımda incə anlayışlar qurmağa çalışdım, lakin keyfiyyətli obyekt yönümlü proqramlar yaratmaq prinsiplərini başa düşmədim. Bəlkə də başqası onları başa düşdü, amma mən deyil.

Mənə anlaşılmazlığa səbəb olan bəzi şeylər var.

Oopun nə olduğunu bilmirəm

Ciddi. Oopun əsas fikirlərini formalaşdırmaq mənim üçün çətindir. Funksional proqramlaşdırma şəraitində əsas fikirlərdən biri dövlətin olmamasıdır. Struktur - parçalanma. Modulda - işlək bloklarda funksionalın ayrılması. Bu paradiqmaların hər hansı birində dominant prinsiplər kodun 95% -ə tətbiq olunur və dil istifadə etməyə təşviq etmək üçün hazırlanmışdır. Oop üçün bu cür qaydaları bilmirəm.
  • Abstraksiya
  • Kasadlama
  • Miras
  • Polimorfizm
Qaydalar toplusuna baxır, elə deyilmi? Beləliklə, budur, halların 95% -də təqib etmək lazım olan çox qaydalar varmı? Hmm, daha yaxından baxaq.

Abstraksiya

Abstraksiya güclü bir proqramlaşdırma vasitəsidir. Böyük sistemlər qurmağa və onlara nəzarəti qorumağa imkan verən şeydir. Heç olmasa belə bir vasitə ilə silahlanmadığı təqdirdə bu günün bugünkü proqram səviyyəsinə yaxın olmayacağımız mümkün deyil. Ancaq abstraksiya oopla necə əlaqəlidir?

Birincisi, abstraksiya yalnız OOP və ümumilikdə proqramlaşdırma bir atribut deyil. Abstraksiya səviyyələrinin yaradılması prosesi demək olar ki, insan biliklərinin bütün sahələrinə paylanır. Beləliklə, molekulyar quruluşunun təfərrüatlarına girmədən materiallar haqqında mühakimə edə bilərik. Və ya edildiyi materiallar deyil, maddələr haqqında danışın. Və ya bir kompüter, bir təyyarə turbin və ya insan bədəni kimi mürəkkəb mexanizmlər haqqında mübahisə edin, bu qurumların fərdi təfərrüatlarını xatırlamıram.

İkincisi, proqramlaşdırma tarixində ilk hesab olunan ADU Lavleisin qeydlərindən başlayaraq, proqramlaşdırma üzrə abstraksiyalar həmişə idi. O vaxtdan bəri insanlar əvvəllər proqramlarında, tez-tez yalnız ən sadə məna daşıyan proqramlarında abstraksiya yaratdılar. Beləliklə, Abelson və Sassman, istenmeyen kitablarında, yalnız prosedur və əlaqəli siyahıları olan mürəkkəb nömrələrə və hətta polinomiyalara dəstək olan tənliklərin həlli sisteminin necə yaradılmasını təsvir edir. Beləliklə, abstraksiya oopu hansı əlavə vasitələr daşıyır? Heç bir fikrim yoxdur. Subprogramme kodu seçin? Bu, hər hansı bir yüksək səviyyəli dildədir. Subroutinləri bir yerdə birləşdirin? Bunun üçün kifayət qədər modul. Tiplifik? Oopdan çox əvvəl idi. Tənzimləmə tənlikləri sistemi olan bir nümunə yaxşı göstərir ki, abstraksiya qurma səviyyələri bu qədər çox deyil, proqramçıların qabiliyyətlərindən olduğu kimi dil vasitələrindən çox deyil.

Kasadlama

Həyata keçirilməsində əsas viser encapsulasiyası. Müştəri kodu yalnız interfeysi görür və yalnız bu sayıla bilər. Bu, həyata keçirilməni dəyişdirmək qərarına gələ bilən inkişaf etdiricilərin əllərini açır. Və həqiqətən də sərindir. Ancaq sual yenidən budur, sonra oop? Hər şey Yuxarıda göstərilən paradiqmalar həyata keçirilməni gizlədir. Header sənədlərində interfeysi vurğuladığınız, Oberon, Oberon, modul üçün yerli və metodları yerli hala gətirməyə imkan verir, nəhayət, bir çox dildə abstraksiya, sadəcə tətbiqetməni də icrasını əhatə edən subroutinlər vasitəsi ilə qurulur. Üstəlik, obyekt yönümlü dillər çox vaxt İncapsulyasiya qaydasını pozmaqXüsusi metodlar vasitəsilə məlumatlara giriş təmin etməklə - Java-da Getters və Sırala, C # və s. (Şərhlərdə proqramlaşdırma dillərində bəzi obyektlərin OOP baxımından obyektlərin olmadığı aşkar edildi: Məlumat ötürmə obyektləri məlumat ötürülməsinə cavabdehdir və buna görə də oopun tam varlıqları deyil və buna görə də orada Encapsulasiyanı qorumağa ehtiyac yoxdur. Digər tərəfdən, memarlığın elastikliyini qorumaq üçün imkan vermək daha yaxşıdır. Beləliklə, hər şey asan deyil.) Bundan əlavə, piton kimi bəzi obyekt yönümlü dillər, bir şey gizlətməyə çalışmayın Ümumiyyətlə, ancaq bu kodu istifadə edərək inkişaf etdiricilərin rasionallığını hesablayın.

Miras

Vərəsəlik oop sayəsində həqiqətən səhnəyə çıxan bir neçə yeni şeylərdən biridir. Xeyr, obyekt yönümlü dillər yeni bir fikir yaratmadı - miras başqa bir paradiqmada tam şəkildə həyata keçirilə bilər - ancaq OOP əvvəlcə bu konsepsiyanı dilin səviyyəsinə gətirdi. Meyvanın açıq və üstünlükləri: nə vaxt təqribən Bəzi sinif üçün uyğundur, nəsil yarada və funksionallığının bir hissəsini ləğv edə bilərsiniz. C ++ və ya Scala kimi birdən çox mirasını dəstəkləyən dillərdə (sonuncuda - əlamətlər hesabına), digər istifadə seçimi görünür - mixinlər, kiçik siniflər, "qəbul etmə" funksiyasını yeni bir sinfə təqdim etməyə imkan verir Kod.

Beləliklə, oopu digərləri arasında bir paradiqma kimi ayıran şey budur? Hmm ... Əgər belədirsə, niyə nadir hallarda real kodda istifadə edirik? Unutmayın, mən dominant paradiqmanın qaydalarını təqdim edən kodun 95% -ni danışdım? Zarafat etmədim. Funksional proqramlaşdırma, kodun ən azı 95% -i yan təsirləri olmadan dəyişməz məlumat və funksiyalardan istifadə edir. Modullarda, demək olar ki, bütün kod məntiqi olaraq modullarla qablaşdırılır. Yazıq qurulmuş struktur proqramlaşdırma, Daekstra, proqramın bütün hissələrini kiçik hissələrə bölməyə çalışın. Vərəsəlik daha az yaygındır. 10% kodda ola bilər, bəzi hallarda (məsələn, çərçivə siniflərindən miras qaldıqda) - 70% -də ola bilər, lakin daha çox deyil. Çünki əksər hallarda bu sadəcə lazım deyil.

Üstəlik, miras təhlükəli Yaxşı dizayn üçün. Kitabdakı dörd (oopun təbliğçisi) dəstəsi, onu heyətlə əvəz etmək mümkün olduğunu tövsiyə edir. Məşhur dillərdə mövcud olan formada miras indi kövrək bir dizayna aparır. Bir əcdaddan miras alan, sinif artıq başqalarından miras qala bilməz. Atanın dəyişməsi də təhlükəlidir. Əlbəttə ki, özəl / qorunan dəyişdiricilər var, lakin sinifin necə dəyişə biləcəyini və müştəri kodunun necə istifadə edə biləcəyini təxmin etmək üçün açılmamış ekstrasensorluq qabiliyyətlərini də tələb edirlər. Vərəsəlik o qədər təhlükəli və əlverişsizdir ki, böyük çərçivələr (məsələn, Java-da yaz və Ejb kimi) onlardan imtina edir, başqalarına, obyekt yönümlü vasitələr (məsələn, metaproqrominq). Nəticələri bu qədər gözlənilməzdir ki, bəzi kitabxanalar (guava kimi) miraslarına miras alan və yeni gediş dilində miras iyerarxiyasından imtina etmək qərara alındı.

Polimorfizm

Bəlkə də polimorfizm obyekt yönümlü proqramlaşdırmada ən yaxşı şeydir. Polimorfizm sayəsində tipli şəxsin obyekti "Shandorkin Adam Impolitoviç" və obyekt tipli nöqtəsi kimi görünür ". "Mat1 * Mat2" yazmağa və adi nömrələrin məhsuluna bənzər matris məhsullarını əldə etməyə imkan verən odur. Onsuz, şəbəkədən, fayldan və ya cizgilərdən, fayldan və ya satırlardan bəhs etmədən, giriş axınından məlumatı oxuya bilməzdi. İnterfeyslərin olduğu hər yerdə, polimorfizm də nəzərdə tutulur.

Həqiqətən polimorfizmi sevirəm. Buna görə də, onun problemləri barədə əsas dillərdə də danışmayacağam. Mən də göndərmə yanaşmasının darlığı haqqında yalnız növü və bunun necə edilə biləcəyi barədə susacağam. Əksər hallarda, lazım olduğu kimi işləyir və bu artıq pis deyil. Sual budur: Polimorfizm, oopu digər paradiqmalardan fərqləndirən prinsipi isə? Məndən soruşsanız (və bu mətni oxudusunuzsa, bu, soruşduğumuzu düşünə biləcəyimiz deməkdir, "yox" cavabını verərdim. Və səbəb hər şey kodda istifadə nisbətindədir. Yəqin ki, interfuzalar və polimorfik metodlar bir az daha çox mirasdır. Adi prosedur üslubunda yazılmış sətirlərin sayı ilə işğal edilmiş kodun satırlarının sayını müqayisə edin - ikincisi həmişə daha böyükdür. Belə bir proqramlaşdırma tərzini təşviq edən dillərə baxaraq, onlara polimorf adlandıra bilmirəm. Polmorfizmin dəstəyi ilə dillər - Bəli, normaldır. Ancaq polimorf dilləri deyil.

(Ancaq bu mənim fikrimdir. Həmişə razı ola bilərsiniz.)

Beləliklə, abstraksiya, encapsulation, miras və polimorfizm - bütün bunlar OOP-dadır, amma bu heç bir şey onun xas olan atributudur. Onda bir oop nədir? Obyekt yönümlü proqramlaşdırmanın mahiyyətinin əslində, obyektləri (olduqca məntiqli) və dərslərdə olduğu güman edilir. Bu, kod və məlumatları, eləcə də proqramdakı obyektlərin real dünyanın mahiyyətini əks etdirməsi fikri birləşdirmək fikridir. Bu fikrə qayıdacağıq, amma başlanğıc üçün bir neçə xalları I ilə qıracağıq.

Kimin oop soyuducu?

Əvvəlki hissədən, proqramlaşdırma dillərinin obyekt yönümlü proqramlaşdırma üsulu ilə çox fərqli ola biləcəyini görmək olar. Bütün dillərdə OOP-ın bütün tətbiqetmələrini bir dəst götürsəniz, çox güman ki, bütün əlamətlər üçün bir ümumi bir şey tapa bilməzsiniz. Bu zooparkı birtəhər məhdudlaşdırmaq və əsaslandırmaq üçün aydınlıq gətirmək, yalnız bir qrup - sırf yönümlü dillərdə, yəni Java və C # yaşayacağam. Bu vəziyyətdə "saf obyekt yönümlü" termini dilin digər paradiqaları dəstəkləmir və ya eyni OOP vasitəsilə tətbiq etməsi deməkdir. Məsələn, piton və ya yaqut, mən təmiz olmayacağam, çünki Bir sinif bəyanatı olmadan onlara asanlıqla tam hüquqlu bir proqram yaza bilərsiniz.

Java və C # -də Oopun mahiyyətini daha yaxşı başa düşmək üçün, bu paradiqmanın digər dillərdə həyata keçirilməsinə dair nümunələr üzərində çalışırıq.

SmallTalk. Müasir həmkarlarından fərqli olaraq, bu dildə oopu həyata keçirmək üçün dinamik yazma və istifadə olunan mesaj ötürmə tərzi var idi. Çağırış metodları əvəzinə, obyektlər bir-birinin mesajlarını göndərdi və alıcının nə gəldiyini emal edə bilmədikdə, sadəcə başqasına bir mesaj göndərdi.

Ümumi lisp. Əvvəlcə CL eyni paradiqma yapışdı. Geliştiricilərin bundan sonra `(obj göndər" ni biraz mesaj) yazmaq qərarına gəldilər - bu çox uzun və metoduna (bəzi üsul) adlandırmaq üçün notation dəyişdirildi. Bu gün, ümumi LISP inkişaf etmiş bir obyekt yönümlü bir proqramlaşdırmanı var Bir çox miras, multimeter və metaklar üçün dəstək ilə sistem (CLO). Fərqli bir xüsusiyyət, cl-dəki Oopun obyektlərin ətrafında deyil, ümumiləşdirilmiş funksiyaların ətrafında olmasıdır.

Klojure. Clojure, 2 obyekt yönümlü proqramlaşdırma sistemi - Java-dan miras qalan, ikincisi, multimethodlara və daha çox bənzər bir şəkildə var.

R. Statistik məlumatların təhlili üçün bu dildə 2 obyekt yönümlü proqramlaşdırma sistemi - S3 və S4 var. Hər ikisi də dildə miras qalır (təəccüblü deyil, bu r-nin kommersiya slopland sandıq satılmasıdır). S4 üçün ən çox, oopun müasir əsas dillərində reallaşdırılması ilə qarşılaşır. S3 daha yüngül bir seçimdir, elementar, dilin özü: bir ümumi funksiya yaranan obyektin "sinif" atributu ilə sorğuları göndərilir.

JavaScript. Digər bir sintaksis istifadə etsə də, kiçiktalka bənzər ideologiyaya görə. Vərəsəlik əvəzinə, prototiping istifadə edir: İstədiyiniz əmlak və ya obyektin özündə meydana gələn bir üsul yoxdursa, sorğu prototip obyektinə (bütün JavaScript obyektlərinin prototipi əmlakına) ötürülür. Prototipin metodlarından birini dəyişdirərək, bütün sinif obyektlərinin davranışının dəyişdirilməsi maraqlıdır (çox gözəl, məsələn, "Tobase64" sinif sinifini əlavə etmək kimi görünür).

Python. Ümumiyyətlə, o, eyni konsepsiyaya əsas anlayışa riayət edir, lakin bundan əlavə, bu, atribut axtarışının JavaScript və ya SmallTalk-da olduğu kimi başqa bir obyektə ötürülməsini dəstəkləyir.

Haskell. Haskell-də ümumiyyətlə heç bir dövlət yoxdur və buna görə də adi anlayışdakı əşyalar. Bununla birlikdə, bir növ OOP hələ də var: məlumat növləri (növləri) bir və ya daha çox növ növə aid ola bilər (tip siniflər). Məsələn, Haskell'in demək olar ki, hər növü bir EQ sinifində (2 obyektin müqayisə əməliyyatları üçün cavabdeh) və bütün nömrələr əlavə olaraq num siniflərində (ədədlər üzrə əməliyyatlar) və ord (əməliyyatlar)<, <=, >\u003d,\u003e). Menstrum dilləri növləri uyğun siniflər (məlumatlar) və tipli siniflər - interfeyslərdir.

Dövlət və ya vətəndaşsız?

Ancaq daha çox ümumi obyekt yönümlü proqramlaşdırma sistemlərinə qayıdın. Heç vaxt başa düşmədiyim şey, obyektlərin daxili vəziyyəti olan əlaqəsidir. OOP-ı öyrənmədən əvvəl hər şey sadə və şəffaf idi: bir neçə əlaqəli məlumatları saxlayan strukturlar var, prosedurlar (funksiyalar) var, emal edir. Gəzmək (it), çıxarın (hesab, məbləğ). Sonra obyektlər gəldi və bu da heç nə idi (proqramları oxumaq daha çətin olsa da, itim [kimin?] Və hesabı vurdu. Sonra məlumatların gizlədilməsi barədə məlumat əldə etdim. Mən hələ də köpək gəzə bilərdim, amma yeməyinin tərkibini görə bilmədim. Yemək heç bir hərəkət etməmişdir (yəqin ki, bu yeməyi yazmaq mümkün idi. (Köpək) yazın, amma yenə də itimin yemək yediyini və əksinə deyiləm). Yemək yalnız məlumatlardır və yalnız onlara daxil olmaq üçün (və itim) lazım idi. Hər şey sadəcə. Ancaq paradiqma çərçivəsində, 90-cı illərin sonundakı köhnə jeansda olduğu kimi, artıq mümkün deyildi.

Yaxşı, tamam, məlumat əldə etmək metodlarımız var. Gəlin bu kiçik özünü aldatma və həqiqətən gizlədiyimiz məlumatların olduğunu iddia edək. Ancaq indi bilirəm ki, obyektlər ilk növbədə məlumatlar, sonra, bəlkə də onların emal üsullarıdır. Proqramları dizayn edərkən səy göstərməli olduğunuz şeylərə necə yazmağı başa düşdüm.

Maariftenmentdən zövq almağa vaxtım yox idi, çünki internetdə vətəndaşsızdır, bu, parlaqlıqla əhatə olunmuşdur və t və l hərfləri üzərində asılmışdır). Ədəbiyyatın qısa bir araşdırması, şəffaf idarəetmə axınının və obyektin tutarlılığını izləməməsi lazım olan sadə bir nəzarət axınının gözəl bir dünyasını açdı. Əlbəttə ki, dərhal bu gözəl dünyaya toxunmaq istədim. Bununla birlikdə, bu, hər hansı bir qaydadan tamamilə imtina etmək idi - indi itin özü gəzdirməməsi və ya bunun üçün xüsusi bir keçid meneceri tələb olunduğu aydın deyildi; Hesabın lazım olub-olmaması, ya da bank bütün işlərin öhdəsindən gələ bilər və əgər varsa, pulu statik və ya dinamik şəkildə yazmalıdır və s. İstifadə seçimlərinin sayı eksponent olaraq və gələcəkdə bütün variantlar ciddi refaktorun ehtiyacına səbəb ola bilər.

Hələ də bir obyektin vətəndaşlığı olmayan nə vaxt verildiyini və yalnız bir məlumat konteyneri olduqda bilmədiyini bilmirəm. Bəzən göz qabağındadır, amma ən çox yox.

Tipifikasiyası: statik və ya dinamik?

C # və Java kimi dilləri haqqında müəyyən edə bilməyəcəyim başqa bir şey, onlar statik və ya dinamik olaraq yazılmışdır. Yəqin ki, əksər insanlar 'nə cəfəngiyat! Əlbəttə ki, statik olaraq yazılmışdır! Tərtib zamanı növləri yoxlanılır! " Ancaq həqiqətən bu qədər asandır? Doğrudanmı, bir proqramçı, metod parametrlərində qeydiyyatdan keçən X, X-nin X T Type X obyektləri olacağına əmin ola bilərmi? Doğru - edə bilməz, çünki X metodunda, X parametrini köçürə bilərsiniz ya da varisi. Görünür, buna görə nə? X heis-lər hələ də X. metodları metodları ilə eyni metodlara sahib olacaqlar, lakin işin məntiqi tamamilə fərqli ola bilər. Ən çox yayılmış hal, bu, bir uşaq sinfi X-dən daha çox ehtiyac duyduğu zaman, metodumuzun optimallaşdırılmasına inanmaq olar (əgər belə bir ssenari sizin üçün qeyri-real görünsə, bəzi inkişaf etmiş açıq mənbəyə bir plugin yazmağa çalışın Kitabxana - ya memarlıq və kitabxana alqoritmlərinin təhlili üçün bir neçə həftə vaxt keçirəcəksiniz və ya sadəcə uyğun bir imza ilə metodları qaldıracaqsınız). Nəticədə, proqram işləyir, lakin iş sürəti bir sifariş verir. Tərtib edənin baxımından hər şey düzgündür. Bu davranışın dəyişdirilə bilməsinə baxmayaraq, bir çox yerdə Java varisliyi adlanan Scala'nın, bir çox yerlərdə yalnız göstərilən tipin arqumentlərinə icazə verdiyi əhəmiyyətlidir.

Başqa bir problem, Java-da hər hansı bir obyektin əvəzinə və C #-də hər hansı bir nullable obyektin əvəzinə ötürülə bilən nulldur. NULL bir anda hər növə aiddir və eyni zamanda heç bir şeyə aid deyil. Null, nə sahələr, nə də metodları yoxdur, buna görə ona hər hansı bir müraciət (null yoxlanılması istisna olmaqla) bir səhvə səbəb olur. Deyəsən hər şey buna vərdiş edir, ancaq Haskell (və eyni Scala) ilə müqayisə etmək üçün xüsusi növlərdən (bəlkə də haskelldə, SCAL-da seçim etmək üçün), digər dillərdə null geri qaytara biləcəklər. Nəticədə Haskell haqqında tez-tez "Proqramı tərtib etmək çətindir, amma yenə də baş verərsə, bu, düzgün işləyir."

Digər tərəfdən, əsas dillər açıq şəkildə dinamik yazılmır və buna görə də bu cür xüsusiyyətlərə interfeyslərin sadəliyi və prosedurların elastikliyinə sahib deyil. Nəticədə Python və ya Lisp üslubunda yazmaq da mümkünsüz olur.

Fərq nədir, bütün qaydalar hələ də bilinirsə, bu yazmağın adı nədir? Fərq, hansı tərəfdən memarlıq dizaynına yaxınlaşacaqdır. Uzun müddət bir mübahisə, bir sistem necə qurulacaq: bir çox növ və az funksiya və ya bir neçə növ və bir çox funksiya varmı? İlk yanaşma Haskelldə, ikincisi LISP-də fəal istifadə olunur. Müasir obyekt yönümlü dillərdə bir şey istifadə olunur. Pis olduğunu söyləmək istəmirəm - yəqin ki, onun üstünlükləri var (sonunda, Java və C # çox dilli platformalar üçün bunu unutmamalısınız), amma hər dəfə yeni bir layihəyə başlayanda Dizayn və ya funksionallıqdan necə dizayn etməyə başlamaq barədə düşünürəm.

Və daha da ...

Tapşırığı necə modelləşdirməyi bilmirəm. OOP-in proqramda real dünyanın obyektlərini göstərməyə imkan verdiyi güman edilir. Ancaq əslində, bir itim var (iki qulaq, dörd pail və yaxası ilə) və bank hesabı (menecer, katiblər və nahar fasiləsi ilə) və proqramda, mahala, mahala kabineti ... yaxşı, başa düşdün. Və nöqtə deyil, proqramın real dünyanın obyektlərini əks etdirməyən köməkçi dərsləri var. Fakt budur ki nəzarət axını dəyişir. Gəzən adam məni bir it ilə gəzməkdən məmnunluqdan məhrum edir və bir ruhsuz banckschta (Hey, keçən həftə pulu dəyişdiyim şirin qız haradadır?).

Bəlkə snob edərəm, amma iti və ya bank hesabımı təsvir etsəm də, kompüterdəki məlumatlar sadəcə məlumat olsaydı, daha çox xoş idim. Məlumatlarla, real dünyaya gəlmədən rahat olanı edə bilərəm.

Funksionallığı necə parçalayacağını da bilmirəm. Python və ya C ++ içərisində, bir simli bir nömrəyə çevirmək üçün kiçik bir xüsusiyyətə ehtiyacım olsaydı, mən yalnız faylın sonunda yazdım. Java və ya C # -də, onu ayrı bir stringutils sinifində dözmək məcburiyyətindəyəm. Qısa-oo dillərində, ita bradkeri iki dəyəri funksiyadan geri qaytarmaq üçün elan edə bilərdim (hesabdakı məbləği və tarazlığı silindi). OOP dillərində, tam hüquqlu bir çıxış yazısı yaratmalı olacağam. Bir layihə üzrə yeni bir şəxs üçün (və ya bir həftə sonra məni də hətta məni) bu sinif sistem memarlığında vacib və əsaslı kimi görünəcəkdir. 150 fayl və eyni vacib və fundamental - oh bəli, şəffaf memarlıq, əla abstraksiya səviyyəsi.

Effektiv proqramları necə yazmağı bilmirəm. Effektiv proqramlar kiçik yaddaşdan istifadə edir - əks halda zibil kollektoru daim edamı yavaşlatacaqdır. Ancaq ən sadə əməliyyatı obyekt yönümlü dillərdə etmək üçün bir çox obyekt yaratmalısınız. Bir HTTP istəyini etmək üçün bir obyekt tipi URL, sonra HTTPConnection tipli bir obyekt, sonra obyekt növü tələbi yaratmaq lazımdır ... Yaxşı, başa düşürsən. Prosessual proqramlaşdırmada, sadəcə bir neçə proseduru onu yığın üzərində yaradılan quruluşu keçərək adlandırardım. Çox güman ki, yaddaşda yalnız bir obyekt yaradılacaq - nəticənin saxlanması üçün yaradılacaqdır. OOP-da daim yaddaşı tıxanmalıyam.

Bəlkə də oop həqiqətən gözəl və zərif bir paradiqmadır. Bəlkə də bunu başa düşmək üçün kifayət qədər ağıllı deyiləm. Yəqin ki, obyekt yönümlü bir dildə həqiqətən gözəl bir proqram yarada biləcək birisi var. Yaxşı, mən yalnız onlara həsəd apara bilərəm.

 

 

Bu maraqlıdır: