Penguraian perisian yang betul

Penguraian hierarki

Anda tidak boleh mula menulis kelas untuk permohonan anda dengan segera. Mula-mula ia perlu direka bentuk. Reka bentuk harus diakhiri dengan seni bina yang bernas. Dan untuk mendapatkan seni bina ini, anda perlu menguraikan sistem secara konsisten.

Penguraian mesti dilakukan secara hierarki - pertama, sistem dibahagikan kepada modul / subsistem berfungsi besar yang menerangkan operasinya dalam bentuk yang paling umum. Kemudian modul yang terhasil dianalisis dengan lebih terperinci dan dibahagikan kepada submodul atau objek.

Sebelum memilih objek, bahagikan sistem kepada blok semantik asas, sekurang-kurangnya secara mental. Dalam aplikasi kecil, ini biasanya sangat mudah dilakukan: beberapa tahap hierarki adalah cukup, kerana sistem mula-mula dibahagikan kepada subsistem / pakej, dan pakej dibahagikan kepada kelas.

Idea ini tidaklah remeh seperti yang disangkakan. Sebagai contoh, apakah intipati "corak seni bina" biasa seperti Model-View-Controller (MVC)?

Ini semua tentang memisahkan pembentangan daripada logik perniagaan . Pertama, mana-mana aplikasi pengguna dibahagikan kepada dua modul - satu bertanggungjawab untuk melaksanakan logik perniagaan itu sendiri (Model), dan yang kedua bertanggungjawab untuk berinteraksi dengan pengguna (Antara Muka Pengguna atau Paparan).

Kemudian ternyata modul mesti berinteraksi, untuk ini mereka menambah Pengawal, yang tugasnya adalah untuk menguruskan interaksi modul. Juga dalam versi mudah alih (klasik) MVC, corak Pemerhati ditambahkan padanya supaya Paparan boleh menerima peristiwa daripada model dan menukar data yang dipaparkan dalam masa nyata.

Modul peringkat atas biasa, yang diperoleh hasil daripada pembahagian pertama sistem kepada komponen terbesar, adalah tepat:

• Logik perniagaan;
• Antaramuka pengguna;
• Pangkalan data;
• Sistem pemesejan;
• Bekas objek.

Pembahagian pertama biasanya membahagikan keseluruhan aplikasi kepada 2-7 (maksimum 10 bahagian). Jika kita memecahkannya kepada lebih banyak bahagian, maka akan ada keinginan untuk mengumpulkannya, dan kita akan sekali lagi mendapat 2-7 modul peringkat atas.

Penguraian berfungsi

Pembahagian kepada modul / subsistem paling baik dilakukan berdasarkan tugasan yang diselesaikan oleh sistem . Tugas utama dibahagikan kepada subtugas konstituennya, yang boleh diselesaikan/dilaksanakan secara autonomi, secara bebas antara satu sama lain.

Setiap modul harus bertanggungjawab untuk menyelesaikan beberapa subtugas dan melaksanakan fungsinya yang sepadan . Sebagai tambahan kepada tujuan fungsian, modul juga dicirikan oleh satu set data yang diperlukan untuk melaksanakan fungsinya, iaitu:

Modul = Fungsi + Data yang diperlukan untuk melaksanakannya.

Jika penguraian ke dalam modul dilakukan dengan betul, maka interaksi dengan modul lain (bertanggungjawab untuk fungsi lain) akan menjadi minimum. Ia mungkin, tetapi ketiadaannya tidak sepatutnya kritikal untuk modul anda.

Modul bukanlah sekeping kod yang sewenang-wenangnya, tetapi unit program (subprogram) yang bermakna secara fungsional dan lengkap yang menyediakan penyelesaian kepada tugas tertentu dan, idealnya, boleh berfungsi secara bebas atau dalam persekitaran lain dan digunakan semula. Modul itu haruslah sejenis "integriti yang mampu kebebasan relatif dalam tingkah laku dan pembangunan." (Christopher Alexander)

Oleh itu, penguraian yang cekap adalah berdasarkan, pertama sekali, pada analisis fungsi sistem dan data yang diperlukan untuk melaksanakan fungsi ini. Fungsi dalam kes ini bukan fungsi kelas dan modul, kerana ia bukan objek. Jika anda hanya mempunyai beberapa kelas dalam satu modul, maka anda telah melampauinya.

Sambungan yang kuat dan lemah

Adalah sangat penting untuk tidak keterlaluan dengan modularisasi. Jika anda memberi seorang pemula aplikasi Spring monolitik dan memintanya untuk memecahkannya ke dalam modul, maka dia akan mengeluarkan setiap Spring Bean ke dalam modul yang berasingan dan menganggap bahawa kerjanya telah selesai. Tetapi tidak.

Kriteria utama untuk kualiti penguraian ialah bagaimana modul memberi tumpuan kepada menyelesaikan tugas mereka dan bebas.

Ini biasanya dirumuskan seperti berikut: "Modul yang diperoleh hasil daripada penguraian hendaklah dikonjugasikan secara maksimum secara dalaman (kesepaduan dalaman yang tinggi) dan saling berkaitan secara minimum antara satu sama lain (gandingan luaran yang rendah)."

