Tərcüməçidən: Təəssüf ki, ingilis dilində kifayət qədər çox oxusam da, ingilis dilindən tərcümədə əhəmiyyətli təcrübəm yoxdur. Amma məlum oldu ki, oxumaq və tərcümə etmək iki fərqli şeydir. Təəssüf ki, mənim əhəmiyyətli proqramlaşdırma təcrübəm yoxdur (mən bu yaxınlarda Spring MVC və Hibernate-də sadə bir veb proqram hazırladım). Buna görə də tərcümə ola biləcəyindən qat-qat pis çıxdı. Məqalədə verilmiş kod nümunələrini bir az düzəltmək hüququndan istifadə etdim, çünki onlar Java-dakı ad konvensiyalarına uyğun gəlmir. Bəlkə də bəzi naxışların adlarını tərcümə etməyə dəyməzdi (belə tərcümə o qədər də başa düşülə bilməz), amma mən düşündüm ki, bu, daha kiçik şərdir. “Yüksək koheziya” sözünün tərcüməsi kimi “yüksək birləşmə” haqqında ayrıca qeyd etmək lazımdır. Razıyam, ən yaxşı tərcümə deyil. Lakin “güclü əlaqə” “yüksək birləşmə”dir (başqa bir vacib anlayış) və “aidiyyət” burada çətin ki, uyğun olsun. Mən tənqidə açığam və məqaləyə istənilən formada olan şərhləri minnətdarlıqla qəbul edəcəyəm. Obyekt yönümlü proqramlaşdırma proqramın real dünya obyektlərinə uyğun gələn komponentlərdən ibarət olduğu proqramlaşdırma tərzidir.Hər hansı real obyektin bəzi xassələri (zaman keçdikcə dəyişə bilər və ya dəyişməyə bilər) və davranışı (bu, ola bilər və ya olmaya bilər) var. başqalarından asılı olaraq dəyişir).şərtlər). Məsələn, qələm aşağıdakı xüsusiyyətlərə malik real dünya obyektidir:
Qırmızıdır (bu zamanla dəyişmir).
İndi 10 santimetr uzunluqdadır (karandaş itiləndikdə bu dəyişə bilər).
Və aşağıdakı davranışa malikdir:
Düzgün istifadə edildikdə iz buraxır.
İz təzyiqdən (xarici amillərdən asılı olaraq) fərqlənə bilər.
Uzunluğu kəskinləşdikcə qısalır (daimi davranış).
Bu misalda olduğu kimi, real dünya obyektləri bir çox xassələrə malik ola bilər, lakin proqramlar yazarkən biz yalnız zəruri xüsusiyyətləri nəzərə alırıq. Obyekt yönümlü proqramlaşdırmanın öz üstünlükləri var. Məsələn, gözlənilən şəkildə real dünya obyekti ilə proqram arasında əlaqə qurmağı asanlaşdırır. Tətbiq böyüdükcə və bir çox obyekt bir-biri ilə qarşılıqlı əlaqədə olduqda bu, həqiqətən kömək edir. Bu, obyektiv dünya daxilində vəzifələrin bölüşdürülməsinə kömək edir və tətbiq vasitəsilə düşünməyə diqqət yetirməyə imkan verir. OOP (Object Oriented Programming) ilə əlaqəli digər vacib xüsusiyyət obyektlərin təsnifatıdır. Dünya (real/virtual) obyektlərlə dolu olduğundan, onları ayrı-ayrılıqda idarə etmək çətindir. Bu obyektləri təsnif etmək üçün bizə müxtəlif obyektləri və onların xassələrini, məsələn, qara qələmlə əlaqələndirməyə kömək edəcək bir üsul lazımdır. Əvvəlki misalda istifadə edilsəydi, fərqlənməz olardı (eyni?), lakin o, fərqli bir obyektdir. Amma hər ikisi karandaş olduğundan eyni “Qələm” sinfinə aiddir. Halbuki qələmə çox bənzəyən qələm başqa bir sinifə aiddir. Bununla belə, qələm və karandaş hər ikisi “Yazı alətləridir”. Obyekt yönümlü proqramlaşdırma aşağıdakı prinsiplərə malikdir:
Abstraksiya
Abstraksiya hadisələrdən daha çox fikirlərlə qarşılıqlı əlaqə keyfiyyəti və ya başqa sözlə, təmsilçilik keyfiyyətlərindən azad olmaq kimi müəyyən edilir . Bu, proqramçılara necə proqramlaşdırmaqdansa , nəyi proqramlaşdıracaqlarına diqqət yetirməyə imkan verir . Abstraksiya bizim funksionallığı təmin etdiyimiz müqavilə kimi düşünülə bilər. Bu konsepsiyadan istifadə edərkən icra detalları gizlənə bilər. Məsələn, bizə yazan sinif lazımdırsa, o zaman əmin olmalıyıq ki, onun “yazma” üsulu var.Biz nə etdik? Biz mücərrəd, başqa sözlə, bizə hansı funksionallıq lazım olduğunu bilən yüksək səviyyəli bir sinif hazırlamışıq, lakin onun necə həyata keçirilməsi bu sinfin əhatə dairəsinə daxil deyil. Bu, bir çox üstünlüklər təklif edir: abstract class writer { write (); }
Biz xarici qurumlar üçün lazım olan minimum məlumatları açıqlayırıq, bu, bizə proqram vasitəsilə düşünməyə diqqət yetirməyə imkan verir (bu, diqqətli düşünməyə imkan verir), çaşqınlığın qarşısını alır və gözlənilməz vədlər verməkdən çəkinir.
Tətbiq təfərrüatları aşkar olunarsa, mümkün olmayacaq gələcək təkmilləşdirmələr üçün yer buraxırıq.
Miras
Ümumi ingilis dilində "miras" "almaq və ötürmək" deməkdir. Bu söz bizim mədəniyyətimizdə çox uzun müddətdir mövcuddur. Əcdadlar zəhmət hesabına torpaq əldə edib, övladlarına ötürdülər, hətta təbiət mirasa üstünlük verir. Bütün bədən xüsusiyyətləri, məsələn, boy, dəri/göz/saç rəngi və s. valideynlərimizdən miras aldığımız genlərdən asılıdır. Miras təkəri yenidən kəşf etməyə imkan vermir və tərəqqini sürətləndirir. OOP-də də eynidir. Biz bir neçə əsas xassələri/davranışları olan ana sinif yaradırıq. Bu valideyndən miras qalan bütün siniflər onların valideyni ilə eyni xassələri/davranışları ehtiva edəcək. Bununla belə, irsi siniflər daha çox xassə/davranış əldə edə və ya davranışın həyata keçirilməsini dəyişə bilər. class WritingInstrument { colour; write() { } } class Pen (child of parent) { inkcolour; } Yuxarıdakı nümunədə ana sinif (WritingInstrument) “rəng” xüsusiyyətinə və “yazma” davranışına malikdir. Nəsil sinfi (qulp) elan edildikdə, "rəng" xassəsinin və "yazma" davranışının yenidən elan edilməsinə ehtiyac yoxdur. Onlar miraslığa görə "qulp" sinfində mövcuddurlar. Bununla belə, nəsil sinif öz əlavə xüsusiyyətlərini/davranışını elan edə bilər. Bunu praktikada necə istifadə edə bilərik? Biz tərtibatçılar çox tənbəl oluruq. Biz nəyisə təkrar-təkrar çap etmək istəmirik. Eyni kodun bir neçə nüsxəsinin mövcudluğu aşağıdakı mülahizələrə görə tövsiyə edilmir:
Kodun nüsxəsi nə qədər az olsa, onu saxlamaq bir o qədər asan olar.
Kodun çox nüsxəsi yoxdursa, bir yerdəki dəyişiklik hər yerdə görünür.
Nə qədər az kod olsa, bir o qədər az səhv olur.
Bir kod bir çox yerdə istifadə edilərsə, ümumiləşdirmə əldə edilir.
Kod yazmağa diqqət yetiririk.
Testlərə diqqət yetiririk.
Java-da vərəsəlik "uzatır" və "həyata keçirir" açar sözlərindən istifadə etməklə əldə edilir. class WritingInstrument { } class Pen extends WritingInstrument { }
Polimorfizm
"Polimorfizm" sözü iki sözdən ibarətdir: "Poly" , yəni. "çox" / "birdən çox" "morf" , yəni. “Forma” Hərfi mənada “polimorfizm” sözü obyektlərin şəraitdən asılı olaraq müxtəlif yollarla davranma qabiliyyətini ifadə edir. Proqramlaşdırmada polimorfizm bir neçə yerdə həyata keçirilə bilər:
Dərslər
Metodlar
Operatorlar
Yuxarıda göstərilənlərin hamısı şərtlərdən, bəlkə də istifadə olunduğu kontekstdən asılı olaraq fərqli davrana bilər. Bu faydalıdır, çünki müştəri (kitabxanalarınızdan istifadə edən proqramçı) çox incəlikləri bilməyə ehtiyac duymur və istədiyiniz funksionallıq kontekstdən lazımi məlumatları seçməklə həyata keçirilir. Class WritingObject { wrire() { // пишем, используя стандартные (по дефолту) цвета } } class Pencil extends WritingObject { write() { // пишем, используя серый цвет, написанный текст можно стереть } } class Pen extends WritingObject { write() { // пишем, используя голубой цвет, написанный текст нельзя стереть } } class Main { main() { WritingObject wr = new WritingObject(); wr.write(); // первый вызов WritingObject wr = new Pen(); wr.write(); // второй вызов WritingObject wr2 = new Pencil(); wr2.write(); // третий вызов } } Yuxarıdakı misalda WritingObject-də defolt tətbiq var, o, nəsil sinifləri qələm və qələm tərəfindən uzadılıb/əsl edilib. write() metodu Main sinfində üç dəfə çağırılır. Hər dəfə metodun hansı obyektə çağırıldığından asılı olaraq fərqli həyata keçirmə çağırılır. Bu halda write() metodu polimorfik olduğu üçün bir çox davranış növlərinə malikdir.
İnkapsulyasiya
İnkapsulyasiya əlaqəli məlumatların/funksionallığın bir vahiddə toplanması kimi müəyyən edilir. Bu, məlumatların əldə edilməsini/dəyişikliyini asanlaşdırmağa kömək edir. Məsələn, verilmiş istifadəçinin malik olduğu bütün xassələri çap etmək lazımdırsa, bizim aşağıdakı seçimlərimiz var: printUserProperties(userName, userId, firstname, lastname, email, phone, … … ….) Biz bütün xassələri götürən və bir-birinin ardınca çap edən metod yaratdıq. Siyahıdakı elementlərin sayı artdıqca düzgün sahələri müəyyən etmək artıq mümkün olmayacaq və bir sahənin əlavə edilməsi/çıxarılması metodun imzasını dəyişəcək. Buna görə də, yeni əlavə edilmiş sahələrə ehtiyacı olmasa belə, bu metodun bütün istifadəçilərini əvəz etməliyik. Kodu daha oxunaqlı etmək və gələcək modifikasiyaları asanlaşdırmaq üçün biz xassələri sinifə daxil edirik və onu kollektiv obyektə çeviririk.Obyekt class User { userName userId firstname lastname email phone .. .. .. } printUserProperties(user) {} dəyişənlərdən və əlaqəli metodlardan ibarət proqram paketidir. Proqram obyektlərindən istifadə edərək real dünya obyektlərini təmsil edə bilərsiniz. Siz animasiya proqramında real itləri və ya idman velosipedinin içərisində proqram obyekti kimi real velosipedi təsəvvür edə bilərsiniz. OOP-da sinif obyektləri yaratmaq, onları ilkin vəziyyətlə (dəyişənlər) təmin etmək və davranışı (funksiyalar, metodlar) həyata keçirmək üçün genişləndirilə bilən şablondur (proqram kodu-şablon). SOLID abbreviaturası 2000-ci illərin əvvəllərində Robert C. Martin tərəfindən adlandırılan “ilk beş prinsip” üçün Michael Feather tərəfindən yaradılmışdır. Prinsiplərin məqsədi birlikdə həyata keçirildikdə, proqramçının saxlanması və genişləndirilməsi asan olan bir sistem yaratması ehtimalını artırmaqdır. SOLID prinsipləri refaktorinq yolu ilə “çürük” kodu aradan qaldırmaq üçün zəruri olan proqramların hazırlanmasında təlimatlardır, nəticədə kod asanlıqla oxuna bilən və genişləndirilə bilən olmalıdır. Bu çevik və adaptiv proqramlaşdırma strategiyasının bir hissəsidir.
Vahid Məsuliyyət Prinsipi
OOP-da vahid məsuliyyət prinsipi bildirir ki, hər bir sinif proqram tərəfindən təmin edilən funksionallığın bir hissəsi üçün cavabdeh olmalıdır və bu məsuliyyət tamamilə həmin sinif tərəfindən əhatə olunmalıdır. Onun bütün funksionallığı bu məsuliyyətlə sıx bağlı olmalıdır.
Açıq/Qapalı Prinsip
OOP-da açıq/qapalı prinsip bildirir ki, “proqram təminatı obyektləri (siniflər, modullar, metodlar və s.) genişləndirilməyə açıq, lakin dəyişməyə qapalı olmalıdır”. Başqa sözlə, müəssisə mənbə kodunu dəyişmədən öz davranışının genişləndirilməsinə icazə verməlidir.
Liskov əvəzetmə prinsipi
Əvəzedicilik OOP-də bir prinsipdir. Burada deyilir ki, əgər kompüter proqramında S T-nin alt növüdürsə, onda T tipli obyektlər elə olmalıdır ki, onlar dəyişdirilmədən S tipli obyektlərlə (yəni S tipli obyektlər T tipli obyektlərlə əvəz edilə bilər) əvəz olunsun. hər hansı tələb olunan xüsusiyyətlər proqramları (dəqiqlik, tapşırıqların tamamlanması və s.).
İnterfeys Seqreqasiya Prinsipi
İnterfeyslərin ayrılması prinsipi bildirir ki, müştəri proqramçı onun istifadə etmədiyi metodlardan asılı olmağa məcbur edilməməlidir. Bu prinsipə əsasən, böyük interfeysləri daha kiçik və daha konkret olanlara bölmək lazımdır ki, müştəri proqramçı yalnız onun üçün maraqlı olan üsulları bilsin. İnterfeys decoupling prinsipinin məqsədi sistemin ayrılmasını təmin etməkdir ki, bu da refaktoru, dəyişiklikləri və yenidən yerləşdirməyi asanlaşdıracaq.
Asılılığın inversiya prinsipi
OOP-də asılılığın inversiya prinsipi proqram modulları arasında əlaqənin kəsilməsinin xüsusi forması deməkdir. Bu prinsipə əməl etməklə, tətbiq arxitekturasını (siyasət təyini) təşkil edən yüksək səviyyəli modullardan asılı aşağı səviyyəli modullara qədər qurulan standart asılılıq əlaqələri tərsinə çevrilir (əksinə çevrilir), beləliklə, dəyişdirilmiş yüksək səviyyəli modullar proqramın icra detallarından müstəqil olurlar. aşağı səviyyəli modullar. Bu prinsip deyir:
Yüksək səviyyəli modullar aşağı səviyyəli modullardan asılı olmamalıdır. Hər iki modul növü abstraksiyalardan asılı olmalıdır.
Abstraksiyalar icra detallarından asılı olmamalıdır. Təfərrüatlar abstraksiyalardan asılı olmalıdır.
Prinsip yüksək və aşağı səviyyəli obyektlərin eyni abstraksiyalardan asılı olması lazım olduğunu bildirərək insanların obyekt yönümlü dizayn haqqında düşünmə tərzini tərsinə çevirir.
GRASP prinsipləri
General Responsibility Assignment Software Patterns (GRASP) obyekt yönümlü dizaynda siniflərə və obyektlərə məsuliyyətlərin təyin edilməsi üçün təlimatlar təqdim edir.
Nəzarətçi
Nəzarətçi nümunəsi sistem hadisələri ilə qarşılıqlı əlaqə üçün məsuliyyəti bütün sistemi və ya istifadə ssenarisini təmsil edən QUI olmayan siniflərə təyin edir. Nəzarətçi:
Bu, istifadəçi ilə birbaşa qarşılıqlı əlaqədə olmayan və sistem hadisələrini qəbul etmək və onlara cavab vermək üçün cavabdeh olan bir obyektdir.
Bir (və ya bir-biri ilə əlaqəli bir çox) istifadə hallarının bütün sistem hadisələri ilə məşğul olmaq üçün istifadə edilməlidir.
Sistem əməliyyatlarına nəzarət edən GUI-nin arxasında duran ilk obyektdir.
İşi özü görməli deyil, onun vəzifəsi hadisələrin gedişatına nəzarət etməkdir.
Yaradan
Yaradıcı sinifin vəzifəsi sonradan istifadə üçün obyektlər yaratmaq və işə salmaqdır. O, başlanğıc parametrlərini, eləcə də hansı obyektin yaradılacağını bilir. Bəzən yaradıcı sinfi aktiv şəkildə obyektlər yaradır və onları keşdə yerləşdirir və lazım olduqda bir nümunə təqdim edir.
Yüksək Koheziya
Yüksək birləşmə qiymətləndirmə nümunəsidir, məqsədi obyektləri bir aydın tapşırığı yerinə yetirməyə yönəlmiş, asanlıqla idarə olunan və başa düşülən vəziyyətdə saxlamaqdır. Yüksək Mufta adətən Aşağı Birləşməni dəstəkləmək üçün istifadə olunur. Yüksək ahəngdarlıq o deməkdir ki, verilmiş elementin məsuliyyətləri aydın şəkildə müəyyən edilmişdir (güclü əlaqəli və yüksək diqqət mərkəzindədir). Proqramın siniflərə və alt sistemlərə bölünməsi sistem xassələrinin birləşməsini artıran hərəkətlərə misaldır. Boş birləşmə, digər tərəfdən, bir elementin çox əlaqəli olmayan vəzifələrin olduğu bir vəziyyətdir. Boş birləşmiş elementləri başa düşmək, təkrar istifadə etmək, saxlamaq çətin və dəyişdirmək çətindir.
dolayı
Dairəvi yol nümunəsi iki element arasında qarşılıqlı əlaqə üçün məsuliyyəti ara obyektə həvalə etməklə, boş birləşməni (və təkrar istifadəni) saxlayır. Nümunə, Model-Görünüş-Nəzarətçi (MVC) modelində verilənlər (model) və onun göstərilməsi (görünüşü) arasında vasitəçilik etmək üçün nəzarətçinin tətbiqi ola bilər.
İnformasiya Mütəxəssisi
İnformasiya Mütəxəssisi (həmçinin Ekspert və ya Ekspert Prinsipi) məsuliyyətin kimə həvalə ediləcəyini müəyyən etmək üçün istifadə edilən prinsipdir. Məsuliyyətlərə metodlar, hesablanmış sahələr və s. Məsuliyyət təyin edərkən bu prinsipdən istifadə edərkən əsas yanaşma aşağıdakı hərəkət ardıcıllığıdır: məsuliyyətin təhlili, onun yerinə yetirilməsi üçün lazım olan məlumatları müəyyən etmək və nəhayət, bu məlumatın harada yerləşdiyini müəyyən etmək. İnformasiya Mütəxəssisi prinsipindən istifadə, onu yerinə yetirmək üçün ən çox məlumata malik olan sinfə məsuliyyətin verilməsi ilə nəticələnir.
Aşağı birləşmə
Boş birləşmə, məsuliyyətlərin necə təyin ediləcəyini müəyyən edən qiymətləndirmə nümunəsidir: siniflər arasında boş birləşmə, birinin dəyişdirilməsi digərinə minimal təsir göstərməli, təkrar istifadəni maksimum dərəcədə artırmalıdır.
Polimorfizm
Polimorfizmə görə, tipə görə davranış dəyişikliyi bu dəyişkənliyin baş verdiyi növlərə təyin olunur. Bu, polimorfik əməliyyatlardan istifadə etməklə əldə edilir.
Qorunan Variasiyalar
Qorunan Dəyişikliklər nümunəsi qeyri-sabitlik fokusunu interfeysə bükməklə və həmin interfeysin müxtəlif tətbiqlərini yaratmaq üçün polimorfizmdən istifadə etməklə elementləri digər elementlərə (obyektlərə, sistemlərə, alt sistemlərə) edilən dəyişikliklərdən qoruyur.
Təmiz İstehsalat
Təmiz konstruksiya problem sahəsində konsepsiyanı təmsil etməyən sinifi əhatə edir və xüsusi olaraq boş birləşmə, yüksək birləşmə və buna görə də maksimum təkrar istifadə potensialına nail olmaq üçün nəzərdə tutulmuşdur (Məlumat Eksperti nümunəsi tərəfindən təklif olunan həll buna nail olmur). Domen idarə edən dizaynda belə bir sinif adətən “Xidmət” adlanır.
Tənqid
Potok və başqaları tərəfindən aparılan tədqiqatlar OOP və prosedur yanaşmaları arasında əhəmiyyətli fərqlər göstərməmişdir.
OOP-nin digər texnologiyalarla, xüsusən də əlaqə texnologiyaları ilə kritik müqayisəsi, ciddi və geniş şəkildə qəbul edilən OOP tərifinin olmaması səbəbindən çətindir (Christopher J. Date)
Digər dillərlə müqayisədə (LISP dialektləri, funksional dillər və s.) OOP dillərinin unikal üstünlüyü yoxdur və lazımsız mürəkkəblik tətbiq edir. (Lorens Krubner)
Mən obyekt yönümlü proqramlaşdırmanı texniki cəhətdən zəif hesab edirəm. O, dünyanı tək tip daxilində dəyişən interfeyslər baxımından hissələrə ayırmağa çalışır. Həqiqi problemləri həll etmək üçün çox çeşidli cəbrlərə ehtiyacınız var - bir çox növə yayılan interfeys ailələri. Mən obyekt yönümlü proqramlaşdırmanı fəlsəfi cəhətdən qeyri-sağlam hesab edirəm. Hər şeyin bir obyekt olduğunu bildirir. Bu doğru olsa belə, o qədər də maraqlı deyil: hər şeyin obyekt olduğunu söyləmək, ümumiyyətlə, heç nə deməmək deməkdir. (Aleksandr Stepanov)
OOP-nin böyük şirkətlər arasında populyarlığı “böyük (və tez-tez dəyişən) orta səviyyəli proqramçılar qrupları” ilə bağlıdır. OOP tərəfindən qoyulan nizam-intizam proqramçıya "çox zərər vurmaqdan" mane olur. (Paul Graham)
Obyekt yönümlü proqramlaşdırma ilk növbədə isimləri qoyur. Niyə belə ifrat tədbirlərə gedib nitqin bir hissəsini postamentə salmaq lazımdır? Niyə bir anlayış digərindən üstündür? OOP-un birdən-birə felləri düşüncəmiz üçün əhəmiyyətini azaltması mümkün deyil. Bu, qəribə dərəcədə əyri bir perspektivdir. (Stiv Yegge)
Clojure-un yaradıcısı Rick Hickey obyekt sistemlərini real dünyanın son dərəcə sadələşdirilmiş modelləri kimi təsvir etmişdir. O, OOP-nin vaxtı düzgün modelləşdirməyə qadir olmadığını vurğuladı, bu da proqramlarda çoxilli işlərin adi hala çevrildiyi zaman böyük problemlər yaradır. Unix proqramçısı və açıq mənbə proqram təminatı müdafiəçisi Eric S. Raymond, OOP-nin "Bir Həll" olması iddiasını tənqid etdi və OOP-nin şəffaflığa mane olan çoxqatlı proqramları təşviq etdiyini yazdı. Əks yanaşma olaraq, Raymond Unix və C nümunəsini verdi.
GO TO FULL VERSION