Kata pengantar
Sebagai pembuat kode yang terlibat dalam pengembangan Java, pentingnya musim semi terbukti dengan sendirinya. Anda mungkin berurusan dengan kerangka kerja musim semi setiap hari. Spring sama bernama, membawa kenyamanan seperti musim semi untuk pengembangan aplikasi Java. Musim semi dapat dikatakan sebagai fondasi yang diperlukan bagi pengembang Java untuk mencapai teknologi canggih. Tentu saja, tidak mudah untuk belajar musim semi dengan baik, terutama untuk memahami prinsip -prinsip musim semi yang mendasari. Dibutuhkan banyak waktu dan energi untuk mempelajarinya dengan cermat, dan terus -menerus coba -coba dan meringkas dalam proyek aktual untuk membentuk pemikiran dan pemahaman Anda sendiri. Blogger memiliki pemahaman yang sangat dangkal tentang musim semi di awal, dan dimungkinkan untuk mengandalkan masalah yang dapat dipecahkan oleh du niang secara umum ketika menghadapi masalah dalam proyek. Namun, selama lebih dari setahun sejak musim semi telah berhubungan dengan musim semi, pemahaman tentang sistem kerangka kerjanya cukup kacau, dan teknologi yang dalam masih seperti kabut, dan belum membentuk kognisi dan pemahamannya sendiri, yang sangat tidak menguntungkan untuk peningkatan teknologi pemrograman. Mengingat hal ini, saya memutuskan untuk menenangkan dan mempelajari kerangka kerja musim semi secara sistematis dari awal hingga akhir, dan mencatat detail pembelajaran dan berbagi pengetahuan teknis melalui bentuk blog. Oke, mari kita ke intinya-
Pengantar Kerangka Musim Semi Inti
Di (injeksi ketergantungan), injeksi ketergantungan, dan konsep lain yang sering kita dengar, sebenarnya mengimplementasikan fungsi yang sama dengan IOC (inversi kontrol), tetapi fungsi yang sama dijelaskan dari perspektif yang berbeda. Blogger di sini tidak akan menganalisis terlalu banyak, ada banyak penjelasan tentang Baidu. Yang perlu kita ketahui adalah apa suntikan ketergantungan dan mengapa injeksi ketergantungan. Untuk memahami dua poin ini, saya pikir belajar Spring adalah yang terbaik dalam hal berpikir.
Ketika musim semi tidak digunakan - yaitu, ketika tidak ada injeksi ketergantungan, sulit untuk mencapai kolaborasi fungsional bersama antara kelas aplikasi Java. Jika kelas tertentu (a) perlu mengimplementasikan fungsinya, jika perlu mengandalkan kolaborasi kelas lain (b), perlu secara aktif membuat objek kelas B di kelas A untuk menyelesaikan fungsi menggunakan metode kelas B (Anda tidak perlu khawatir tentang metode statis dan situasi lain di sini). Ini setara dengan Kelas A yang bertanggung jawab atas pengelolaan seluruh siklus hidup objek Kelas B. Dalam kasus yang sangat sederhana, tampaknya tidak ada masalah pada objek baru dari kelas lain dalam satu kelas, tetapi hubungan kolaboratif antara kelas aplikasi dan kelas yang kompleks sering kali multilateral. Kami tidak tahu berapa banyak objek alternatif implementasi fungsi kelas akan bergantung untuk bekerja sama. Oleh karena itu, membuat objek di kelas dan mengelola seluruh siklus hidup objek akan menyebabkan kopling kode tinggi dan kompleksitas yang tak terbayangkan. Jadi, bayangkan bahwa jika kita dapat menyerahkan siklus hidup suatu objek ke komponen pihak ketiga untuk manajemen, dan ketika suatu kelas membutuhkan objek lain, komponen pihak ketiga akan dibuat langsung ke sana. Dengan cara ini, kelas hanya dapat fokus pada implementasi fungsinya sendiri tanpa mengelola siklus hidup objek kelas lainnya, fungsi kelas semacam itu jauh lebih sederhana. Ya, Anda pasti mengerti bahwa musim semi adalah komponen pihak ketiga ini. Kita hanya perlu memberi tahu Spring (wadah) objek mana yang perlu dikelola, dan kita tidak perlu peduli tentang bagaimana kerangka kerja Spring membuat objek. Dengan cara ini, ketika Kelas A tertentu membutuhkan objek Kelas B, jika Kelas B telah dinyatakan dan diserahkan ke Manajemen Kontainer Musim Semi, maka ketika program berjalan ke Kelas A dan membutuhkan Kelas B, Spring Container menyuntikkan objek Kelas B ke Kelas A melalui injeksi ketergantungan untuk membantu dalam menyelesaikan fungsi bisnis. Melalui injeksi ketergantungan komponen pihak ketiga, objek tidak perlu lagi membuat dan mengelola ketergantungan antar kelas sendiri. Ada juga banyak cara untuk membuat injeksi ketergantungan objek, seperti injeksi antarmuka, injeksi metode konstruksi, injeksi metode setter, dll. Berbicara tentang hal ini, Anda harus memiliki pemahaman yang relatif langsung tentang injeksi ketergantungan. Adapun mengapa injeksi ketergantungan diperlukan, artikel di atas telah menjelaskannya dengan sangat jelas. Untuk mengurangi kopling antara komponen dalam kode, pertama -tama kita harus menggunakan contoh sederhana untuk secara intuitif mengalami manfaat injeksi ketergantungan daripada mengelola objek sendiri -
Manusia Public Class mengimplementasikan mobil {private qqcar private; public man () {this.car = qqcar baru (); } @Override public void xiabibi () {} public void driveCar () {car.drive (); }}Ada dua implementasi mobil antarmuka: Mercedes-Benz dan QQ Car. Dalam kode manusia dan QQCAR di atas, pengemudi veteran hanya membuat objek mobil QQ melalui konstruktor, sehingga ia hanya dapat mengendarai mobil QQ. Jadi apa yang harus dilakukan pengemudi veteran jika dia ingin mengendarai Mercedes-Benz? Apakah Anda memintanya untuk menciptakan kembali objek Mercedes-Benz? Kode yang sangat digabungkan seperti itu tampaknya tidak berdaya, jadi kami akan membuat beberapa perbaikan pada kode di atas dengan menyuntikkan objek:
Manusia kelas publik mengimplementasikan mobil {mobil pribadi manusia; orang publik (mobil mobil) {this.car = mobil; } @Override public void xiabibi () {} public void driveCar () {car.drive (); }}Kode di atas memblokir objek spesifik berdasarkan karakteristik polimorfik melalui injeksi antarmuka konstruktor, sehingga pengemudi veteran dapat mengendarai apa pun yang mereka inginkan. Ini adalah manfaat dari injeksi ketergantungan.
AOP (pemrograman berorientasi aspek), pemrograman berorientasi wajah. Dalam pengembangan harian, ketika kami menyelesaikan fungsi bisnis tertentu, kami menulis banyak kode. Ketika kami akhirnya mengoptimalkan kode, kami menemukan bahwa kode yang benar -benar melengkapi bisnis mungkin hanya dua kalimat, dan sisanya tidak terlalu relevan dengan bagian bisnis ini. Ini sepenuhnya diekstraksi hanya untuk mengimplementasikan kode teknologi tertentu. Jadi secara alami, kami akan mengekstraknya ke kelas alat, sehingga semua yang Anda gunakan OK dengan hanya memanggil metode alat. Mari kita lihat sedikit lebih tinggi. Selain menyelesaikan fungsi bisnis terkait, komponen fungsional dari setiap modul bisnis melibatkan operasi tambahan seperti log, transaksi, dan kontrol keamanan. Ini bukan fungsi inti dari modul, tetapi mereka sangat diperlukan. Jika fungsi tambahan ini ditambahkan ke kode, setiap komponen sistem bisnis akan tampak terlalu berulang dan membuat kode bisnis tampak membingungkan dan tidak cukup murni. Pada saat ini, Anda bertanya kepada Tuhan, dapatkah kode bisnis Anda hanya fokus pada implementasi bisnis, dan mengabaikan hal -hal yang tidak relevan seperti log, transaksi, dll.? Oh, Tuhan bilang tidak apa -apa, jadi ada AOP. Jika tujuan injeksi ketergantungan adalah untuk menjaga komponen kooperatif dalam keadaan kopling yang relatif longgar, AOP memisahkan fungsi yang tersebar di seluruh aplikasi untuk membentuk komponen yang dapat digunakan kembali. Dalam istilah, log, transaksi, dll. Semuanya adalah komponen yang dapat digunakan kembali. Kami dapat sepenuhnya mengekstrak log, transaksi, keamanan, dan kode fungsional lainnya yang tersebar di berbagai bagian kode bisnis dan menjadi komponen alat yang terpisah. Nyatakan sebagai bagian fungsional dalam konfigurasi Spring, dan kemudian beri tahu pegas di mana dan kapan Anda ingin menggunakan (memotong) komponen yang dapat digunakan kembali ini. Ini adalah interpretasi sederhana saya tentang bagian yang berorientasi wajah. Artikel ini hanyalah sebuah pengantar, sehingga blogger hanya akan menjelaskan secara singkat konsep dan tidak akan membuat kode atau implementasi konfigurasi tertentu. Ini akan disajikan dalam posting blog berikutnya. Selamat datang untuk melihatnya.