'Coupling' adalah istilah yang menggambarkan hubungan antara dua entitas dalam sistem perangkat lunak (biasanya kelas).
Ketika suatu kelas menggunakan kelas lain, atau berkomunikasi dengannya, itu dikatakan 'bergantung' pada kelas lain, dan karenanya kelas-kelas ini 'digabungkan'. Setidaknya salah satu dari mereka 'tahu' tentang yang lain.
Idenya adalah bahwa kita harus mencoba menjaga sambungan antara kelas dalam sistem kita sebagai 'longgar' mungkin: maka 'lepas kopling' atau kadang-kadang 'decoupling' (walaupun dalam bahasa Inggris 'decoupling' akan berarti 'tidak ada kopling sama sekali', orang-orang sering menggunakannya untuk menyiratkan 'lepas kopling' antara entitas).
Jadi: dalam praktiknya apa yang longgar-lepas versus kuat, dan mengapa kita harus membuat entitas longgar?
Coupling menggambarkan tingkat ketergantungan antara satu entitas dengan entitas lainnya. Seringkali kelas atau objek.
Ketika ClassA sangat bergantung pada ClassB, kemungkinan ClassA terpengaruh ketika ClassB diubah sangat tinggi. Ini adalah kopling yang kuat.
Namun jika ClassA sedikit tergantung pada ClassB, maka kemungkinan ClassA terpengaruh dengan cara apa pun oleh perubahan kode ClassB, rendah. Ini adalah kopling longgar, atau hubungan 'dipisahkan'.
Kopling longgar baik karena kami tidak ingin komponen sistem kami sangat bergantung satu sama lain. Kami ingin menjaga sistem tetap modular, di mana kami dapat dengan aman mengubah satu bagian tanpa memengaruhi yang lain.
Ketika dua bagian secara longgar digabungkan, mereka lebih independen satu sama lain dan lebih kecil kemungkinannya untuk patah ketika bagian lainnya berubah.
Misalnya, saat membuat mobil, Anda tidak akan menginginkan perubahan internal pada mesin untuk memecahkan sesuatu di setir.
Meskipun ini tidak akan pernah terjadi secara tidak sengaja ketika membuat mobil, hal serupa terjadi pada programmer setiap saat. Kopling longgar dimaksudkan untuk mengurangi risiko hal-hal seperti itu terjadi.
Kopling yang kuat biasanya terjadi ketika entitas A tahu terlalu banyak tentang entitas B. Jika entitas A membuat terlalu banyak asumsi tentang bagaimana entitas B beroperasi atau bagaimana ia dibangun, maka ada risiko tinggi bahwa perubahan dalam entitas B akan memengaruhi entitas A. Ini adalah karena salah satu anggapan tentang entitas B sekarang salah.
Sebagai contoh, bayangkan bahwa sebagai pengemudi, Anda akan membuat asumsi tertentu tentang bagaimana mesin mobil Anda bekerja.
Pada hari Anda membeli mobil baru dengan mesin yang bekerja secara berbeda (atau karena alasan tertentu mesin Anda diganti), asumsi Anda sebelumnya akan salah. Jika Anda kode di komputer, Anda sekarang akan menjadi kode yang salah yang tidak berfungsi dengan baik.
Namun, jika semua asumsi bahwa sebagai pengemudi Anda membuat mobil adalah: A- mereka memiliki roda kemudi dan B- mereka memiliki pedal rem dan gas, daripada perubahan dalam mobil tidak akan mempengaruhi Anda, selama beberapa asumsi Anda tetap benar. Ini adalah kopling longgar.
Teknik penting untuk mencapai kopling longgar adalah Enkapsulasi. Idenya adalah bahwa kelas menyembunyikan detail internal dari kelas lain, dan menawarkan antarmuka yang didefinisikan secara ketat untuk kelas lain untuk berkomunikasi dengannya.
Jadi misalnya, jika Anda mendefinisikan kelas Mobil, itu antarmuka (metode umum) mungkin akan menjadi drive()
, stop()
, steerLeft()
, steerRight()
, getSpeed()
. Ini adalah metode yang dapat digunakan benda lain pada objek Mobil.
Semua detail lain dari kelas Mobil: bagaimana mesin bekerja, jenis bahan bakar yang digunakannya, dll. Disembunyikan dari kelas lain - untuk mencegah mereka mengetahui terlalu banyak tentang Mobil.
Saat kelas A tahu terlalu banyak tentang kelas B: kami memiliki hubungan yang sangat berpasangan, di mana kelas A terlalu bergantung pada kelas B dan perubahan pada kelas B cenderung memengaruhi kelas A. Membuat sistem sulit untuk diperluas dan dipelihara.
Hubungan antara dua entitas, di mana mereka tahu sedikit tentang satu sama lain (hanya apa yang diperlukan) - adalah hubungan yang longgar, atau terpisah.