Aturan kanggo nulis kode: saka nggawe sistem kanggo nggarap obyek

Sugeng sonten sedaya: dina iki aku arep ngomong karo sampeyan babagan nulis kode sing bener. Nalika aku miwiti program, ora ditulis kanthi jelas ing ngendi wae yen sampeyan bisa nulis kaya iki, lan yen sampeyan nulis kaya iki, aku bakal nemokake sampeyan lan…. Akibaté, aku duwe akeh pitakonan ing sirahku: carane nulis kanthi bener, prinsip apa sing kudu ditindakake ing bagean iki utawa program kasebut, lan liya-liyane. Ya, ora kabeh wong pengin langsung nyilem menyang buku kaya Kode Bersih, amarga akeh sing ditulis ing buku kasebut, nanging wiwitane ora jelas. Lan nalika sampeyan wis rampung maca, sampeyan bisa ngilangi kabeh kepinginan kanggo kode. Dadi adhedhasar ing ndhuwur, dina iki aku pengin menehi pandhuan cilik (sakumpulan rekomendasi cilik) kanggo nulis kode tingkat sing luwih dhuwur. Ing artikel iki kita bakal njlèntrèhaké aturan dhasar lan konsep sing ana hubungane karo nggawe sistem lan nggarap antarmuka, kelas lan obyek. Maca materi iki ora butuh wektu akeh lan, muga-muga, ora bakal bosen. Aku bakal pindhah saka ndhuwur menyang ngisor, yaiku, saka struktur umum aplikasi menyang rincian sing luwih spesifik.

Sistem

Karakteristik umum sistem sing dikarepake yaiku:

• kerumitan minimal - proyèk kebacut rumit kudu nyingkiri. Sing utama yaiku kesederhanaan lan kajelasan (paling apik = prasaja);
• ease saka pangopènan - nalika nggawe aplikasi, sampeyan kudu ngelingi sing kudu didhukung (sanajan dudu sampeyan), supaya kode kudu cetha lan ketok;
• kopling banget iku nomer minimal sambungan antarane macem-macem bagean saka program (maksimum nggunakake prinsip OOP);
• reusability - ngrancang sistem kanthi kemampuan kanggo nggunakake maneh pecahan ing aplikasi liyane;
• portabilitas - sistem kudu gampang diadaptasi menyang lingkungan liyane;
• gaya tunggal - ngrancang sistem kanthi gaya siji ing pecahan sing beda;
• extensibility (scalability) - Ngapikake sistem tanpa ngganggu struktur dhasar (yen sampeyan nambah utawa ngganti pecahan, iki ngirim ora mengaruhi liyane).

Sakbenere mokal kanggo mbangun aplikasi sing ora mbutuhake modifikasi, tanpa nambah fungsi. Kita kudu terus-terusan ngenalake unsur-unsur anyar supaya otak kita bisa ngetutake jaman. Lan ing kene ana skalabilitas . Skalabilitas ateges ngembangake aplikasi, nambah fungsionalitas anyar, nggarap sumber daya liyane (utawa, kanthi tembung liyane, kanthi beban luwih akeh). Yaiku, kita kudu netepi sawetara aturan, kayata nyuda kopling sistem kanthi nambah modularitas, supaya luwih gampang nambah logika anyar.

Tahap desain sistem

1. Sistem piranti lunak - ngrancang aplikasi ing wangun umum.
2. Pemisahan menyang subsistem / paket - nemtokake bagean sing bisa dipisahake kanthi logis lan nemtokake aturan interaksi ing antarane.
3. Dibagi subsistem menyang kelas - mbagi bagean sistem menyang kelas lan antarmuka tartamtu, uga nemtokake interaksi ing antarane.
4. Dibagi kelas dadi metode yaiku definisi lengkap babagan metode sing dibutuhake kanggo kelas, adhedhasar tugas kelas iki. Desain metode - definisi rinci babagan fungsi metode individu.

Biasane, pangembang biasa tanggung jawab kanggo desain, lan arsitek aplikasi tanggung jawab kanggo item kasebut ing ndhuwur.

Prinsip utama lan konsep desain sistem