Kesepaduan Tinggi, kesepaduan tinggi atau "kesepaduan" dalam modul, menunjukkan bahawa modul tertumpu pada penyelesaian satu masalah sempit, dan tidak terlibat dalam melaksanakan fungsi heterogen atau tanggungjawab yang tidak berkaitan.

Kesepaduan mencirikan sejauh mana tugas yang dilaksanakan oleh modul berkaitan antara satu sama lain.

Akibat daripada Kesepaduan Tinggi ialah Prinsip Tanggungjawab Tunggal - yang pertama daripada lima prinsip SOLID , mengikut mana mana-mana objek / modul hanya mempunyai satu tanggungjawab dan tidak boleh ada lebih daripada satu sebab untuk mengubahnya.

Gandingan Rendah , gandingan longgar, bermakna modul di mana sistem dibahagikan hendaklah, jika boleh, bebas atau berganding longgar antara satu sama lain. Mereka sepatutnya boleh berinteraksi, tetapi pada masa yang sama tahu sesedikit mungkin tentang satu sama lain.

Setiap modul tidak perlu mengetahui cara modul lain berfungsi, bahasa apa ia ditulis dan cara ia berfungsi. Selalunya, untuk mengatur interaksi modul sedemikian, bekas tertentu digunakan, di mana modul ini dimuatkan.

Dengan reka bentuk yang betul, jika anda menukar satu modul, anda tidak perlu mengedit yang lain, atau perubahan ini akan menjadi minimum. Lebih longgar gandingan, lebih mudah untuk menulis/memahami/melanjutkan/membaiki atur cara.

Adalah dipercayai bahawa modul yang direka dengan baik harus mempunyai sifat berikut:

• Integriti dan kesempurnaan fungsi - setiap modul melaksanakan satu fungsi, tetapi melaksanakannya dengan baik dan lengkap, modul secara bebas melaksanakan satu set operasi penuh untuk melaksanakan fungsinya.
• Satu input dan satu output - pada input, modul program menerima set data awal tertentu, melakukan pemprosesan yang bermakna dan mengembalikan satu set data hasil, iaitu prinsip IPO standard dilaksanakan - input -\u003e proses -\u003e pengeluaran.
• Kebebasan logik - hasil kerja modul program hanya bergantung pada data awal, tetapi tidak bergantung pada kerja modul lain.
• Pautan maklumat yang lemah dengan modul lain - pertukaran maklumat antara modul harus diminimumkan jika boleh.

Amat sukar bagi seorang pemula untuk memahami cara mengurangkan ketersambungan modul dengan lebih banyak lagi. Sebahagian pengetahuan ini datang dengan pengalaman, sebahagiannya - selepas membaca buku pintar. Tetapi yang terbaik adalah menganalisis seni bina aplikasi sedia ada.

Komposisi bukannya warisan

Penguraian yang cekap adalah sejenis seni dan tugas yang sukar untuk kebanyakan pengaturcara. Kesederhanaan adalah menipu di sini, dan kesilapan adalah mahal.

Ia berlaku bahawa modul khusus digandingkan dengan kuat antara satu sama lain dan tidak boleh dibangunkan secara bebas. Atau tidak jelas apa fungsi masing-masing bertanggungjawab. Jika anda menghadapi masalah yang sama, kemungkinan besar pembahagian ke dalam modul telah dilakukan secara tidak betul.

Ia harus sentiasa jelas peranan yang dimainkan oleh setiap modul . Kriteria yang paling boleh dipercayai bahawa penguraian dilakukan dengan betul adalah jika modul adalah subrutin bebas dan berharga yang boleh digunakan secara berasingan daripada aplikasi yang lain (dan oleh itu boleh digunakan semula).

Apabila menguraikan sistem, adalah wajar untuk menyemak kualitinya dengan bertanya kepada diri sendiri soalan: "Apakah tugasan yang dilakukan oleh setiap modul?", "Seberapa mudah modul untuk diuji?", "Adakah mungkin untuk menggunakan modul itu sendiri. atau dalam persekitaran lain?" mempengaruhi orang lain?"

Anda perlu cuba mengekalkan modul sebagai autonomi yang mungkin . Seperti yang dinyatakan sebelum ini, ini ialah parameter utama untuk penguraian yang betul . Oleh itu, ia mesti dijalankan sedemikian rupa sehingga modul pada mulanya lemah bergantung antara satu sama lain. Jika anda berjaya, maka anda hebat.

Jika tidak, maka semuanya tidak hilang di sini juga. Terdapat beberapa teknik dan corak khas yang membolehkan anda meminimumkan dan melemahkan lagi hubungan antara subsistem. Sebagai contoh, dalam kes MVC, corak Pemerhati telah digunakan untuk tujuan ini, tetapi penyelesaian lain mungkin.

Ia boleh dikatakan bahawa teknik untuk decoupling merupakan "kit alat arkitek" utama. Ia hanya perlu untuk memahami bahawa kita bercakap tentang semua subsistem dan adalah perlu untuk melemahkan sambungan pada semua peringkat hierarki , iaitu, bukan sahaja antara kelas, tetapi juga antara modul pada setiap peringkat hierarki.