Kod yazma qaydaları: sistem yaratmaqdan tutmuş obyektlərlə işləməyə qədər

Hər kəsə günortanız xeyir: bu gün sizinlə kodun düzgün yazılması haqqında danışmaq istərdim. Mən proqramlaşdırmaya ilk başlayanda heç bir yerdə aydın yazılmamışdı ki, belə yaza bilərsən, belə yazsan, səni taparam və.... Nəticədə beynimdə çoxlu suallar yarandı: necə düzgün yazmalı, verilişin bu və ya digər bölməsində hansı prinsiplərə əməl edilməlidir və s. Yaxşı, hamı dərhal Təmiz Kod kimi kitablara dalmaq istəmir, çünki onlarda çox şey yazılıb, amma əvvəlcə az şey aydındır. Oxumağı bitirəndə isə bütün kodlaşdırma istəyini dayandıra bilərsiniz. Beləliklə, yuxarıda göstərilənlərə əsaslanaraq, bu gün sizə daha yüksək səviyyəli kod yazmaq üçün kiçik bir bələdçi (kiçik tövsiyələr toplusu) təqdim etmək istəyirəm. Bu yazıda biz sistem yaratmaq və interfeyslər, siniflər və obyektlərlə işləmək ilə bağlı əsas qayda və anlayışları nəzərdən keçirəcəyik. Bu materialı oxumaq sizə çox vaxt aparmayacaq və ümid edirəm ki, darıxmağınıza imkan verməyəcəksiniz. Mən yuxarıdan aşağıya, yəni tətbiqin ümumi strukturundan daha konkret detallara keçəcəyəm.

Sistem

Sistemin ümumi arzu olunan xüsusiyyətləri bunlardır:

• minimal mürəkkəblik - həddindən artıq mürəkkəb layihələrdən qaçınmaq lazımdır. Əsas odur ki, sadəlik və aydınlıqdır (ən yaxşı = sadə);
• baxım asanlığı - bir proqram yaratarkən, onun dəstəklənməsinə ehtiyac olduğunu xatırlamalısınız (siz olmasa belə), kod aydın və aydın olmalıdır;
• zəif birləşmə proqramın müxtəlif hissələri arasında minimum əlaqə sayıdır (OOP prinsiplərindən maksimum istifadə);
• təkrar istifadəyə yararlılıq - onun fraqmentlərindən başqa proqramlarda təkrar istifadə etmək imkanı olan sistemin layihələndirilməsi;
• daşınma qabiliyyəti - sistem asanlıqla başqa mühitə uyğunlaşdırılmalıdır;
• vahid üslub - sistemin müxtəlif fraqmentlərində vahid üslubda layihələndirilməsi;
• genişlənmə (miqyaslılıq) - sistemin əsas strukturunu pozmadan təkmilləşdirmək (bir fraqment əlavə etsəniz və ya dəyişdirsəniz, bu, qalan hissələrə təsir etməməlidir).

Dəyişikliklər tələb etməyən bir proqram yaratmaq, funksionallıq əlavə etmədən, demək olar ki, mümkün deyil. Beyin balamızın zamanla ayaqlaşa bilməsi üçün daim yeni elementlər təqdim etməli olacağıq. Ölçeklenebilirlik oyuna girdiyi yerdir . Ölçeklenebilirlik mahiyyətcə tətbiqi genişləndirir, yeni funksionallıq əlavə edir, daha çox resursla (və ya başqa sözlə, daha çox yüklə) işləyir. Yəni, modulluğu artırmaqla sistemin birləşməsini azaltmaq kimi bəzi qaydalara əməl etməliyik ki, yeni məntiq əlavə etmək daha asan olsun.

Sistemin dizayn mərhələləri