Lazy initialization idiom Aplikasi ora nglampahi wektu nggawe obyek nganti digunakake, sing nyepetake proses initialization lan nyuda beban kolektor sampah. Nanging sampeyan ora kudu adoh banget karo iki, amarga iki bisa nyebabake pelanggaran modularitas. Sampeyan bisa uga kudu mindhah kabeh langkah desain menyang bagean tartamtu, contone, utama, utawa menyang kelas sing kerjane kaya pabrik . Salah sawijining aspek kode sing apik yaiku ora ana kode boilerplate sing kerep diulang. Minangka aturan, kode kasebut diselehake ing kelas sing kapisah supaya bisa diarani ing wektu sing tepat. AOP Kapisah, aku pengin nyebutake pemrograman berorientasi aspek . Iki pemrograman kanthi ngenalake logika end-to-end, yaiku, mbaleni kode dilebokake ing kelas - aspek, lan diarani nalika kondisi tartamtu wis tekan. Contone, nalika ngakses metode kanthi jeneng tartamtu utawa ngakses variabel saka jinis tartamtu. Kadhangkala aspek bisa mbingungake, amarga ora langsung jelas saka ngendi kode kasebut diarani, nanging iki minangka fungsi sing migunani banget. Utamane, nalika caching utawa logging: kita nambah fungsi iki tanpa nambah logika tambahan kanggo kelas biasa. Sampeyan bisa maca liyane babagan OAP kene . 4 Aturan kanggo Ngrancang Arsitektur Sederhana Miturut Kent Beck

1. Expressiveness - perlu kanggo tujuan cetha ditulis ing kelas, wis ngrambah liwat jeneng bener, ukuran cilik lan ketaatan kanggo prinsip tanggung jawab siji (kita bakal katon ing luwih rinci ing ngisor iki).
2. Minimal kelas lan cara - ing kepinginan kanggo break kelas dadi cilik lan unidirectional sabisa, sampeyan bisa pindhah adoh banget (antipattern - shotgunning). Prinsip iki mbutuhake supaya sistem tetep kompak lan ora adoh banget, nggawe kelas kanggo saben wahing.
3. Kurang duplikasi - kode ekstra sing mbingungake minangka tandha desain sistem sing ora apik lan dipindhah menyang papan sing kapisah.
4. Eksekusi kabeh tes - sistem sing wis lulus kabeh tes dikontrol, amarga owah-owahan bisa nyebabake kegagalan tes, sing bisa nuduhake yen owah-owahan ing logika internal metode kasebut uga nyebabake owah-owahan ing prilaku sing dikarepake. .

