Peraturan untuk menulis kod: daripada mencipta sistem kepada bekerja dengan objek

Selamat tengah hari semua: hari ini saya ingin bercakap dengan anda tentang menulis kod dengan betul. Apabila saya mula-mula memulakan pengaturcaraan, ia tidak ditulis dengan jelas di mana-mana yang anda boleh menulis seperti ini, dan jika anda menulis seperti ini, saya akan mencari anda dan…. Akibatnya, saya mempunyai banyak soalan di kepala saya: bagaimana untuk menulis dengan betul, prinsip apa yang harus diikuti dalam bahagian program ini atau itu, dll. Nah, tidak semua orang mahu segera menyelami buku seperti Kod Bersih, kerana banyak yang tertulis di dalamnya, tetapi pada mulanya sedikit jelas. Dan apabila anda selesai membaca, anda boleh menghalang semua keinginan untuk kod. Jadi berdasarkan perkara di atas, hari ini saya ingin memberikan anda panduan kecil (satu set cadangan kecil) untuk menulis kod peringkat lebih tinggi. Dalam artikel ini kita akan membincangkan peraturan dan konsep asas yang berkaitan dengan mencipta sistem dan bekerja dengan antara muka, kelas dan objek. Membaca bahan ini tidak akan membawa anda banyak masa dan, saya harap, tidak akan membiarkan anda bosan. Saya akan pergi dari atas ke bawah, iaitu, dari struktur umum aplikasi kepada butiran yang lebih khusus.

Sistem

Ciri-ciri umum sistem yang dikehendaki ialah:

• kerumitan minimum - projek yang terlalu rumit harus dielakkan. Perkara utama ialah kesederhanaan dan kejelasan (terbaik = mudah);
• kemudahan penyelenggaraan - apabila membuat aplikasi, anda mesti ingat bahawa ia perlu disokong (walaupun bukan anda), jadi kod itu harus jelas dan jelas;
• gandingan lemah ialah bilangan sambungan minimum antara bahagian program yang berlainan (penggunaan maksimum prinsip OOP);
• kebolehgunaan semula - mereka bentuk sistem dengan keupayaan untuk menggunakan semula serpihannya dalam aplikasi lain;
• mudah alih - sistem mesti mudah disesuaikan dengan persekitaran lain;
• gaya tunggal - mereka bentuk sistem dalam gaya tunggal dalam serpihan yang berbeza;
• kebolehlanjutan (skalabiliti) - menambah baik sistem tanpa mengganggu struktur asasnya (jika anda menambah atau menukar serpihan, ini tidak sepatutnya menjejaskan yang lain).

Hampir mustahil untuk membina aplikasi yang tidak memerlukan pengubahsuaian, tanpa menambah fungsi. Kami sentiasa perlu memperkenalkan unsur-unsur baru supaya anak buah fikiran kami dapat mengikuti perkembangan zaman. Dan di sinilah skalabiliti memainkan peranan . Kebolehskalaan pada asasnya adalah mengembangkan aplikasi, menambah fungsi baharu, bekerja dengan lebih banyak sumber (atau, dengan kata lain, dengan lebih banyak beban). Iaitu, kita mesti mematuhi beberapa peraturan, seperti mengurangkan gandingan sistem dengan meningkatkan modulariti, supaya lebih mudah untuk menambah logik baru.

Peringkat reka bentuk sistem

1. Sistem perisian - mereka bentuk aplikasi dalam bentuk umum.
2. Pemisahan kepada subsistem/pakej - mentakrifkan bahagian yang boleh dipisahkan secara logik dan mentakrifkan peraturan interaksi antara mereka.
3. Membahagikan subsistem kepada kelas - membahagikan bahagian sistem kepada kelas dan antara muka tertentu, serta mentakrifkan interaksi antara mereka.
4. Membahagikan kelas kepada kaedah ialah definisi lengkap kaedah yang diperlukan untuk kelas, berdasarkan tugas kelas ini. Reka bentuk kaedah - definisi terperinci tentang fungsi kaedah individu.

Biasanya, pembangun biasa bertanggungjawab untuk reka bentuk, dan arkitek aplikasi bertanggungjawab untuk item yang diterangkan di atas.

Prinsip dan konsep utama reka bentuk sistem