1. Proqram təminatı sistemi - proqramın ümumi formada layihələndirilməsi.
2. Alt sistemlərə/paketlərə ayırma - məntiqi olaraq ayrıla bilən hissələrin müəyyən edilməsi və onlar arasında qarşılıqlı əlaqə qaydalarının müəyyən edilməsi.
3. Alt sistemlərin siniflərə bölünməsi - sistemin hissələrinin xüsusi siniflərə və interfeyslərə bölünməsi, habelə onlar arasında qarşılıqlı əlaqənin müəyyən edilməsi.
4. Siniflərin metodlara bölünməsi bu sinfin tapşırığına əsaslanaraq sinif üçün lazım olan metodların tam tərifidir. Metod dizaynı - fərdi metodların funksionallığının ətraflı tərifi.

Tipik olaraq, adi tərtibatçılar dizayna cavabdehdirlər və tətbiqin memarı yuxarıda təsvir olunan maddələrə cavabdehdir.

Sistemin dizaynının əsas prinsipləri və konsepsiyaları

Tənbəl başlatma idiomu Tətbiq istifadə olunana qədər obyekt yaratmağa vaxt sərf etmir, bu da işəsalma prosesini sürətləndirir və zibil yığan yükü azaldır. Ancaq bununla çox uzağa getməməlisiniz, çünki bu, modulluğun pozulmasına səbəb ola bilər. Bütün dizayn addımlarını müəyyən bir hissəyə, məsələn, əsas və ya fabrik kimi işləyən sinifə köçürməyə dəyər ola bilər . Yaxşı kodun aspektlərindən biri də tez-tez təkrarlanan kodun olmamasıdır. Bir qayda olaraq, belə kod ayrı bir sinifə yerləşdirilir ki, lazımi anda çağırıla bilsin. AOP ayrıca aspekt yönümlü proqramlaşdırmanı qeyd etmək istərdim . Bu, uç-to-end məntiqi tətbiq etməklə proqramlaşdırmadır, yəni təkrarlanan kod siniflərə - aspektlərə qoyulur və müəyyən şərtlərə çatdıqda çağırılır. Məsələn, müəyyən bir adla metoda daxil olduqda və ya müəyyən tipli dəyişənə daxil olduqda. Bəzən aspektlər çaşdırıcı ola bilər, çünki kodun haradan çağırıldığı dərhal aydın deyil, lakin buna baxmayaraq, bu çox faydalı bir funksionallıqdır. Xüsusilə, keşləmə və ya giriş zamanı: biz bu funksionallığı adi siniflərə əlavə məntiq əlavə etmədən əlavə edirik. OAP haqqında daha ətraflı burada oxuya bilərsiniz . Kent Bekə görə sadə memarlığın layihələndirilməsi üçün 4 qayda

1. Ekspressivlik - sinfin aydın ifadə edilmiş məqsədinə ehtiyac, düzgün adlandırma, kiçik ölçü və vahid məsuliyyət prinsipinə riayət etməklə əldə edilir (bunu aşağıda daha ətraflı nəzərdən keçirəcəyik).
2. Minimum siniflər və üsullar - sinifləri mümkün qədər kiçik və bir istiqamətli bölməyə bölmək istəyinizlə, çox uzağa gedə bilərsiniz (antipattern - ov tüfəngi). Bu prinsip sistemi yığcam saxlamağı və çox uzağa getməməyi, hər asqırma üçün sinif yaratmağı tələb edir.
3. Təkrarlanmanın olmaması - çaşdıran əlavə kod sistemin zəif dizaynının əlamətidir və ayrı yerə köçürülür.
4. Bütün testlərin icrası - bütün sınaqlardan keçmiş sistemə nəzarət edilir, çünki hər hansı bir dəyişiklik testlərin uğursuz olmasına səbəb ola bilər ki, bu da bizə metodun daxili məntiqindəki dəyişikliyin həm də gözlənilən davranışın dəyişməsinə səbəb olduğunu göstərə bilər.