SOLID Nalika ngrancang sistem, perlu nggatekake prinsip SOLID sing kondhang: S - tanggung jawab tunggal - prinsip tanggung jawab tunggal; O - mbukak-tutup - prinsip openness / closeness; L - substitusi Liskov - prinsip substitusi Barbara Liskov; I - segregasi antarmuka - prinsip pamisahan antarmuka; D - inversi dependensi - prinsip inversi dependensi; Kita ora bakal mikir babagan saben prinsip khusus (iki rada ngluwihi ruang lingkup artikel iki, nanging sampeyan bisa ngerteni luwih akeh ing kene .

Antarmuka

Mbok menawa salah sawijining tahap paling penting kanggo nggawe kelas sing nyukupi yaiku nggawe antarmuka sing nyukupi sing bakal makili abstraksi apik sing ndhelikake rincian implementasi kelas, lan ing wektu sing padha bakal makili klompok metode sing jelas konsisten karo saben liyane. . Ayo goleki kanthi luwih rinci babagan salah sawijining prinsip SOLID - pemisahan antarmuka : klien (kelas) ora kudu ngetrapake cara sing ora perlu sing ora bakal digunakake. Yaiku, yen kita ngomong babagan mbangun antarmuka kanthi jumlah minimal cara sing dituju kanggo nindakake tugas mung antarmuka iki (minangka aku, meh padha karo tanggung jawab siji ), luwih becik nggawe sawetara sing luwih cilik. tinimbang siji antarmuka sing kembung. Untunge, kelas bisa ngetrapake luwih saka siji antarmuka, kayadene warisan. Sampeyan uga kudu ngelingi babagan jeneng antarmuka sing bener: jeneng kasebut kudu nggambarake tugas kanthi akurat. Lan, mesthi, sing luwih cendhek, kurang kebingungan bakal nyebabake. Ing tingkat antarmuka sing komentar kanggo dokumentasi biasane ditulis , kang, ing siji, mbantu kita njlèntrèhaké kanthi rinci apa cara kudu nindakake, apa bantahan lan apa bakal bali.

kelas

Ayo ndeleng organisasi internal kelas. Utawa, sawetara tampilan lan aturan sing kudu ditindakake nalika mbangun kelas. Biasane, kelas kudu diwiwiti kanthi dhaptar variabel, disusun kanthi urutan tartamtu:

1. konstanta statis umum;
2. konstanta statis pribadi;
3. variabel conto pribadi.

Sabanjure ana macem-macem konstruktor kanthi urutan saka argumen sing luwih sithik nganti luwih akeh. Dheweke diterusake kanthi cara saka akses sing luwih mbukak menyang sing paling ditutup: minangka aturan, cara pribadi sing ndhelikake implementasine sawetara fungsi sing pengin kita matesi ana ing sisih ngisor.

Ukuran kelas

Saiki aku arep ngomong babagan ukuran kelas. Ayo elinga salah sawijining prinsip tanggung jawab SOLID - tunggal . Tanggung jawab tunggal - prinsip tanggung jawab tunggal. Iki nyatakake yen saben obyek mung nduweni siji tujuan (tanggung jawab), lan logika kabeh cara kasebut ditujokake kanggo njamin. Dadi, adhedhasar iki, kita kudu ngindhari kelas gedhe lan kembung (sing kanthi sifate minangka antipattern - "obyek gaib"), lan yen kita duwe akeh metode logika heterogen ing kelas, kita kudu mikir. bab bejat menyang saperangan bagean logis (kelas). Iki, ing siji, bakal nambah readability saka kode, amarga kita ora perlu akeh wektu kanggo ngerti tujuan saka cara yen kita ngerti tujuan kira-kira saka kelas tartamtu. Sampeyan uga kudu ngati-ati jeneng kelas : kudu nggambarake logika sing ana. Contone, yen kita duwe kelas sing jenenge duwe 20+ tembung, kita kudu mikir babagan refactoring. Saben kelas sing ngurmati awake dhewe ora kudu duwe variabel internal sing akeh banget. Nyatane, saben cara bisa digunakake karo siji utawa sawetara, sing nyebabake kopling luwih gedhe ing kelas kasebut (sing mesthine, amarga kelas kasebut kudu dadi siji). Akibaté, nambah koherensi saka kelas ndadékaké kanggo nyuda ing minangka kuwi, lan, mesthi, nomer kita kelas mundhak. Kanggo sawetara, iki ngganggu; dheweke kudu mlebu kelas luwih akeh kanggo ndeleng kepiye tugas gedhe sing spesifik. Antarane liyane, saben kelas minangka modul cilik sing kudu disambungake minimal karo liyane. Isolasi iki nyuda jumlah owah-owahan sing kudu ditindakake nalika nambah logika tambahan ing kelas.

Obyek

Enkapsulasi

Ing kene kita bakal ngomong babagan salah sawijining prinsip OOP - enkapsulasi . Dadi, ndhelikake implementasine ora mudhun kanggo nggawe lapisan metode antarane variabel (tanpa dipikirake mbatesi akses liwat metode siji, getter lan setters, sing ora apik, amarga kabeh titik enkapsulasi wis ilang). Akses ndhelikake ditujokake kanggo mbentuk abstraksi, yaiku, kelas nyedhiyakake metode konkrit umum sing bisa digunakake karo data kita. Nanging pangguna ora perlu ngerti persis cara kita nggarap data iki - bisa digunakake, lan ora apa-apa.

Hukum Demeter

Sampeyan uga bisa nimbang Hukum Demeter: iku pesawat cilik saka aturan sing mbantu ngatur kerumitan ing kelas lan cara tingkat. Dadi, ayo nganggep manawa kita duwe obyek Carlan duwe metode - move(Object arg1, Object arg2). Miturut Hukum Demeter, cara iki diwatesi kanggo nelpon:

• cara obyek dhewe Car(ing tembung liyane, iki);
• cara obyek digawe ing move;
• cara obyek liwati minangka argumen - arg1,;arg2
• cara obyek internal Car(padha iki).

Ing tembung liyane, hukum Demeter kaya aturan anak - sampeyan bisa ngomong karo kanca-kanca, nanging ora karo wong liyo .

Struktur data

Struktur data minangka kumpulan unsur-unsur sing ana gandhengane. Nalika nganggep obyek minangka struktur data, yaiku sakumpulan unsur data sing diolah kanthi cara, anane sing diimplisit. Yaiku obyek sing tujuane kanggo nyimpen lan ngoperasikake (ngolah) data sing disimpen. Bentenane utama saka obyek biasa yaiku obyek minangka sakumpulan metode sing ngoperasikake unsur data sing ora ana. Ngerti ta? Ing obyek biasa, aspek utama yaiku metode, lan variabel internal ditujokake kanggo operasi sing bener, nanging ing struktur data iku sebaliknya: metode ndhukung lan mbantu nggarap unsur sing disimpen, sing utama ing kene. Salah sawijining jinis struktur data yaiku Data Transfer Object (DTO) . Iki minangka kelas kanthi variabel umum lan ora ana metode (utawa mung cara maca / nulis) sing ngliwati data nalika nggarap database, nggarap pesen parsing saka soket, dsb. Biasane, data ing obyek kasebut ora disimpen suwe lan ora disimpen. meh langsung diowahi dadi entitas sing digunakake aplikasi kita. Entitas uga minangka struktur data, nanging tujuane kanggo melu logika bisnis ing macem-macem tingkat aplikasi, dene DTO kanggo ngirim data menyang / saka aplikasi. Tuladha DTO:

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

Kabeh katon jelas, nanging ing kene kita sinau babagan eksistensi hibrida. Hibrida minangka obyek sing ngemot cara kanggo nangani logika penting lan nyimpen unsur internal lan cara akses (njaluk / nyetel) menyang. Obyek kaya mengkono iku ora apik lan nggawe angel kanggo nambah cara anyar. Sampeyan ora kudu nggunakake, amarga ora jelas apa sing dimaksudake - nyimpen unsur utawa nindakake sawetara logika. Sampeyan bisa maca bab bisa jinis obyek kene .

Prinsip nggawe variabel

Ayo dipikirake sethithik babagan variabel, utawa luwih becik, pikirake apa prinsip kanggo nggawe:

1. Saenipun, sampeyan kudu ngumumake lan miwiti variabel langsung sadurunge nggunakake (tinimbang nggawe lan dilalekake).
2. Yen bisa, wara-wara variabel minangka final kanggo nyegah nilai saka owah-owahan sawise initialization.
3. Aja lali babagan variabel counter (biasane digunakake ing sawetara jinis daur ulang for, yaiku, kita kudu ora lali kanggo ngreset, yen ora, bisa ngrusak kabeh logika).
4. Sampeyan kudu nyoba kanggo miwiti variabel ing konstruktor.
5. Yen ana pilihan antarane nggunakake obyek karo utawa tanpa referensi ( new SomeObject()), pilih tanpa ( ), wiwit obyek iki, yen digunakake, bakal dibusak sak koleksi sampah sabanjuré lan ora bakal sampah sumber.
6. Nggawe umur variabel minangka cendhak sabisa (jarak antarane nggawe variabel lan akses pungkasan).
7. Inisialisasi variabel sing digunakake ing loop langsung sadurunge loop, tinimbang ing wiwitan metode sing ngemot loop.
8. Tansah miwiti karo orane katrangan paling winates lan nggedhekake mung yen perlu (sampeyan kudu nyoba kanggo nggawe variabel minangka lokal sabisa).
9. Gunakake saben variabel mung kanggo siji waé.
10. Ngindhari variabel kanthi makna sing didhelikake (variabel kasebut ambruk ing antarane rong tugas, tegese jinise ora cocog kanggo ngrampungake salah sawijining).

Metode

Ayo langsung pindhah menyang implementasine logika kita, yaiku, kanggo metode.

1. Aturan pisanan yaiku kompak. Saenipun, siji cara ngirim ora ngluwihi 20 baris, supaya yen, ngomong, cara umum "swells" Ngartekno, sampeyan kudu mikir babagan mindhah logika kapisah menyang cara pribadi.

2. Aturan kapindho yaiku pamblokiran ing printah if, else, whilelan liya-liyane ora kudu dilebokake kanthi dhuwur: iki kanthi signifikan nyuda keterbacaan kode kasebut. Saenipun, nesting ngirim ora luwih saka rong blok {}.

   Sampeyan uga dianjurake kanggo nggawe kode ing blok kasebut kompak lan gampang.

3. Aturan katelu yaiku cara kudu nindakake mung siji operasi. Yaiku, yen metode nindakake logika sing kompleks lan macem-macem, kita dibagi dadi submetode. Akibaté, cara kasebut bakal dadi fasad, tujuane kanggo nelpon kabeh operasi liyane kanthi urutan sing bener.

   Nanging apa yen operasi katon gampang banget kanggo nggawe cara sing kapisah? Ya, kadhangkala bisa uga katon kaya manuk pipit metu saka meriam, nanging cara cilik menehi sawetara keuntungan:

   • maca kode luwih gampang;
   • metode cenderung dadi luwih rumit sajrone pangembangan, lan yen metode kasebut wiwitane gampang, ngrampungake fungsine bakal luwih gampang;
   • ndhelikake rincian implementasine;
   • nggampangake nggunakake maneh kode;
   • linuwih kode luwih.

4. Aturan mudhun yaiku kode kasebut kudu diwaca saka ndhuwur nganti ngisor: sing luwih ngisor, sing luwih jero logika, lan kosok balene, sing luwih dhuwur, cara sing luwih abstrak. Contone, printah switch cukup uncompact lan undesirable, nanging yen sampeyan ora bisa nindakake tanpa nggunakake saklar, sampeyan kudu nyoba kanggo mindhah minangka kurang sabisa, menyang cara-tingkat paling.

5. Argumen metode - pira sing becik? Saenipun, ora ana apa-apa)) Nanging apa pancen kedadeyan? Nanging, sampeyan kudu nyoba kanggo duwe sawetara saka wong-wong mau sabisa, amarga kurang ana, luwih gampang nggunakake cara iki lan luwih gampang kanggo nyoba. Yen mangu-mangu, nyoba kanggo guess kabeh skenario kanggo nggunakake cara karo nomer akeh bantahan input.

