Dekomposisi hirarkis
Sampeyan ora kudu miwiti nulis kelas kanggo aplikasi sampeyan langsung. Pisanan kudu dirancang. Desain kudu diakhiri karo arsitektur sing wicaksana. Lan kanggo njaluk arsitektur iki, sampeyan kudu terus-terusan decompose sistem.
Dekomposisi kudu ditindakake kanthi hierarki - pisanan, sistem kasebut dipérang dadi modul / subsistem fungsional sing gedhé sing njlèntrèhaké operasi ing wangun sing paling umum. Banjur modul sing diasilake dianalisis kanthi luwih rinci lan dibagi dadi submodul utawa obyek.
Sadurunge milih obyek, dibagi sistem dadi blok semantik dhasar, paling ora mental. Ing aplikasi cilik, iki biasane gampang banget: sawetara tingkat hierarki cukup cukup, amarga sistem kasebut pisanan dipérang dadi subsistem / paket, lan paket dipérang dadi kelas.
Ide iki ora sepele kaya sing katon. Contone, apa inti saka "pola arsitektur" umum minangka Model-View-Controller (MVC)?
Iku kabeh babagan misahake presentasi saka logika bisnis . Pisanan, aplikasi pangguna apa wae dipérang dadi rong modul - siji tanggung jawab kanggo ngetrapake logika bisnis dhewe (Model), lan sing kapindho tanggung jawab kanggo sesambungan karo pangguna (Antarmuka Pangguna utawa Tampilan).
Banjur dadi metu sing modul kudu piye wae sesambungan, kanggo iki nambah Controller, kang tugas kanggo ngatur interaksi modul. Uga ing versi seluler (klasik) MVC, pola Observer ditambahake supaya Tampilan bisa nampa acara saka model lan ngganti data sing ditampilake ing wektu nyata.
Modul tingkat ndhuwur sing khas, sing dipikolehi minangka asil saka divisi pisanan sistem dadi komponen paling gedhe, yaiku:
- Logika bisnis;
- Antarmuka pangguna;
- Database;
- Sistem pesen;
- Wadhah obyek.
Pemisahan pisanan biasane dibagi kabeh aplikasi dadi 2-7 (maksimal 10 bagean). Yen dipecah dadi luwih akeh, mula bakal ana kepinginan kanggo nglumpukake, lan kita bakal entuk maneh 2-7 modul tingkat paling dhuwur.
Dekomposisi fungsional
Divisi menyang modul / subsistem paling apik ditindakake adhedhasar tugas sing ditindakake sistem . Tugas utama dipérang dadi subtugas konstituen, sing bisa ditanggulangi / ditindakake kanthi mandiri, kanthi mandiri.
Saben modul kudu tanggung jawab kanggo ngrampungake sawetara subtugas lan nindakake fungsi sing cocog . Saliyane tujuan fungsional, modul uga ditondoi kanthi sakumpulan data sing dibutuhake kanggo nindakake fungsi kasebut, yaiku:
Modul = Fungsi + Data sing dibutuhake kanggo nglakokake.
Yen dekomposisi dadi modul wis rampung kanthi bener, mula interaksi karo modul liyane (tanggung jawab kanggo fungsi liyane) bakal minimal. Bisa uga, nanging ora ana sing penting kanggo modul sampeyan.
Modul ora minangka potongan kode sing kasepakatan, nanging minangka unit program (subprogram) sing nduweni fungsi lan lengkap kanthi fungsi sing nyedhiyakake solusi kanggo tugas tartamtu lan, saenipun, bisa digunakake kanthi mandiri utawa ing lingkungan liyane lan bisa digunakake maneh. Modul kasebut kudu dadi jinis "integritas sing nduweni kamardikan relatif ing prilaku lan pangembangan." (Christopher Alexander)
Mangkono, dekomposisi sing kompeten adhedhasar, pisanan, ing analisis fungsi sistem lan data sing dibutuhake kanggo nindakake fungsi kasebut. Fungsi ing kasus iki ora fungsi kelas lan modul, amarga padha ora obyek. Yen sampeyan duwe mung saperangan saka kelas ing modul, banjur overdid iku.
Konektivitas sing kuwat lan lemah
Penting banget supaya ora overdo karo modularisasi. Yen sampeyan menehi pamula aplikasi Spring monolithic lan takon marang break menyang modul, banjur bakal njupuk metu saben Spring Bean menyang modul kapisah lan nimbang sing karya wis rampung. Nanging ora.
Kriteria utama kanggo kualitas dekomposisi yaiku kepiye modul fokus kanggo ngrampungake tugas lan mandiri.
Iki biasane dirumusake kaya ing ngisor iki: "Modul sing dipikolehi minangka asil saka dekomposisi kudu maksimal konjugasi internal (kohesi internal dhuwur) lan minimally interconnected karo saben liyane (kopling eksternal kurang)."
Kohesi dhuwur, kohesi dhuwur utawa "kohesi" ing modul kasebut, nuduhake yen modul kasebut fokus kanggo ngrampungake masalah sing sempit, lan ora nindakake fungsi sing heterogen utawa tanggung jawab sing ora ana gandhengane.
Kohesi nggambaraken tingkat tugas sing ditindakake dening modul sing ana gegayutane.
Konsekuensi saka Kohesi Dhuwur yaiku Prinsip Tanggung Jawab Tunggal - sing pertama saka limang prinsip SOLID , miturut obyek / modul apa wae kudu mung siji tanggung jawab lan ora ana luwih saka siji alasan kanggo ngganti.
Low Coupling , coupling longgar, tegese modul sing dibagi sistem kudu, yen bisa, independen utawa longgar gegandhengan karo saben liyane. Dheweke kudu bisa sesambungan, nanging ing wektu sing padha ngerti sethithik babagan saben liyane.
Saben modul ora perlu ngerti cara kerja modul liyane, basa apa sing ditulis, lan cara kerjane. Asring, kanggo ngatur interaksi modul kasebut, wadhah tartamtu digunakake, ing ngendi modul kasebut dimuat.
Kanthi desain sing tepat, yen sampeyan ngganti siji modul, sampeyan ora kudu ngowahi liyane, utawa owah-owahan iki bakal minimal. Sing looser kopling, luwih gampang kanggo nulis / ngerti / ngluwihi / ndandani program.
Dipercaya manawa modul sing dirancang kanthi apik kudu nduweni sifat ing ngisor iki:
- Integritas lan kelengkapan fungsional - saben modul nindakake siji fungsi, nanging nindakake kanthi apik lan lengkap, modul kasebut kanthi mandiri nindakake operasi lengkap kanggo ngleksanakake fungsine.
- Siji input lan siji output - ing input, modul program nampa set data awal tartamtu, nindakake pangolahan sing migunani lan ngasilake siji set data asil, yaiku, prinsip IPO standar dileksanakake - input -\u003e proses -\u003e output.
- Kamardikan logis - asil karya modul program mung gumantung ing data awal, nanging ora gumantung ing karya modul liyane.
- Link informasi sing lemah karo modul liyane - ijol-ijolan informasi antarane modul kudu diminimalisir yen bisa.
Pamula angel banget ngerti carane nyuda panyambungan modul luwih akeh. Sebagéyan kawruh iki teka karo pengalaman, sebagéyan - sawise maca buku pinter. Nanging paling apik kanggo nganalisa arsitektur aplikasi sing wis ana.
Komposisi tinimbang warisan
Dekomposisi sing kompeten minangka jinis seni lan tugas sing angel kanggo umume programer. Kesederhanaan ngapusi ing kene, lan kesalahan larang regane.
Mengkono modul darmabakti banget gegandhengan karo saben liyane lan padha ora bisa dikembangaké independen. Utawa ora cetha apa fungsi saben wong tanggung jawab kanggo. Yen sampeyan nemoni masalah sing padha, kemungkinan pemisahan dadi modul ora ditindakake kanthi bener.
Sampeyan kudu jelas apa peran saben modul . Kriteria sing paling dipercaya yen dekomposisi wis rampung kanthi bener yaiku yen modul kasebut minangka subrutin independen lan berharga sing bisa digunakake kanthi ora ana ing aplikasi liyane (lan mulane bisa digunakake maneh).
Nalika decomposing sistem, iku seng di pengeni kanggo mriksa kualitas kanthi takon dhewe pitakonan: "Apa tugas saben modul nindakake?", "Sepira gampang modul kanggo nyoba?", "Apa bisa nggunakake modul dhewe. utawa ing lingkungan liyane?" mengaruhi wong liya?"
Sampeyan kudu nyoba kanggo njaga modul minangka otonom sabisa . Kaya sing wis kasebut sadurunge, iki minangka parameter kunci kanggo dekomposisi sing tepat . Mulane, kudu ditindakake kanthi cara supaya modul-modul kasebut wiwitane gumantung banget. Yen sampeyan sukses, sampeyan pancen hebat.
Yen ora, kabeh ora bakal ilang ing kene. Ana sawetara teknik lan pola khusus sing ngidini sampeyan luwih nyilikake lan ngurangi hubungan antarane subsistem. Contone, ing kasus MVC, pola Observer digunakake kanggo tujuan iki, nanging solusi liyane bisa uga.
Bisa diarani yen teknik kanggo decoupling minangka "toolkit arsitek" utama. Sampeyan mung perlu kanggo mangerteni yen kita ngomong babagan kabeh subsistem lan perlu kanggo ngurangi sambungan ing kabeh tingkat hirarki , yaiku, ora mung antarane kelas, nanging uga antarane modul ing saben tingkat hirarkis.
GO TO FULL VERSION