Memahami Longgar / Ketat Kopling di "Dunia Nyata"

Saya tidak akan mengatakan apa "komunitas" karena saya ingin penjelasan yang tidak bias, tetapi katakanlah Anda sedang membangun modul yang dapat digunakan kembali dan modul itu membutuhkan 3+ modul tergantung dan menghapus 1 dari mereka menyebabkan kesalahan pemecahan tidak hanya di aplikasi Anda sebagai keseluruhan yang menggunakan modul ini, tetapi modul itu sendiri.

Dari pemahaman saya (yang pasti salah) sistem modular longgar ditambah tidak akan rusak hanya dengan menghapus satu modul. Aplikasi harus tetap berjalan tetapi tanpa "fitur" / modul dan modul itu sendiri seharusnya tidak menyebabkan semuanya tidak berjalan hanya karena modul dependen tidak ada.

Apakah ini salah? Jika demikian, jika modul masih tergantung pada titik semuanya tidak berfungsi apa perbedaan antara kopling ketat / longgar?

Tidak cukup --- menghapus modul bisa merusak sistem. Gagasan di balik sistem yang digabungkan secara longgar adalah bahwa bertukar dalam modul yang sama sekali berbeda akan bekerja dengan baik selama modul baru sesuai dengan persyaratan antarmuka yang sama dengan yang lama. Jika dipasangkan dengan erat, kode di sekitarnya akan membuat anggapan tentang internal dan akan mulai gagal jika modul baru diperkenalkan.

Longgar kopling pada dasarnya adalah ketergantungan tidak langsung antara modul tentang bagaimana mereka dapat berkembang.

Secara umum, ketika ada sistem yang tergabung erat modul / objek yang berbeda memiliki perilaku yang sangat spesifik yang mengasumsikan perilaku objek periferal. Objek tersebut dihubungkan / digabungkan ke perilaku modul lainnya dan tidak dapat digunakan kembali secara terpisah atau dalam konteks lainnya.

Modul semacam itu walaupun bertanggung jawab atas fungsi individu tidak dapat berkembang secara independen atau tidak dapat berkembang

Sebuah contoh:

Katakanlah Anda memiliki 3 objek Shape(objek model) dan Canvas(elemen UI). Sekarang

Asumsikan bahwa suatu metode shape.draw(Canvas)akan menggambar objek pada bidang yang disuplai oleh bidang kanvas.

Sekarang, terkadang jendela sebagian tertutup dan diubah ukurannya. Dalam kasus seperti itu, metode di atas mungkin hanya melakukan sesuatu seperti ini.

shape::draw(Canvas) {
   Rect.WindowLeft = Canvas.GetWindowRect.getLeftOffset(); 
   Rect.LeftPixel = Canvas.GetWindowRect.pixels() + Rect.WindowLeft; 
   ....  // like this get all co-ordinates. 

   draw_instance(Rect);  // This will draw the actual shape. 
}

Pada dasarnya, di sini fungsi draw mengambil persegi panjang di mana hal-hal perlu digambar. Ini mudah dimengerti (orang mungkin menyebut ini sederhana ) kode. Namun, ini adalah kode yang sangat digabungkan.

Bayangkan situasinya:

• Bagaimana jika mekanisme kanvas menahan jendela tidak lagi berbentuk persegi panjang?
• bagaimana jika ada offset tambahan yang disimpan Canvas yang bersifat pribadi ?
• Bagaimana jika beberapa aplikasi lain menginginkan bentuk yang sama tetapi tidak lagi memiliki jendela GUI (misalnya, ia membuat gambar dan menyimpan dalam file).

Akar penyebab masalah adalah bahwa objek shape tahu dan karenanya erat dengan Canvas.

Apa yang diinginkan bahwa satu set piksel diberikan untuk membentuk di mana ia menulis; yang shapeseharusnya tidak (bahkan implisit) pengetahuan tentang di mana pixel benar-benar ditulis.

Itu tergantung, bahkan pada apa yang Anda tentukan sebagai modul. Beberapa bagian dari sistem harus digabungkan dengan erat (misalnya, entitas Anda harus digunakan kembali di seluruh aplikasi), tetapi beberapa sistem harus longgar, baik dengan pemisahan antarmuka, atau jika kita berbicara tentang tidak merusak aplikasi jika Anda menghapus modul , maka modul itu harus ditransfer entah bagaimana secara dinamis, mungkin melalui wadah IOC atau sesuatu.

Juga, kopling ketat berarti bahwa beberapa bagian tergantung pada implementasi modul tertentu , bukan definisi modul atau sesuatu.