SOLID Sistemi layihələndirərkən SOLID-in məlum prinsiplərini nəzərə almağa dəyər: S - vahid məsuliyyət - vahid məsuliyyət prinsipi; O - açıq-qapalı - açıqlıq/yaxınlıq prinsipi; L - Liskovun əvəzlənməsi - Barbara Liskovun əvəzetmə prinsipi; I - interfeysin ayrılması - interfeysin ayrılması prinsipi; D - asılılıq inversiyası - asılılığın inversiya prinsipi; Hər bir prinsip üzərində xüsusi olaraq dayanmayacağıq (bu, bu məqalənin əhatə dairəsindən bir qədər kənardadır, lakin burada daha çox məlumat əldə edə bilərsiniz.

İnterfeys

Bəlkə də adekvat sinif yaratmağın ən vacib mərhələlərindən biri, sinfin həyata keçirilməsinin təfərrüatlarını gizlədən yaxşı bir abstraksiyanı təmsil edəcək və eyni zamanda bir-biri ilə aydın şəkildə uyğun gələn metodlar qrupunu təmsil edəcək adekvat interfeys yaratmaqdır. . SOLID prinsiplərindən birinə daha yaxından nəzər salaq - interfeys seqreqasiyası : müştərilər (siniflər) istifadə etməyəcəkləri lazımsız metodları tətbiq etməməlidirlər. Yəni, bu interfeysin yeganə tapşırığını yerinə yetirməyə yönəlmiş minimum sayda üsulla interfeys qurmaqdan danışırıqsa (mənim üçün bu, tək məsuliyyətə çox bənzəyir ), bir neçə kiçik yaratmaq daha yaxşıdır. bir şişirilmiş interfeys əvəzinə olanları. Xoşbəxtlikdən, bir sinif irsiyyətdə olduğu kimi birdən çox interfeys həyata keçirə bilər. İnterfeyslərin düzgün adlandırılmasını da xatırlamaq lazımdır: ad öz vəzifəsini mümkün qədər dəqiq əks etdirməlidir. Və təbii ki, nə qədər qısa olsa, bir o qədər az qarışıqlığa səbəb olacaq. Sənədləşdirmə üçün şərhlər adətən interfeys səviyyəsində yazılır , bu da öz növbəsində metodun nə etməli olduğunu, hansı arqumentləri tələb etdiyini və nəyin qaytaracağını ətraflı təsvir etməyə kömək edir.

Sinif

Dərslərin daxili təşkilinə baxaq. Daha doğrusu, siniflər qurarkən əməl edilməli olan bəzi baxışlar və qaydalar. Tipik olaraq, sinif müəyyən bir ardıcıllıqla düzülmüş dəyişənlərin siyahısı ilə başlamalıdır:

1. ictimai statik sabitlər;
2. özəl statik sabitlər;
3. özəl instansiya dəyişənləri.

Daha sonra azdan daha çox arqumentə doğru sıra ilə müxtəlif konstruktorlar var. Onların ardınca daha açıq girişdən ən qapalı olanlara qədər üsullar gəlir: bir qayda olaraq, məhdudlaşdırmaq istədiyimiz bəzi funksionallığın həyata keçirilməsini gizlədən özəl üsullar ən aşağı yerdədir.

Sinif ölçüsü

İndi sinif ölçüsü haqqında danışmaq istərdim. SOLID - tək məsuliyyət prinsiplərindən birini xatırlayaq . Vahid məsuliyyət - vahid məsuliyyət prinsipi. Burada bildirilir ki, hər bir obyektin yalnız bir məqsədi (məsuliyyəti) var və onun bütün üsullarının məntiqi onu təmin etməyə yönəlib. Yəni, buna əsaslanaraq, böyük, qabarıq siniflərdən (təbiətinə görə antipatterndir - “ilahi obyektdir”) qaçmalıyıq və əgər sinifdə çoxlu müxtəlif, heterojen məntiq metodlarımız varsa, düşünməliyik. onu bir neçə məntiqi hissəyə (siniflərə) bölmək haqqında. Bu, öz növbəsində, kodun oxunuşunu yaxşılaşdıracaq, çünki müəyyən bir sinfin təxmini məqsədini bilsək, metodun məqsədini başa düşmək üçün çox vaxt lazım deyil. Siz həmçinin sinif adına diqqət yetirməlisiniz : o, tərkibindəki məntiqi əks etdirməlidir. Deyək ki, adı 20+ sözdən ibarət bir sinifimiz varsa, refaktorinq haqqında düşünməliyik. Özünə hörmət edən hər bir sinifdə bu qədər çox daxili dəyişənlər olmamalıdır. Əslində, hər bir metod onlardan biri və ya bir neçəsi ilə işləyir, bu da sinif daxilində daha çox birləşməyə səbəb olur (bu, tam olaraq belə olmalıdır, çünki sinif vahid bütöv olmalıdır). Nəticə etibarı ilə bir sinfin ahəngdarlığının artması onun belə azalmasına gətirib çıxarır və təbii ki, siniflərimizin sayı artır. Bəziləri üçün bu bezdiricidir; onlar müəyyən bir böyük tapşırığın necə işlədiyini görmək üçün daha çox sinifə getməlidirlər. Digər şeylər arasında, hər bir sinif digərləri ilə minimal şəkildə əlaqəli olan kiçik bir moduldur. Bu izolyasiya sinifə əlavə məntiq əlavə edərkən etməli olduğumuz dəyişikliklərin sayını azaldır.

Obyektlər

İnkapsulyasiya

Burada ilk növbədə OOP- inkapsulyasiya prinsiplərindən biri haqqında danışacağıq . Beləliklə, həyata keçirilməsini gizlətmək dəyişənlər arasında metod təbəqəsi yaratmağa gəlmir (tək metodlar, alıcılar və tənzimləyicilər vasitəsilə girişi düşünmədən məhdudlaşdırmaq, yaxşı deyil, çünki bütün inkapsulyasiya nöqtəsi itirilir). Girişin gizlədilməsi abstraksiyaların formalaşmasına yönəlib, yəni sinif məlumatlarımızla işlədiyimiz ümumi konkret metodları təqdim edir. Ancaq istifadəçinin bu məlumatla necə işlədiyimizi dəqiq bilməsi lazım deyil - bu işləyir və yaxşıdır.

Demeter qanunu

Siz həmçinin Demeter Qanununu nəzərdən keçirə bilərsiniz: bu, sinif və metod səviyyəsində mürəkkəbliyi idarə etməyə kömək edən kiçik qaydalar toplusudur. Beləliklə, fərz edək ki, bizim obyektimiz var Carvə onun metodu var - move(Object arg1, Object arg2). Demeter Qanununa görə, bu üsul çağırışla məhdudlaşır:

• obyektin özünün üsulları Car(başqa sözlə, bu);
• -də yaradılmış obyektlərin üsulları move;
• arqument kimi ötürülən obyektlərin üsulları - arg1, arg2;
• daxili obyektlərin metodları Car(eyni bu).

Başqa sözlə, Demeter qanunu uşaq qaydası kimi bir şeydir - dostlarla danışa bilərsiniz, ancaq yadlarla deyil .

Məlumat strukturu

Məlumat strukturu əlaqəli elementlərin toplusudur. Bir obyekti məlumat strukturu kimi nəzərdən keçirərkən, mövcudluğu dolayısı ilə ifadə olunan metodlarla işlənən məlumat elementləri toplusudur. Yəni, məqsədi saxlanılan məlumatları saxlamaq və işləmək (emal etmək) olan bir obyektdir. Adi obyektdən əsas fərq ondan ibarətdir ki, obyekt mövcudluğu nəzərdə tutulan məlumat elementləri üzərində işləyən metodlar toplusudur. Başa düşürsən? Adi bir obyektdə əsas aspekt üsullardır və daxili dəyişənlər onların düzgün işləməsinə yönəldilmişdir, lakin məlumat strukturunda bunun əksinədir: üsullar burada əsas olan saxlanılan elementlərlə işləməyi dəstəkləyir və kömək edir. Məlumat strukturunun bir növü Data Transfer Object (DTO) . Bu, ümumi dəyişənlərə malik sinifdir və verilənlər bazası ilə işləyərkən məlumatları ötürən, rozetkalardan mesajların təhlili ilə işləyən və s. metodları olmayan (yaxud yalnız oxumaq/yazma metodları) var. Tipik olaraq, belə obyektlərdə verilənlər uzun müddət saxlanılmır və demək olar ki, dərhal tətbiqimizin işlədiyi obyektə çevrilir. Müəssisə, öz növbəsində, həm də məlumat strukturudur, lakin onun məqsədi tətbiqin müxtəlif səviyyələrində biznes məntiqində iştirak etməkdir, DTO isə məlumatı proqrama/tətbiqdən nəql etməkdir. DTO nümunəsi:

@Setter
@Getter
@NoArgsConstructor
public class UserDto {
    private long id;
    private String firstName;
    private String lastName;
    private String email;
    private String password;
}

Hər şey aydın görünür, amma burada hibridlərin mövcudluğu haqqında öyrənirik. Hibridlər mühüm məntiqi idarə etmək və daxili elementləri və onlara daxil olmaq üsullarını (almaq/quraşdırmaq) saxlamaq üçün üsulları ehtiva edən obyektlərdir. Belə obyektlər dağınıqdır və yeni metodların əlavə edilməsini çətinləşdirir. Onları istifadə etməməlisiniz, çünki onların nə üçün nəzərdə tutulduğu aydın deyil - elementləri saxlamaq və ya bir növ məntiq yerinə yetirmək. Siz burada mümkün obyekt növləri haqqında oxuya bilərsiniz .

Dəyişənlərin yaradılması prinsipləri

Dəyişənlər haqqında bir az düşünək, daha doğrusu, onların yaradılması prinsiplərinin nə ola biləcəyini düşünək:

1. İdeal olaraq, siz dəyişəni istifadə etməzdən əvvəl dərhal elan etməli və işə salmalısınız (onu yaratmaq və unutmaq əvəzinə).
2. Mümkün olduqda, başlanğıcdan sonra dəyərinin dəyişməsinin qarşısını almaq üçün dəyişənləri yekun elan edin.
3. Sayğac dəyişənləri haqqında unutmayın (adətən biz onları bir növ döngədə istifadə edirik for, yəni onları sıfırlamağı unutmamalıyıq, əks halda bütün məntiqimizi poza bilər).
4. Siz konstruktorda dəyişənləri işə salmağa çalışmalısınız.
5. Obyektin istinadlı və ya istinadsız istifadəsi arasında seçim varsa ( new SomeObject()), olmadan ( ) seçin, çünki bir dəfə istifadə edilən bu obyekt növbəti zibil yığımı zamanı silinəcək və resursları israf etməyəcək.
6. Dəyişənlərin ömrünü mümkün qədər qısa edin (bir dəyişənin yaradılması ilə son giriş arasındakı məsafə).
7. Döngədə istifadə olunan dəyişənləri dövrəni ehtiva edən metodun əvvəlində deyil, dərhal döngədən əvvəl işə salın.
8. Həmişə ən məhdud əhatə dairəsi ilə başlayın və yalnız zəruri hallarda onu genişləndirin (dəyişəni mümkün qədər yerli etməyə çalışmalısınız).
9. Hər dəyişəni yalnız bir məqsəd üçün istifadə edin.
10. Gizli mənaları olan dəyişənlərdən çəkinin (dəyişən iki tapşırıq arasında parçalanıb, yəni onun növü onlardan birinin həlli üçün uyğun deyil).

Metodlar

Gəlin birbaşa məntiqimizin həyata keçirilməsinə, yəni üsullara keçək.

1. Birinci qayda kompaktlıqdır. İdeal olaraq, bir üsul 20 sətirdən çox olmamalıdır, buna görə də, məsələn, ictimai bir üsul əhəmiyyətli dərəcədə "şişirsə", ayrılmış məntiqi özəl metodlara köçürmək barədə düşünməlisiniz.

2. ifİkinci qayda odur ki , else, və s. komandalardakı bloklar whileyüksək səviyyədə yerləşdirilməməlidir: bu, kodun oxunuşunu əhəmiyyətli dərəcədə azaldır. İdeal olaraq, yuva iki blokdan çox olmamalıdır {}.

   Bu bloklardakı kodu yığcam və sadə etmək də məqsədəuyğundur.

3. Üçüncü qayda odur ki, metod yalnız bir əməliyyat yerinə yetirməlidir. Yəni bir üsul mürəkkəb, müxtəlif məntiqi yerinə yetirirsə, onu alt metodlara bölürük. Nəticədə, metodun özü bir fasad olacaq, məqsədi bütün digər əməliyyatları düzgün qaydada çağırmaqdır.

   Bəs əməliyyat ayrı bir üsul yaratmaq üçün çox sadə görünürsə? Bəli, bəzən topdan sərçə atmaq kimi görünə bilər, lakin kiçik üsullar bir sıra faydalar təmin edir:

   • daha asan kodu oxumaq;
   • üsullar inkişaf zamanı daha mürəkkəb olur və əgər metod əvvəlcə sadə idisə, onun funksionallığını çətinləşdirmək bir az daha asan olacaq;
   • icra detallarını gizlətmək;
   • kodun təkrar istifadəsini asanlaşdırmaq;
   • daha yüksək kod etibarlılığı.

4. Aşağıya doğru qayda budur ki, kodu yuxarıdan aşağı oxumaq lazımdır: nə qədər aşağı olarsa, məntiqin dərinliyi nə qədər böyük olarsa və əksinə, daha yüksək olarsa, metodlar bir o qədər abstraktdır. Məsələn, keçid əmrləri olduqca yığcam və arzuolunmazdır, lakin keçiddən istifadə etmədən edə bilmirsinizsə, onu mümkün qədər aşağı səviyyəyə, ən aşağı səviyyəli üsullara köçürməyə çalışmalısınız.

5. Metod arqumentləri - neçəsi idealdır? İdeal olaraq, heç biri yoxdur)) Amma bu, həqiqətən baş verir? Bununla belə, onların mümkün qədər az olmasına çalışmalısınız, çünki onların sayı nə qədər azdırsa, bu metoddan istifadə etmək bir o qədər asandır və onu sınaqdan keçirmək bir o qədər asandır. Əgər şübhəniz varsa, çox sayda giriş arqumenti olan bir metoddan istifadə üçün bütün ssenariləri təxmin etməyə çalışın.

