Posting ini terakhir diedit oleh Summer pada 2017-9-27 15:32
Artikel ini adalah cerita pendek yang meniru Tanya Jawab, dan penulis menggunakan gaya lucu untuk menganalisis secara singkat pekerjaan yang dilakukan arsitek: Saya ingin menjadi arsitek perangkat lunak. Ini adalah pilihan yang bagus untuk pengembang perangkat lunak muda. Saya ingin memimpin tim dan membuat keputusan penting tentang database dan kerangka kerja, server web, dll. Oh, maka Anda tidak ingin menjadi arsitek perangkat lunak sama sekali. Tentu saja saya ingin menjadi pembuat keputusan penting. Tidak apa-apa, tetapi Anda tidak memasukkan keputusan penting dalam daftar Anda, yang merupakan keputusan yang tidak relevan. Apa maksudmu? Apakah Anda mengatakan bahwa database bukanlah keputusan penting, tahukah Anda berapa banyak yang kita belanjakan untuk itu? Mungkin harganya terlalu mahal. Namun, database bukanlah salah satu keputusan penting. Bagaimana Anda bisa mengatakan itu? Basis data adalah inti dari sistem, di mana semua data disistematisasikan, diklasifikasikan, diindeks, dan diakses. Tanpa database, tidak akan ada sistem. Basis data hanyalah perangkat IO yang kebetulan menyediakan beberapa alat yang berguna untuk klasifikasi, kueri, dan pelaporan informasi, tetapi ini hanya fungsi tambahan dari arsitektur sistem. Bantuan? Ini keterlaluan. Itu benar, itu tambahan. Aturan bisnis sistem mungkin dapat memanfaatkan beberapa alat ini, tetapi alat tersebut tidak melekat pada aturan bisnis yang sesuai. Jika perlu, Anda dapat mengganti yang ada dengan alat yang berbeda; Dan aturan bisnis tidak akan berubah. Ya, tapi itu harus dikodekan ulang, karena alat-alat ini digunakan dalam database aslinya. Itu masalahmu. Apa maksudmu? Masalah Anda adalah bahwa Anda berpikir aturan bisnis bergantung pada alat database, tetapi sebenarnya tidak. Atau setidaknya, seharusnya tidak seperti ini sampai arsitektur yang baik disediakan. Itu hanya gila. Bagaimana Anda membuat aturan bisnis yang tidak menggunakan alat tersebut? Saya tidak mengatakan mereka tidak menggunakan alat database, tetapi mereka tidak bergantung padanya. Aturan bisnis tidak perlu mengetahui database mana yang Anda gunakan. Jadi bagaimana Anda mendapatkan aturan bisnis tanpa mengetahui alat apa yang harus digunakan? Balikkan dependensi sehingga database bergantung pada aturan bisnis. Pastikan bahwa aturan bisnis tidak bergantung pada database. Anda berbicara omong kosong. Sebaliknya, saya menggunakan bahasa arsitektur perangkat lunak. Ini adalah prinsip inversi ketergantungan: standar tingkat rendah harus bergantung pada standar tingkat tinggi. Omong kosong! Kriteria tingkat tinggi (dengan asumsi mengacu pada aturan bisnis) Memanggil kriteria tingkat rendah (dengan asumsi mengacu pada database). Oleh karena itu, kriteria tingkat tinggi akan bergantung pada kriteria tingkat rendah sesuai dengan prinsip bahwa penelepon bergantung pada penerima telepon. Semua orang tahu ini! Ini benar saat runtime. Tetapi saat mengkompilasi, yang kita inginkan adalah inversi dependensi. Kode sumber pedoman tingkat tinggi tidak boleh menyebutkan kode sumber pedoman tingkat rendah. Ayolah! Bagaimana Anda bisa menelepon tanpa menyebutkannya? Tentu saja tidak masalah. Itulah yang terlibat dalam berorientasi objek. Orientasi objek adalah tentang pembuatan model dunia nyata, menggabungkan data, fungsionalitas, dan objek yang kohesif. Ini tentang mengatur kode ke dalam struktur yang intuitif. Itu yang mereka katakan? Seperti yang kita semua tahu, ini adalah kebenaran yang jelas. Ya, namun, ketika menggunakan pedoman berorientasi objek, memang dimungkinkan untuk memanggil tanpa menyebutkannya. Nah, bagaimana cara melakukannya? Dalam desain berorientasi objek, objek saling mengirim pesan. Itu benar, tentu saja. Saat pengirim mengirim pesan, ia tidak mengetahui jenis penerimanya. Itu tergantung pada bahasa yang digunakan. Di Jawa, pengirim setidaknya mengetahui jenis dasar penerima. Di Ruby, pengirim setidaknya tahu bahwa penerima mampu menangani pesan yang diterima. Itu benar. Namun, bagaimanapun, pengirim tidak mengetahui jenis penerima tertentu. Itu benar, yah, itu benar. Oleh karena itu, pengirim dapat merancang penerima untuk melakukan suatu fungsi tanpa menyebutkan jenis penerima tertentu. Itu benar, itu benar. Saya mengerti. Namun, pengirim tetap bergantung pada penerima. Ini benar saat runtime. Namun, berbeda ketika dikompilasi. Kode sumber pengirim tidak menyebutkan atau bergantung pada kode sumber penerima. Faktanya, kode sumber penerima tergantung pada kode sumber pengirim. Tidak mau! Pengirim masih bergantung pada kelas yang dikirimnya. Mungkin dari beberapa kode sumber, itu akan lebih jelas. Paragraf berikut ditulis dalam bahasa Jawa. Pertama adalah pengirim: pengirim paket; kelas publik Pengirim { penerima Penerima pribadi; publik Pengirim (Penerima r) { penerima = r; } public void doSomething () { receiver.receiveThis (); } antarmuka publik Penerima { void receiveThis (); } }Berikut penerimanya: penerima paket; mengimpor pengirim. Pengirim; public class SpecificReceiver mengimplementasikan Sender.Receiver { public void receiveThis () { //melakukan sesuatu yang menarik. } }Catatan: Penerima bergantung pada pengirim, Penerima Spesifik bergantung pada pengirim, dan tidak ada informasi terkait penerima dalam pengirim. Ya, tapi Anda berbohong, Anda menempatkan antarmuka penerima di kelas pengirim. Anda mulai mengerti. Apa yang Anda tahu? Tentu saja, itu adalah prinsip arsitektur. Pengirim memiliki antarmuka yang harus diterapkan penerima. Jika itu berarti saya harus menggunakan kelas bersarang, maka ...... Kelas bersarang hanyalah salah satu sarana untuk mencapai tujuan, ada cara lain. Nah, tunggu sebentar. Apa hubungannya ini dengan database? Kami mulai berbicara tentang database. Mari kita lihat kodenya sedikit lebih lanjut. Yang pertama adalah aturan bisnis sederhana: paket bisnisAturan; entitas impor. Sesuatu; kelas publik BusinessRule { gateway BusinessRuleGateway privat; public BusinessRule (gateway BusinessRuleGateway) { this.gateway = gateway; } public void execute (String id) { gateway.startTransaction (); Sesuatu benda = gateway.getSomething (id); thing.makeChanges (); gateway.saveSomething (benda); gateway.endTransaction (); } }Aturan bisnis tidak memiliki banyak bobot. Ini hanya salah satu contoh. Mungkin ada lebih banyak kelas seperti itu yang menerapkan banyak aturan bisnis yang berbeda. Oke, jadi apa sebenarnya Gateway itu? Ini menyediakan semua metode akses data melalui aturan bisnis. Terapkan sebagai berikut: paket bisnisAturan; entitas impor. Sesuatu; antarmuka publik BusinessRuleGateway { Sesuatu getSomething (id string); batal startTransaction (); void saveSomething (Sesuatu); void endTransaction (); }Catatan: Ini ada di businessRules. Oke, apa itu kelas Sesuatu? Ini mewakili objek bisnis sederhana. Saya memasukkannya ke dalam entitas. entitas paket; public class Something { public void makeChanges () { //... } }Pada akhirnya implementasi BusinessRuleGateway, kelas ini mengetahui database yang sebenarnya: database paket; impor businessRules.BusinessRuleGateway; entitas impor. Sesuatu; public MySqlBusinessRuleGateway mengimplementasikan BusinessRuleGateway { public Something getSomething (String id) { // gunakan MySql untuk mendapatkan sesuatu. } public void startTransaction () { // start MySql transaction } public void saveSomething (Sesuatu hal) { // simpan benda di MySql } public void endTransaction () { // end Transaksi MySql } }Selain itu, perhatikan bahwa aturan bisnis memanggil database saat runtime; Namun, pada waktu kompilasi, database melibatkan dan bergantung pada businessRules. Yah, saya pikir saya mengerti. Anda hanya menggunakan polimorfisme untuk menyembunyikan fakta bahwa database diterapkan dari aturan bisnis. Namun, antarmuka masih diperlukan untuk menyediakan semua alat database ke aturan bisnis. Tidak, tidak sama sekali. Kami belum berusaha menyediakan alat database untuk aturan bisnis. Sebaliknya, mereka menggunakan aturan bisnis untuk membuat antarmuka untuk apa yang mereka butuhkan. Menerapkan antarmuka ini memungkinkan Anda memanggil alat yang tepat. Ya, tetapi jika Anda perlu menggunakan setiap alat untuk semua aturan bisnis, maka letakkan saja alat tersebut di antarmuka gateway. Ah, kurasa kamu masih tidak mengerti. Pahami apa? Ini sudah jelas. Setiap aturan bisnis hanya mendefinisikan satu antarmuka untuk alat akses data yang dibutuhkannya. Tunggu sebentar, bagaimana menurutmu? Ini adalah Prinsip Pemisahan Antarmuka. Setiap kelas aturan bisnis hanya menggunakan fasilitas database tertentu. Oleh karena itu, antarmuka yang disediakan oleh setiap aturan bisnis hanya dapat mengakses fasilitas yang sesuai. Namun, ini berarti bahwa ada banyak antarmuka dan banyak kelas implementasi kecil yang memanggil kelas database lainnya. Hebat, Anda mulai mengerti. Tapi itu terlalu berantakan dan membuang-buang waktu. Mengapa melakukan ini? Ini terorganisir dan menghemat waktu. Yuk, dapatkan banyak kode demi kode. Sebaliknya, keputusan yang tidak relevan dapat ditunda melalui keputusan arsitektur yang penting. Apa maksudnya? Saya ingat pada awalnya, Anda mengatakan Anda ingin menjadi arsitek perangkat lunak, bukan? Anda ingin membuat semua keputusan yang benar-benar penting. Ya, itulah yang saya pikirkan. Anda ingin membuat keputusan tentang database, webserver, dan kerangka kerja, bukan? Ya, Anda mengatakan bahwa semua itu tidak penting. Hanya konten yang tidak relevan. Itu benar. Itu saja. Keputusan penting yang dibuat oleh arsitek perangkat lunak adalah keputusan yang memungkinkan Anda membuat keputusan tentang database, server web, dan kerangka kerja. Tetapi Anda harus memutuskan mana yang lebih dulu! Tidak, itu tidak berhasil. Faktanya, ini dapat diputuskan nanti dalam siklus pengembangan, ketika informasinya lebih melimpah. Ini adalah bencana jika arsitek mengidentifikasi kerangka kerja terlebih dahulu hanya untuk menemukan bahwa mereka tidak memberikan kinerja yang diperlukan atau memperkenalkan kendala yang tidak dapat ditoleransi. Hanya ketika arsitek memutuskan untuk menunda keputusan, dia akan membuat keputusan ketika informasinya cukup; Tim yang tidak menggunakan perangkat dan kerangka kerja IO yang lambat dan intensif sumber daya dapat membuat lingkungan pengujian yang cepat dan ringan atas kebijaksanaan arsitek. Hanya arsiteknya yang peduli tentang apa yang benar-benar penting dan menunda mereka yang tidak, dan tim seperti itu adalah yang beruntung. Omong kosong, saya tidak mengerti apa yang Anda maksud sama sekali. Nah, perhatikan baik-baik artikel ini, jika tidak, Anda harus menunggu 10 tahun lagi untuk mengetahuinya.
| 
Diposting pada 27/09/2017 15.29.46
|
|
|
Diposting pada 28/09/2017 15.00.37
|
Tuan tanah|
Diposting pada 29/09/2017 08.34.23
|
Diposting pada 27/11/2018 11.12.17
|
