Sugeng dina, kabeh! Dina iki kita arep ngomong karo sampeyan babagan nulis kode sing apik. Mesthi wae, ora kabeh wong pengin langsung ngunyah buku kaya Kode Resik, amarga ngemot informasi sing akeh nanging ora akeh sing jelas. Lan nalika sampeyan rampung maca, sampeyan bisa mateni kabeh kepinginan kanggo kode. Ngelingi kabeh mau, dina iki aku pengin menehi pandhuan cilik (set cilik saka rekomendasi) kanggo nulis kode sing luwih apik. Ing artikel iki, ayo goleki aturan lan konsep dhasar sing ana gandhengane karo nggawe sistem lan nggarap antarmuka, kelas, lan obyek. Maca artikel iki ora butuh wektu akeh lan, muga-muga sampeyan ora bakal bosen. Aku bakal ngupayakake saka ndhuwur nganti ngisor, yaiku saka struktur umum aplikasi nganti rincian sing luwih sempit.
Sistem
Ing ngisor iki umume karakteristik sistem sing dikarepake:
Kompleksitas minimal. Proyek sing rumit banget kudu dihindari. Sing paling penting yaiku prasaja lan gamblang (luwih prasaja = luwih apik).
Gampang pangopènan. Nalika nggawe aplikasi, sampeyan kudu eling yen aplikasi kasebut kudu dijaga (sanajan sampeyan ora tanggung jawab kanggo njaga). Iki tegese kode kudu jelas lan jelas.
Kopling longgar. Iki tegese kita nyilikake jumlah dependensi ing antarane macem-macem bagean program (ngoptimalake selaras karo prinsip OOP).
Bisa digunakake maneh. Kita ngrancang sistem kanthi kemampuan kanggo nggunakake maneh komponen ing aplikasi liyane.
Portabilitas. Sampeyan kudu gampang adaptasi sistem menyang lingkungan liyane.
Gaya seragam. Kita ngrancang sistem nggunakake gaya seragam ing macem-macem komponen.
Extensibility (skalabilitas). Kita bisa nambah sistem tanpa nglanggar struktur dhasar (nambah utawa ngganti komponen ngirim ora mengaruhi kabeh liyane).
Sacoro prakteke mokal kanggo mbangun aplikasi sing ora mbutuhake modifikasi utawa fungsi anyar. Kita kudu terus nambah bagean anyar kanggo mbantu bocah-bocah supaya bisa ngetutake jaman. Iki minangka skalabilitas. Skalabilitas ateges ngluwihi aplikasi, nambah fungsionalitas anyar, lan nggarap sumber daya liyane (utawa, kanthi tembung liyane, kanthi beban sing luwih gedhe). Ing tembung liyane, supaya luwih gampang kanggo nambah logika anyar, kita kelet kanggo sawetara aturan, kayata ngurangi kopling sistem dening nambah modularity.
Divisi dadi subsistem/paket. Nemtokake bagean sing beda-beda kanthi logis lan nemtokake aturan kanggo interaksi ing antarane.
Divisi subsistem menyang kelas. Dibagi bagean saka sistem menyang kelas tartamtu lan antarmuka, lan nemtokake interaksi antarane wong-wong mau.
Divisi kelas dadi metode. Nggawe definisi lengkap babagan cara sing dibutuhake kanggo kelas, adhedhasar tanggung jawab sing diwenehake.
Desain metode. Nggawe definisi rinci babagan fungsionalitas metode individu.
Biasane pangembang biasa nangani desain iki, dene arsitek aplikasi nangani poin sing dijelasake ing ndhuwur.
Dhasar kekarepan panggolékan lan kagunaan kang umum saka system design
Inisialisasi malas. Ing idiom pemrograman iki, aplikasi ora mbuwang wektu nggawe obyek nganti bener digunakake. Iki nyepetake proses initialization lan nyuda beban ing kolektor sampah. Sing jarene, sampeyan ora kudu adoh banget, amarga bisa nglanggar prinsip modularitas. Mbok menawa kudu mindhah kabeh conto konstruksi menyang bagean tartamtu, contone, metode utama utawa kelas pabrik . Salah sawijining ciri kode sing apik yaiku ora ana kode boilerplate sing bola-bali. Minangka aturan, kode kasebut diselehake ing kelas sing kapisah supaya bisa diarani yen perlu.
AOP
Aku uga pengin nyathet pemrograman berorientasi aspek. Paradigma pemrograman iki kabeh babagan ngenalake logika transparan. Tegese, kode repetitive dilebokake ing kelas (aspek) lan diarani nalika kondisi tartamtu wis wareg. Contone, nalika nelpon cara 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. Utamané nalika caching utawa logging. Kita nambah fungsi iki tanpa nambah logika tambahan kanggo kelas biasa. Patang aturan Kent Beck kanggo arsitektur prasaja:
Ekspresif - Maksud saka kelas kudu ditulis kanthi jelas. Iki digayuh liwat jeneng sing tepat, ukuran cilik, lan ketaatan prinsip tanggung jawab siji (sing bakal kita nimbang luwih rinci ing ngisor iki).
Jumlah minimal saka kelas lan cara - Ing kepinginan kanggo nggawe kelas minangka cilik lan narrowly fokus sabisa, sampeyan bisa pindhah adoh banget (ngasilaké operasi shotgun anti-pola). Prinsip iki mbutuhake supaya sistem tetep kompak lan ora adoh banget, nggawe kelas sing kapisah kanggo saben tumindak sing bisa ditindakake.
Ora ana duplikasi - Kode duplikat, sing nggawe kebingungan lan minangka indikasi desain sistem suboptimal, diekstrak lan dipindhah menyang lokasi sing kapisah.
Nglakokake kabeh tes - Sistem sing lulus kabeh tes bisa diatur. Sembarang owah-owahan bisa nyebabake tes gagal, nuduhake yen owah-owahan ing logika internal metode uga ngganti prilaku sistem kanthi cara sing ora dikarepake.
SOLID
Nalika ngrancang sistem, prinsip SOLID sing kondhang kudu ditimbang:
S (tanggung jawab tunggal), O (mbukak-tutup), L (substitusi Liskov), I (segregasi antarmuka), D (inversi dependensi).
Kita ora bakal mikir babagan saben prinsip individu. Sing bakal dadi sethitik ngluwihi orane katrangan saka artikel iki, nanging sampeyan bisa maca liyane kene .
Antarmuka
Mbok menawa salah sawijining langkah sing paling penting kanggo nggawe kelas sing dirancang kanthi apik yaiku nggawe antarmuka sing dirancang kanthi apik sing nggambarake abstraksi sing apik, ndhelikake rincian implementasi kelas lan kanthi bebarengan nampilake klompok metode sing jelas konsisten karo siji 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. Ing tembung liya, yen kita ngomong babagan nggawe antarmuka kanthi cara paling sithik kanggo nindakake tugas antarmuka (sing dakanggep meh padha karo prinsip tanggung jawab tunggal), luwih becik nggawe sawetara sing luwih cilik tinimbang. saka siji antarmuka kembung. Untunge, kelas bisa ngetrapake luwih saka siji antarmuka. Elinga jeneng antarmuka kanthi bener: jeneng kasebut kudu nggambarake tugas sing ditugasake kanthi akurat. Lan, mesthi, sing luwih cendhek, sing kurang kebingungan bakal nyebabake. Komentar dokumentasi biasane ditulis ing tingkat antarmuka. Komentar kasebut menehi katrangan babagan apa sing kudu ditindakake saben metode, argumen apa sing dibutuhake, lan apa sing bakal ditindakake.
Ayo goleki carane kelas disusun sacara internal. Utawa, sawetara perspektif lan aturan sing kudu ditindakake nalika nulis kelas. Minangka aturan, kelas kudu diwiwiti kanthi dhaptar variabel kanthi urutan tartamtu:
konstanta statis umum;
konstanta statis pribadi;
variabel conto pribadi.
Sabanjure teka macem-macem konstruktor, supaya saka sing duwe argumentasi paling sithik nganti sing paling akeh. Dheweke diterusake kanthi cara saka sing paling umum nganti sing paling pribadi. Umumé, cara pribadi sing ndhelikake implementasine sawetara fungsi sing pengin diwatesi ana ing sisih ngisor.
Ukuran kelas
Saiki aku arep ngomong babagan ukuran kelas. Ayo ngelingi salah sawijining prinsip SOLID — prinsip tanggung jawab tunggal. Iki nyatakake yen saben obyek mung nduweni siji tujuan (tanggung jawab), lan logika kabeh cara kasebut nduweni tujuan kanggo ngrampungake. Iki ngandhani supaya ora kelas gedhe lan kembung (sing sejatine minangka anti-pola obyek Allah), lan yen kita duwe akeh metode kanthi macem-macem logika sing beda-beda ing kelas, kita kudu mikir babagan pamisah kasebut dadi a saperangan bagean logis (kelas). Iki, ing siji, bakal nambah readability saka kode, awit iku ora bakal njupuk dawa kanggo ngerti tujuan saben cara yen kita ngerti tujuan kira-kira sembarang kelas tartamtu. Uga, priksa jeneng kelas, sing kudu nggambarake logika sing ana. Contone, yen kita duwe kelas kanthi 20+ tembung ing jenenge, kita kudu mikir babagan refactoring. Sembarang kelas sing ngurmati dhiri kudu ora duwe variabel internal sing akeh. Nyatane, saben metode bisa digunakake karo siji utawa sawetara, nyebabake kohesi akeh ing kelas (sing pancen kudune, amarga kelas kasebut kudu dadi kesatuan). Akibaté, nambah kohesi kelas kang ndadékaké kanggo abang ing ukuran kelas, lan, mesthi, nomer kelas mundhak. Iki ngganggu kanggo sawetara wong, amarga sampeyan kudu maca file kelas luwih akeh kanggo ndeleng carane tugas gedhe tartamtu bisa digunakake. Ing ndhuwur kabeh, saben kelas modul cilik sing kudu minimally related kanggo liyane. Isolasi iki nyuda jumlah owah-owahan sing kudu ditindakake nalika nambah logika tambahan ing kelas. saben cara dianggo karo siji utawa sawetara saka wong-wong mau, nyebabake akeh kohesi ing kelas (sing persis kaya sing kudune, amarga kelas kasebut kudu dadi siji). Akibaté, nambah kohesi kelas kang ndadékaké kanggo abang ing ukuran kelas, lan, mesthi, nomer kelas mundhak. Iki ngganggu kanggo sawetara wong, amarga sampeyan kudu maca file kelas luwih akeh kanggo ndeleng carane tugas gedhe tartamtu bisa digunakake. Ing ndhuwur kabeh, saben kelas modul cilik sing kudu minimally related kanggo liyane. Isolasi iki nyuda jumlah owah-owahan sing kudu ditindakake nalika nambah logika tambahan ing kelas. saben cara dianggo karo siji utawa sawetara saka wong-wong mau, nyebabake akeh kohesi ing kelas (sing persis kaya sing kudune, amarga kelas kasebut kudu dadi siji). Akibaté, nambah kohesi kelas kang ndadékaké kanggo abang ing ukuran kelas, lan, mesthi, nomer kelas mundhak. Iki ngganggu kanggo sawetara wong, amarga sampeyan kudu maca file kelas luwih akeh kanggo ndeleng carane tugas gedhe tartamtu bisa digunakake. Ing ndhuwur kabeh, saben kelas modul cilik sing kudu minimally related kanggo liyane. Isolasi iki nyuda jumlah owah-owahan sing kudu ditindakake nalika nambah logika tambahan ing kelas. s kohesi ndadékaké menyang abang ing ukuran kelas, lan, mesthi, nomer kelas mundhak. Iki ngganggu kanggo sawetara wong, amarga sampeyan kudu maca file kelas luwih akeh kanggo ndeleng carane tugas gedhe tartamtu bisa digunakake. Ing ndhuwur kabeh, saben kelas modul cilik sing kudu minimally related kanggo liyane. Isolasi iki nyuda jumlah owah-owahan sing kudu ditindakake nalika nambah logika tambahan ing kelas. s kohesi ndadékaké menyang abang ing ukuran kelas, lan, mesthi, nomer kelas mundhak. Iki ngganggu kanggo sawetara wong, amarga sampeyan kudu maca file kelas luwih akeh kanggo ndeleng carane tugas gedhe tartamtu bisa digunakake. Ing ndhuwur kabeh, saben kelas modul cilik sing kudu minimally related kanggo liyane. Isolasi iki nyuda jumlah owah-owahan sing kudu ditindakake nalika nambah logika tambahan ing kelas.
Obyek
Enkapsulasi
Ing kene kita bakal ngomong babagan prinsip OOP: enkapsulasi. Singidaken implementasine ora jumlah kanggo nggawe cara kanggo insulate variabel (thoughtlessly matesi akses liwat cara individu, getter, lan setters, kang ora apik, wiwit kabèh titik enkapsulasi wis ilang). Akses ndhelikake ditujokake kanggo mbentuk abstraksi, yaiku, kelas nyedhiyakake metode konkrit sing dienggo bareng sing digunakake kanggo nggarap data. Lan pangguna ora perlu ngerti persis carane kita nggarap data iki — bisa digunakake lan cukup.
Hukum Demeter
Kita uga bisa nimbang Hukum Demeter: minangka aturan cilik sing mbantu ngatur kerumitan ing tingkat kelas lan metode. Upaminipun kita duwe obyek Car , lan wis pamindhahan (Obyek arg1, Obyek arg2) cara. Miturut Hukum Demeter, cara iki diwatesi kanggo nelpon:
cara obyek Mobil dhewe (ing tembung liyane, obyek "iki");
cara obyek digawe ing cara pamindhahan ;
cara obyek liwati minangka argumen ( arg1 , arg2 );
cara obyek Car internal (maneh, "iki").
Ing tembung liyane, Hukum Demeter kaya apa sing bisa dikandhakake wong tuwa marang bocah: "sampeyan bisa ngomong karo kanca-kanca, nanging ora karo wong liyo".
Struktur data
Struktur data minangka kumpulan unsur-unsur sing ana gandhengane. Nalika nimbang obyek minangka struktur data, ana sakumpulan unsur data sing cara digunakake. Anane cara-cara kasebut kanthi implisit dianggep. Tegese struktur dhata yaiku obyek kang nduweni tujuwan kanggo nyimpen lan nggarap (ngolah) dhata kang disimpen. Bentenane utama saka obyek biasa yaiku obyek biasa minangka kumpulan metode sing ngoperasikake unsur data sing dianggep ana. Ngerti ta? Aspek utama obyek biasa yaiku metode. Variabel internal nggampangake operasi sing bener. Nanging ing struktur data, ana cara kanggo ndhukung karya sampeyan karo unsur data sing disimpen, sing paling penting ing kene. Salah sawijining jinis struktur data yaiku obyek transfer data (DTO). Iki kelas karo variabel umum lan ora ana cara (utawa mung cara kanggo maca / nulis) sing digunakake kanggo nransfer data nalika nggarap database, parsing pesen saka soket, etc.. Data ora biasane disimpen ing obyek kuwi kanggo wektu dawa. Iki meh langsung diowahi dadi jinis entitas sing dienggo aplikasi kita. Entitas, uga minangka struktur data, nanging tujuane kanggo melu logika bisnis ing macem-macem tingkat aplikasi. Tujuan saka DTO yaiku kanggo ngirim data menyang / saka aplikasi. Tuladha DTO: uga minangka struktur data, nanging tujuane kanggo melu logika bisnis ing macem-macem tingkat aplikasi. Tujuan saka DTO yaiku kanggo ngirim data menyang / saka aplikasi. Tuladha DTO: uga minangka struktur data, nanging tujuane kanggo melu logika bisnis ing macem-macem tingkat aplikasi. Tujuan saka DTO yaiku 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 cukup jelas, nanging ing kene kita sinau babagan eksistensi hibrida. Hibrida minangka obyek sing nduweni metode kanggo nangani logika penting, nyimpen unsur internal, lan uga kalebu metode accessor (get/set). Obyek kaya mengkono iku ora apik lan nggawe angel kanggo nambah cara anyar. Sampeyan kudu nyingkiri, amarga ora jelas apa gunane - nyimpen unsur utawa nglakokake logika?
Prinsip nggawe variabel
Ayo dipikirake sethithik babagan variabel. Luwih khusus, ayo dipikirake prinsip apa sing ditrapake nalika nggawe:
Saenipun, sampeyan kudu ngumumake lan miwiti variabel sadurunge nggunakake (aja nggawe siji lan lali babagan).
Yen bisa, wara-wara variabel minangka final kanggo nyegah nilai saka owah-owahan sawise initialization.
Aja lali babagan variabel counter, sing biasane digunakake ing sawetara jinis loop . Tegese, aja lali kanggo nul. Yen ora, kabeh logika kita bisa rusak.
Sampeyan kudu nyoba kanggo miwiti variabel ing konstruktor.
Yen ana pilihan antarane nggunakake obyek karo referensi utawa tanpa ( SomeObject anyar () ), milih kanggo tanpa, wiwit sawise obyek digunakake bakal dibusak sak siklus sampah sabanjuré lan sumber daya ora boroske.
Tansah umur variabel (jarak antarane nggawe variabel lan wektu pungkasan dirujuk) sabisa.
Inisialisasi variabel sing digunakake ing loop sadurunge loop, ora ing wiwitan metode sing ngemot loop.
Tansah miwiti karo orane katrangan paling winates lan nggedhekake mung yen perlu (sampeyan kudu nyoba kanggo nggawe variabel minangka lokal sabisa).
Gunakake saben variabel mung kanggo siji waé.
Ngindhari variabel kanthi tujuan sing didhelikake, contone pamisah variabel ing antarane rong tugas - iki tegese jinise ora cocog kanggo ngrampungake salah sawijining.
Metode
saka film "Star Wars: Episode III - Revenge of the Sith" (2005)
Ayo nerusake langsung menyang implementasine logika kita, yaiku metode.
Aturan # 1 - Compactness. Saenipun, cara ngirim ora ngluwihi 20 baris. Iki tegese yen cara umum "abuh" sacara signifikan, sampeyan kudu mikir babagan ngilangi logika lan mindhah menyang cara pribadi sing kapisah.
Aturan #2 — yen , liya , nalika lan statements liyane ngirim ora akeh nested pamblokiran: persil saka nesting Ngartekno nyuda readability saka kode. Saenipun, sampeyan ngirim ora luwih saka rong blok {} nested .
Lan iku uga seng di pengeni kanggo njaga kode ing pamblokiran iki kompak lan prasaja.
Aturan #3 - Cara kudu nindakake mung siji operasi. Sing, yen cara nindakake kabeh jinis logika Komplek, kita break menyang submethods. Akibaté, cara kasebut bakal dadi fasad sing tujuane nelpon kabeh operasi liyane kanthi urutan sing bener.
Nanging apa yen operasi katon banget prasaja kanggo sijine menyang cara kapisah? Bener, kadhangkala bisa uga kaya nembak meriam ing manuk pipit, nanging cara cilik menehi sawetara kaluwihan:
Pangerten kode sing luwih apik;
Metode cenderung dadi luwih rumit nalika pangembangan maju. Yen cara iku prasaja kanggo miwiti, banjur bakal dadi luwih gampang kanggo complicate sawijining fungsi;
Rincian implementasine didhelikake;
Gunakake maneh kode sing luwih gampang;
Kode luwih dipercaya.
Aturan stepdown - Kode kudu diwaca saka ndhuwur nganti ngisor: sing luwih ngisor sampeyan maca, luwih jero sampeyan nyelidiki logika. Lan kosok balene, sing luwih dhuwur sampeyan pindhah, cara liyane abstrak. Contone, statement ngalih rada non-kompak lan undesirable, nanging yen sampeyan ora bisa supaya nggunakake ngalih, sampeyan kudu nyoba kanggo mindhah minangka kurang sabisa, kanggo cara-tingkat paling.
Argumen metode - Apa nomer sing cocog? Saenipun, ora ana apa-apa :) Nanging apa pancene kedadeyan? Yen ngandika, sampeyan kudu nyoba kanggo duwe sawetara bantahan sabisa, amarga kurang ana, luwih gampang nggunakake cara lan luwih gampang kanggo nyoba. Yen ana keraguan, coba antisipasi kabeh skenario kanggo nggunakake metode kanthi akeh parameter input.
Kajaba iku, luwih apik kanggo misahake metode sing duwe gendera boolean minangka parameter input, amarga iki kabeh nuduhake manawa metode kasebut nindakake luwih saka siji operasi (yen bener, banjur tindakake siji, yen salah, banjur tindakake liyane). Nalika aku nulis ing ndhuwur, iki ora apik lan kudu dihindari yen bisa.
Yen cara wis nomer akeh paramèter input (ekstrim punika 7, nanging sampeyan kudu tenan miwiti mikir sawise 2-3), sawetara saka bantahan kudu diklompokaké menyang obyek kapisah.
Yen ana sawetara cara sing padha (overloaded), banjur paramèter sing padha kudu dilewati kanthi urutan sing padha: iki nambah keterbacaan lan kegunaan.
Nalika sampeyan ngliwati paramèter menyang cara, sampeyan kudu yakin manawa kabeh mau digunakake, yen ora, kenapa sampeyan butuh? Cut sembarang paramèter sing ora digunakake metu saka antarmuka lan rampung karo.
nyoba / nyekel ora katon apik banget ing alam, dadi apike kanggo mindhah menyang cara penengah kapisah (cara kanggo nangani pengecualian):
Aku ngandika bab duplikat kode ndhuwur, nanging mugi kula mbaleni sepisan maneh: Yen kita duwe sawetara cara karo kode bola, kita kudu pindhah menyang cara kapisah. Iki bakal nggawe metode lan kelas luwih kompak. Aja lali babagan aturan sing ngatur jeneng: rincian babagan cara jeneng kelas, antarmuka, metode, lan variabel kanthi bener bakal dibahas ing bagean sabanjure artikel kasebut. Nanging mung iku sing dakkarepake kanggo sampeyan dina iki.
GO TO FULL VERSION