6. Ayrı-ayrılıqda mən bir giriş arqumenti kimi boolean bayrağı olan metodları vurğulamaq istərdim , çünki bu, təbii olaraq bu metodun birdən çox əməliyyat həyata keçirməsini nəzərdə tutur (əgər doğrudursa, biri yanlışdır - başqa). Yuxarıda yazdığım kimi, bu yaxşı deyil və mümkünsə ondan çəkinmək lazımdır.

7. Metodun çoxlu sayda daxil olan arqumentləri varsa (ekstremal dəyər 7-dir, lakin bu barədə 2-3-dən sonra düşünmək lazımdır), bəzi arqumentləri ayrıca obyektdə qruplaşdırmaq lazımdır.

8. Bir neçə oxşar üsul varsa (həddən artıq yüklənmiş) , onda oxşar parametrlər eyni ardıcıllıqla ötürülməlidir: bu, oxunaqlılığı və istifadəni artırır.

9. Parametrləri metoda ötürəndə onların hamısının istifadə olunacağına əmin olmalısınız, əks halda arqument nə üçündür? Onu interfeysdən kəsin və budur.

10. try/catchTəbiətinə görə çox gözəl görünmür, buna görə də onu aralıq ayrı bir üsula (istisnaların idarə edilməsi üsulu) köçürmək yaxşı bir addım olardı:

    public void exceptionHandling(SomeObject obj) {
        try {
            someMethod(obj);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

Yuxarıda kodun təkrarlanması haqqında danışdım, lakin onu bura əlavə edəcəyəm: Əgər kodun hissələrini təkrarlayan bir neçə üsulumuz varsa, onu ayrıca metoda köçürməliyik ki, bu da həm metodun, həm də metodun kompaktlığını artıracaq. sinif. Və düzgün adlar haqqında unutmayın. Məqalənin növbəti hissəsində siniflərin, interfeyslərin, metodların və dəyişənlərin düzgün adlandırılmasının təfərrüatlarını sizə izah edəcəyəm. Və bu gün üçün sahib olduğum hər şey budur. Kod qaydaları: düzgün adlandırmanın gücü, yaxşı və pis şərhlər