Idiom pemula malas Aplikasi tidak menghabiskan masa mencipta objek sehingga ia digunakan, yang mempercepatkan proses pemula dan mengurangkan beban pemungut sampah. Tetapi anda tidak sepatutnya pergi terlalu jauh dengan ini, kerana ini boleh menyebabkan pelanggaran modulariti. Ia mungkin berbaloi untuk mengalihkan semua langkah reka bentuk ke bahagian tertentu, contohnya, utama atau ke kelas yang berfungsi seperti kilang . Salah satu aspek kod yang baik ialah ketiadaan kod boilerplate yang kerap diulang. Sebagai peraturan, kod tersebut diletakkan dalam kelas berasingan supaya ia boleh dipanggil pada masa yang tepat. AOP Secara berasingan, saya ingin menyebut pengaturcaraan berorientasikan aspek . Ini adalah pengaturcaraan dengan memperkenalkan logik hujung ke hujung, iaitu, kod berulang dimasukkan ke dalam kelas - aspek, dan dipanggil apabila syarat tertentu dicapai. Contohnya, apabila mengakses kaedah dengan nama tertentu atau mengakses pembolehubah jenis tertentu. Kadang-kadang aspek boleh mengelirukan, kerana ia tidak segera jelas dari mana kod dipanggil, tetapi bagaimanapun, ini adalah fungsi yang sangat berguna. Khususnya, apabila caching atau log: kami menambah fungsi ini tanpa menambah logik tambahan pada kelas biasa. Anda boleh membaca lebih lanjut mengenai OAP di sini . 4 Peraturan untuk Merekabentuk Seni Bina Mudah Menurut Kent Beck

1. Ekspresif - keperluan untuk tujuan kelas yang dinyatakan dengan jelas, dicapai melalui penamaan yang betul, saiz kecil dan pematuhan kepada prinsip tanggungjawab tunggal (kita akan melihatnya dengan lebih terperinci di bawah).
2. Sekurang-kurangnya kelas dan kaedah - dalam keinginan anda untuk memecahkan kelas kepada sekecil dan sehala yang mungkin, anda boleh pergi terlalu jauh (antipattern - senapang patah). Prinsip ini memerlukan untuk memastikan sistem padat dan tidak pergi terlalu jauh, mewujudkan kelas untuk setiap bersin.
3. Kekurangan pertindihan - kod tambahan yang mengelirukan adalah tanda reka bentuk sistem yang lemah dan dipindahkan ke tempat yang berasingan.
4. Pelaksanaan semua ujian - sistem yang telah lulus semua ujian dikawal, kerana sebarang perubahan boleh menyebabkan kegagalan ujian, yang boleh menunjukkan kepada kita bahawa perubahan dalam logik dalaman kaedah juga membawa kepada perubahan dalam tingkah laku yang dijangkakan. .