6. Dhewe, aku pengin nyorot metode sing duwe gendera boolean minangka argumen input , amarga iki tegese cara iki nindakake luwih saka siji operasi (yen bener banjur siji, palsu - liyane). Nalika aku nulis ing ndhuwur, iki ora apik lan kudu dihindari yen bisa.

7. Yen cara wis nomer akeh bantahan mlebu (nilai nemen 7, nanging sampeyan kudu mikir bab iku sawise 2-3), sampeyan kudu klompok sawetara bantahan ing obyek kapisah.

8. Yen ana sawetara cara sing padha (overloaded) , banjur paramèter sing padha kudu dilewati kanthi urutan sing padha: iki nambah keterbacaan lan kegunaan.

9. Nalika sampeyan ngliwati paramèter menyang cara, sampeyan kudu yakin manawa kabeh bakal digunakake, yen ora, apa argumen kasebut? Cut metu saka antarmuka lan sing.

10. try/catchIku ora katon apik banget dening alam, supaya pamindhahan apik bakal pindhah menyang cara kapisah penengah (metode kanggo nangani pengecualian):

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

Aku ngandika bab mbaleni kode ndhuwur, nanging aku bakal nambah kene: Yen kita duwe sawetara cara karo mbaleni bagean kode, kita kudu pindhah menyang cara kapisah, kang bakal nambah compactness saka loro cara lan kelas. Lan aja lali babagan jeneng sing bener. Aku bakal menehi katrangan babagan jeneng kelas, antarmuka, metode lan variabel sing bener ing bagean sabanjure artikel kasebut. Lan iku kabeh aku duwe kanggo dina iki. Aturan kode: kekuwatan menehi jeneng sing tepat, komentar apik lan ala