Dekomposisi hierarkis
Anda tidak boleh langsung mulai menulis kelas untuk aplikasi Anda. Pertama perlu dirancang. Desain harus diakhiri dengan arsitektur yang bijaksana. Dan untuk mendapatkan arsitektur ini, Anda perlu menguraikan sistem secara konsisten.
Dekomposisi harus dilakukan secara hierarkis - pertama, sistem dibagi menjadi modul / subsistem fungsional besar yang menjelaskan operasinya dengan cara yang paling umum. Kemudian modul yang dihasilkan dianalisis lebih detail dan dibagi menjadi submodul atau objek.
Sebelum memilih objek, bagi sistem menjadi blok semantik dasar, setidaknya secara mental. Dalam aplikasi kecil, ini biasanya sangat mudah dilakukan: beberapa level hierarki sudah cukup, karena sistem pertama-tama dibagi menjadi subsistem / paket, dan paket dibagi menjadi beberapa kelas.
Ide ini tidak sepele seperti kelihatannya. Misalnya, apa inti dari "pola arsitektur" umum seperti Model-View-Controller (MVC)?
Ini semua tentang memisahkan presentasi dari logika bisnis . Pertama, setiap aplikasi pengguna dibagi menjadi dua modul - satu bertanggung jawab untuk mengimplementasikan logika bisnis itu sendiri (Model), dan yang kedua bertanggung jawab untuk berinteraksi dengan pengguna (Antarmuka Pengguna atau Tampilan).
Kemudian ternyata modul-modul tersebut entah bagaimana harus berinteraksi, untuk ini mereka menambahkan Pengontrol, yang tugasnya adalah mengelola interaksi modul. Juga di MVC versi seluler (klasik), pola Pengamat ditambahkan ke dalamnya sehingga Tampilan dapat menerima peristiwa dari model dan mengubah data yang ditampilkan secara real time.
Modul tingkat atas yang khas, diperoleh sebagai hasil dari pembagian pertama sistem menjadi komponen terbesar, tepatnya:
- Logika bisnis;
- Antarmuka pengguna;
- Basis data;
- Sistem pesan;
- Wadah objek.
Pembagian pertama biasanya membagi seluruh aplikasi menjadi 2-7 (maksimal 10 bagian). Jika kita memecahnya menjadi lebih banyak bagian, maka akan ada keinginan untuk mengelompokkannya, dan kita akan mendapatkan 2-7 modul tingkat atas lagi.
Dekomposisi fungsional
Pembagian ke dalam modul / subsistem paling baik dilakukan berdasarkan tugas yang diselesaikan oleh sistem . Tugas utama dibagi menjadi subtugas penyusunnya, yang dapat diselesaikan/dilakukan secara mandiri, secara independen satu sama lain.
Setiap modul harus bertanggung jawab untuk menyelesaikan beberapa subtugas dan menjalankan fungsinya yang sesuai . Selain tujuan fungsional, modul juga dicirikan oleh kumpulan data yang diperlukan untuk menjalankan fungsinya, yaitu:
Modul = Fungsi + Data yang diperlukan untuk menjalankannya.
Jika dekomposisi menjadi modul dilakukan dengan benar, maka interaksi dengan modul lain (bertanggung jawab untuk fungsi lain) akan minimal. Mungkin saja, tetapi ketidakhadirannya seharusnya tidak penting untuk modul Anda.
Modul bukanlah potongan kode yang sewenang-wenang, tetapi unit program (subprogram) terpisah yang bermakna secara fungsional dan lengkap yang memberikan solusi untuk tugas tertentu dan, idealnya, dapat bekerja secara mandiri atau di lingkungan lain dan digunakan kembali. Modul itu harus semacam "integritas yang mampu relatif mandiri dalam perilaku dan perkembangan." (Christopher Alexander)
Jadi, dekomposisi yang kompeten didasarkan, pertama-tama, pada analisis fungsi sistem dan data yang diperlukan untuk menjalankan fungsi-fungsi ini. Fungsi dalam hal ini bukanlah fungsi kelas dan modul, karena bukan objek. Jika Anda hanya memiliki beberapa kelas dalam modul, maka Anda berlebihan.
Konektivitas yang kuat dan lemah
Sangat penting untuk tidak berlebihan dengan modularisasi. Jika Anda memberikan aplikasi Spring monolitik kepada pemula dan memintanya untuk memecahnya menjadi modul, maka dia akan mengeluarkan setiap Spring Bean ke dalam modul terpisah dan menganggap bahwa pekerjaannya telah selesai. Tapi ternyata tidak.
Kriteria utama kualitas dekomposisi adalah bagaimana modul difokuskan pada penyelesaian tugas mereka dan mandiri.
Ini biasanya dirumuskan sebagai berikut: "Modul yang diperoleh sebagai hasil dekomposisi harus dikonjugasikan secara maksimal secara internal (kohesi internal tinggi) dan saling berhubungan minimal satu sama lain (kopling eksternal rendah)."
Kohesi Tinggi, kohesi tinggi atau "kohesi" dalam modul, menunjukkan bahwa modul difokuskan pada penyelesaian satu masalah sempit, dan tidak terlibat dalam melakukan fungsi heterogen atau tanggung jawab yang tidak terkait.
Kohesi mencirikan sejauh mana tugas-tugas yang dilakukan oleh modul terkait satu sama lain.
Konsekuensi dari Kohesi Tinggi adalah Prinsip Tanggung Jawab Tunggal - yang pertama dari lima prinsip SOLID , yang menurutnya setiap objek / modul hanya boleh memiliki satu tanggung jawab dan tidak boleh ada lebih dari satu alasan untuk mengubahnya.
Kopling Rendah , kopling longgar, berarti bahwa modul-modul yang membagi sistem harus, jika memungkinkan, independen atau digabungkan secara longgar satu sama lain. Mereka harus dapat berinteraksi, tetapi pada saat yang sama mengetahui sesedikit mungkin tentang satu sama lain.
Setiap modul tidak perlu mengetahui cara kerja modul lain, bahasa apa yang digunakan, dan cara kerjanya. Seringkali, untuk mengatur interaksi modul semacam itu, wadah tertentu digunakan, tempat modul ini dimuat.
Dengan desain yang tepat, jika Anda mengubah satu modul, Anda tidak perlu mengedit yang lain, atau perubahan ini akan minimal. Semakin longgar kopling, semakin mudah untuk menulis/memahami/memperpanjang/memperbaiki program.
Dipercayai bahwa modul yang dirancang dengan baik harus memiliki sifat-sifat berikut:
- Integritas dan kelengkapan fungsional - setiap modul mengimplementasikan satu fungsi, tetapi mengimplementasikannya dengan baik dan lengkap, modul secara mandiri melakukan serangkaian operasi lengkap untuk mengimplementasikan fungsinya.
- Satu input dan satu output - pada input, modul program menerima satu set data awal tertentu, melakukan pemrosesan yang berarti dan mengembalikan satu set data hasil, yaitu, prinsip IPO standar diterapkan - input -\u003e proses -\u003e keluaran.
- Kemandirian logis - hasil kerja modul program hanya bergantung pada data awal, tetapi tidak bergantung pada kerja modul lain.
- Tautan informasi yang lemah dengan modul lain - pertukaran informasi antar modul harus diminimalkan jika memungkinkan.
Sangat sulit bagi seorang pemula untuk memahami cara lebih mengurangi konektivitas modul. Sebagian pengetahuan ini datang dari pengalaman, sebagian lagi setelah membaca buku pintar. Tetapi yang terbaik adalah menganalisis arsitektur aplikasi yang ada.
Komposisi bukannya warisan
Dekomposisi yang kompeten adalah sejenis seni dan tugas yang sulit bagi sebagian besar programmer. Kesederhanaan menipu di sini, dan kesalahan mahal harganya.
Kebetulan modul khusus sangat digabungkan satu sama lain dan tidak dapat dikembangkan secara mandiri. Atau tidak jelas fungsi apa yang menjadi tanggung jawab masing-masing. Jika Anda mengalami masalah serupa, kemungkinan besar partisi menjadi modul dilakukan dengan tidak benar.
Harus selalu jelas peran apa yang dimainkan setiap modul . Kriteria paling andal bahwa dekomposisi dilakukan dengan benar adalah jika modul adalah subrutin independen dan berharga yang dapat digunakan secara terpisah dari aplikasi lainnya (dan karenanya dapat digunakan kembali).
Saat menguraikan sistem, sebaiknya periksa kualitasnya dengan bertanya pada diri sendiri pertanyaan: "Tugas apa yang dilakukan setiap modul?", "Seberapa mudah modul diuji?", "Apakah mungkin menggunakan modul sendiri atau di lingkungan lain?" mempengaruhi orang lain?"
Anda perlu mencoba untuk mempertahankan modul-modul tersebut seotonom mungkin . Seperti disebutkan sebelumnya, ini adalah parameter kunci untuk dekomposisi yang tepat . Oleh karena itu, harus dilakukan sedemikian rupa sehingga modul-modul pada awalnya tidak terlalu bergantung satu sama lain. Jika Anda berhasil, maka Anda hebat.
Jika tidak, maka semuanya juga tidak hilang di sini. Ada sejumlah teknik dan pola khusus yang memungkinkan Anda untuk lebih meminimalkan dan melemahkan hubungan antar subsistem. Misalnya, dalam kasus MVC, pola Pengamat digunakan untuk tujuan ini, tetapi solusi lain dimungkinkan.
Dapat dikatakan bahwa teknik decoupling merupakan "alat arsitek" utama. Anda hanya perlu memahami bahwa kita berbicara tentang semua subsistem dan perlu untuk melemahkan koneksi di semua level hierarki , yaitu, tidak hanya antar kelas, tetapi juga antar modul di setiap level hierarki.