SOLID Apabila mereka bentuk sistem, perlu mengambil kira prinsip SOLID yang terkenal: S - tanggungjawab tunggal - prinsip tanggungjawab tunggal; O - terbuka-tertutup - prinsip keterbukaan/kedekatan; L - Penggantian Liskov - Prinsip penggantian Barbara Liskov; I - pengasingan antara muka - prinsip pemisahan antara muka; D - penyongsangan pergantungan - prinsip penyongsangan pergantungan; Kami tidak akan membincangkan setiap prinsip secara khusus (ini sedikit di luar skop artikel ini, tetapi anda boleh mengetahui lebih lanjut di sini

Antara muka

Mungkin salah satu peringkat yang paling penting untuk mencipta kelas yang mencukupi ialah mencipta antara muka yang mencukupi yang akan mewakili abstraksi yang baik yang menyembunyikan butiran pelaksanaan kelas, dan pada masa yang sama akan mewakili sekumpulan kaedah yang jelas konsisten antara satu sama lain . Mari kita lihat lebih dekat pada salah satu prinsip SOLID - pengasingan antara muka : pelanggan (kelas) tidak seharusnya melaksanakan kaedah yang tidak perlu yang mereka tidak akan gunakan. Iaitu, jika kita bercakap tentang membina antara muka dengan bilangan minimum kaedah yang bertujuan untuk melaksanakan satu-satunya tugas antara muka ini (bagi saya, ia sangat serupa dengan tanggungjawab tunggal ), adalah lebih baik untuk mencipta beberapa yang lebih kecil. yang bukannya satu antara muka kembung. Nasib baik, kelas boleh melaksanakan lebih daripada satu antara muka, seperti halnya dengan warisan. Anda juga perlu ingat tentang penamaan antara muka yang betul: nama itu harus mencerminkan tugasnya setepat mungkin. Dan, sudah tentu, semakin pendek, semakin kurang kekeliruan yang akan ditimbulkan. Pada peringkat antara muka, komen untuk dokumentasi biasanya ditulis , yang, seterusnya, membantu kami menerangkan secara terperinci perkara yang harus dilakukan oleh kaedah, hujah yang diperlukan dan perkara yang akan dikembalikan.

Kelas

Mari kita lihat organisasi dalaman kelas. Atau sebaliknya, beberapa pandangan dan peraturan yang harus dipatuhi semasa membina kelas. Biasanya, kelas harus bermula dengan senarai pembolehubah, disusun dalam susunan tertentu:

1. pemalar statik awam;
2. pemalar statik persendirian;
3. pembolehubah contoh peribadi.

Seterusnya ialah pelbagai pembina dalam susunan daripada lebih sedikit kepada lebih banyak hujah. Ia diikuti oleh kaedah daripada akses yang lebih terbuka kepada yang paling tertutup: sebagai peraturan, kaedah persendirian yang menyembunyikan pelaksanaan beberapa fungsi yang ingin kami hadkan berada di bahagian paling bawah.

Saiz kelas

Sekarang saya ingin bercakap tentang saiz kelas. Mari kita ingat salah satu prinsip SOLID - single responsibility . Tanggungjawab tunggal - prinsip tanggungjawab tunggal. Ia menyatakan bahawa setiap objek hanya mempunyai satu matlamat (tanggungjawab), dan logik semua kaedahnya bertujuan untuk memastikannya. Iaitu, berdasarkan ini, kita harus mengelakkan kelas yang besar dan kembung (yang sifatnya adalah antipattern - "objek ketuhanan"), dan jika kita mempunyai banyak kaedah logik yang pelbagai dan heterogen dalam kelas, kita perlu berfikir tentang memecahkannya kepada beberapa bahagian logik (kelas). Ini, seterusnya, akan meningkatkan kebolehbacaan kod, kerana kita tidak memerlukan banyak masa untuk memahami tujuan kaedah jika kita mengetahui anggaran tujuan kelas tertentu. Anda juga perlu memerhatikan nama kelas : ia harus mencerminkan logik yang terkandung di dalamnya. Katakan, jika kita mempunyai kelas yang namanya mempunyai 20+ perkataan, kita perlu memikirkan tentang pemfaktoran semula. Setiap kelas yang menghormati diri tidak seharusnya mempunyai bilangan pembolehubah dalaman yang begitu besar. Malah, setiap kaedah berfungsi dengan salah satu daripada mereka atau beberapa, yang menyebabkan gandingan yang lebih besar dalam kelas (yang betul-betul seperti yang sepatutnya, kerana kelas itu harus sebagai satu keseluruhan). Akibatnya, meningkatkan koheren kelas membawa kepada penurunan di dalamnya, dan, sudah tentu, bilangan kelas kami bertambah. Bagi sesetengah orang, ini menjengkelkan; mereka perlu pergi ke kelas lebih banyak untuk melihat cara tugas besar tertentu berfungsi. Antara lain, setiap kelas adalah modul kecil yang harus disambungkan secara minimum kepada yang lain. Pengasingan ini mengurangkan bilangan perubahan yang perlu kita buat apabila menambah logik tambahan pada kelas.

Objek

Enkapsulasi

Di sini kita pertama sekali akan bercakap tentang salah satu prinsip pengkapsulan OOP . Oleh itu, menyembunyikan pelaksanaan tidak termasuk untuk mencipta lapisan kaedah antara pembolehubah (mengehadkan akses melalui kaedah tunggal, getter dan setter, yang tidak baik, kerana keseluruhan titik enkapsulasi hilang). Menyembunyikan akses bertujuan untuk membentuk abstraksi, iaitu, kelas menyediakan kaedah konkrit biasa yang melaluinya kami bekerja dengan data kami. Tetapi pengguna tidak perlu mengetahui dengan tepat cara kami bekerja dengan data ini - ia berfungsi, dan tidak mengapa.

Hukum Demeter

Anda juga boleh mempertimbangkan Hukum Demeter: ia adalah satu set peraturan kecil yang membantu mengurus kerumitan pada peringkat kelas dan kaedah. Jadi, mari kita anggap bahawa kita mempunyai objek Cardan ia mempunyai kaedah - move(Object arg1, Object arg2). Menurut Undang-undang Demeter, kaedah ini terhad kepada panggilan:

• kaedah objek itu sendiri Car(dengan kata lain, ini);
• kaedah objek yang dicipta dalam move;
• kaedah objek yang diluluskan sebagai hujah - arg1, arg2;
• kaedah objek dalaman Car(sama ini).

Dalam erti kata lain, undang-undang Demeter adalah seperti peraturan kanak-kanak - anda boleh bercakap dengan rakan, tetapi tidak dengan orang yang tidak dikenali .

Struktur data

Struktur data ialah himpunan elemen yang berkaitan. Apabila mempertimbangkan objek sebagai struktur data, ia adalah satu set elemen data yang diproses dengan kaedah, kewujudan yang tersirat secara tersirat. Iaitu, ia adalah objek yang tujuannya adalah untuk menyimpan dan mengendalikan (memproses) data yang disimpan. Perbezaan utama daripada objek biasa ialah objek ialah satu set kaedah yang beroperasi pada elemen data yang kewujudannya tersirat. Adakah anda faham? Dalam objek biasa, aspek utama ialah kaedah, dan pembolehubah dalaman ditujukan kepada operasi yang betul, tetapi dalam struktur data ia adalah sebaliknya: kaedah menyokong dan membantu berfungsi dengan elemen yang disimpan, yang merupakan yang utama di sini. Satu jenis struktur data ialah Data Transfer Object (DTO) . Ini ialah kelas dengan pembolehubah awam dan tiada kaedah (atau kaedah baca/tulis sahaja) yang menghantar data apabila bekerja dengan pangkalan data, berfungsi dengan menghuraikan mesej daripada soket, dll. Biasanya, data dalam objek tersebut tidak disimpan untuk masa yang lama dan ditukar hampir serta-merta kepada entiti yang digunakan oleh aplikasi kami. Entiti, seterusnya, juga merupakan struktur data, tetapi tujuannya adalah untuk mengambil bahagian dalam logik perniagaan pada peringkat aplikasi yang berbeza, manakala DTO adalah untuk mengangkut data ke/dari aplikasi. Contoh DTO:

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

Segala-galanya kelihatan jelas, tetapi di sini kita belajar tentang kewujudan hibrid. Hibrid adalah objek yang mengandungi kaedah untuk mengendalikan logik penting dan menyimpan elemen dalaman dan kaedah capaian (dapatkan/set) kepada mereka. Objek sedemikian tidak kemas dan menyukarkan untuk menambah kaedah baharu. Anda tidak boleh menggunakannya, kerana tidak jelas tujuannya - menyimpan elemen atau melakukan beberapa jenis logik. Anda boleh membaca tentang kemungkinan jenis objek di sini .

Prinsip mencipta pembolehubah

Mari kita fikirkan sedikit tentang pembolehubah, atau sebaliknya, fikirkan tentang prinsip untuk menciptanya:

1. Sebaik-baiknya, anda harus mengisytiharkan dan memulakan pembolehubah serta-merta sebelum menggunakannya (daripada menciptanya dan melupakannya).
2. Apabila boleh, isytiharkan pembolehubah sebagai muktamad untuk mengelakkan nilainya berubah selepas permulaan.
3. Jangan lupa tentang pembolehubah pembilang (biasanya kita menggunakannya dalam beberapa jenis gelung for, iaitu, kita tidak boleh lupa untuk menetapkannya semula, jika tidak, ia boleh memecahkan keseluruhan logik kita).
4. Anda harus cuba memulakan pembolehubah dalam pembina.
5. Jika terdapat pilihan antara menggunakan objek dengan atau tanpa rujukan ( new SomeObject()), pilih tanpa ( ), kerana objek ini, setelah digunakan, akan dipadamkan semasa pengumpulan sampah seterusnya dan tidak akan membazir sumber.
6. Jadikan jangka hayat pembolehubah sesingkat mungkin (jarak antara penciptaan pembolehubah dan akses terakhir).
7. Mulakan pembolehubah yang digunakan dalam gelung sejurus sebelum gelung, bukannya pada permulaan kaedah yang mengandungi gelung.
8. Sentiasa mulakan dengan skop yang paling terhad dan kembangkannya hanya jika perlu (anda harus cuba menjadikan pembolehubah sebagai setempat yang mungkin).
9. Gunakan setiap pembolehubah untuk satu tujuan sahaja.
10. Elakkan pembolehubah dengan makna tersembunyi (pembolehubah itu terbelah antara dua tugasan, yang bermaksud jenisnya tidak sesuai untuk menyelesaikan salah satu daripadanya).

Kaedah

Mari kita beralih terus kepada pelaksanaan logik kita, iaitu, kepada kaedah.

1. Peraturan pertama ialah kekompakan. Sebaik-baiknya, satu kaedah tidak boleh melebihi 20 baris, jadi jika, katakan, kaedah awam "membengkak" dengan ketara, anda perlu berfikir tentang memindahkan logik yang dipisahkan ke kaedah peribadi.

2. Peraturan kedua ialah sekatan dalam commands if, else, whiledan seterusnya tidak boleh sangat bersarang: ini mengurangkan kebolehbacaan kod dengan ketara. Sebaik-baiknya, sarang hendaklah tidak lebih daripada dua blok {}.

   Ia juga dinasihatkan untuk membuat kod dalam blok ini padat dan ringkas.

3. Peraturan ketiga ialah kaedah mesti melakukan hanya satu operasi. Iaitu, jika kaedah melakukan logik yang kompleks dan pelbagai, kami membahagikannya kepada subkaedah. Akibatnya, kaedah itu sendiri akan menjadi fasad, tujuannya adalah untuk memanggil semua operasi lain dalam susunan yang betul.

   Tetapi bagaimana jika operasi kelihatan terlalu mudah untuk mencipta kaedah berasingan? Ya, kadangkala ia kelihatan seperti menembak burung pipit dari meriam, tetapi kaedah kecil memberikan beberapa faedah:

   • membaca kod yang lebih mudah;
   • kaedah cenderung menjadi lebih kompleks sepanjang pembangunan, dan jika kaedah itu pada mulanya mudah, merumitkan fungsinya akan menjadi lebih mudah;
   • menyembunyikan butiran pelaksanaan;
   • memudahkan penggunaan semula kod;
   • kebolehpercayaan kod yang lebih tinggi.

4. Peraturan ke bawah ialah kod harus dibaca dari atas ke bawah: semakin rendah, semakin besar kedalaman logik, dan sebaliknya, semakin tinggi, kaedah yang lebih abstrak. Sebagai contoh, arahan suis agak tidak padat dan tidak diingini, tetapi jika anda tidak boleh melakukannya tanpa menggunakan suis, anda harus cuba mengalihkannya serendah mungkin, ke kaedah peringkat terendah.

5. Hujah kaedah - berapa banyak yang ideal? Sebaik-baiknya, tiada langsung)) Tetapi adakah itu benar-benar berlaku? Walau bagaimanapun, anda harus cuba untuk memilikinya sesedikit mungkin, kerana semakin sedikit, semakin mudah untuk menggunakan kaedah ini dan semakin mudah untuk mengujinya. Jika ragu-ragu, cuba teka semua senario untuk menggunakan kaedah dengan sejumlah besar argumen input.

6. Secara berasingan, saya ingin menyerlahkan kaedah yang mempunyai bendera boolean sebagai hujah input , kerana ini secara semula jadi membayangkan bahawa kaedah ini melaksanakan lebih daripada satu operasi (jika benar maka satu, palsu - satu lagi). Seperti yang saya tulis di atas, ini tidak baik dan harus dielakkan jika boleh.

7. Jika kaedah mempunyai sejumlah besar argumen masuk (nilai ekstrem ialah 7, tetapi anda harus memikirkannya selepas 2-3), anda perlu mengumpulkan beberapa argumen dalam objek yang berasingan.

8. Jika terdapat beberapa kaedah yang serupa (terlebih beban) , maka parameter yang serupa mesti diluluskan dalam susunan yang sama: ini meningkatkan kebolehbacaan dan kebolehgunaan.

9. Apabila anda menghantar parameter kepada kaedah, anda mesti yakin bahawa semuanya akan digunakan, jika tidak, untuk apa hujahnya? Potong ia daripada antara muka dan itu sahaja.

10. try/catchIa tidak kelihatan sangat bagus mengikut sifatnya, jadi langkah yang baik ialah memindahkannya ke kaedah berasingan perantaraan (kaedah untuk mengendalikan pengecualian):

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

Saya bercakap tentang mengulangi kod di atas, tetapi saya akan menambahkannya di sini: Jika kita mempunyai beberapa kaedah dengan mengulangi bahagian kod, kita perlu memindahkannya ke kaedah yang berasingan, yang akan meningkatkan kekompakan kedua-dua kaedah dan kelas. Dan jangan lupa tentang nama yang betul. Saya akan memberitahu anda butiran penamaan kelas, antara muka, kaedah dan pembolehubah yang betul di bahagian seterusnya artikel. Dan itu sahaja yang saya ada untuk hari ini. Peraturan kod: kuasa penamaan yang betul, komen yang baik dan buruk