Jawaban:
Kopling ketat adalah ketika sekelompok kelas sangat tergantung satu sama lain.
Skenario ini muncul ketika suatu kelas mengambil terlalu banyak tanggung jawab, atau ketika satu masalah tersebar di banyak kelas daripada memiliki kelasnya sendiri.
Kopling longgar dicapai melalui desain yang mempromosikan tanggung jawab tunggal dan pemisahan masalah.
Kelas yang digabungkan secara longgar dapat dikonsumsi dan diuji secara independen dari kelas lain (beton).
Antarmuka adalah alat yang ampuh untuk digunakan untuk decoupling. Kelas dapat berkomunikasi melalui antarmuka daripada kelas konkret lainnya, dan kelas mana pun bisa berada di ujung komunikasi itu hanya dengan mengimplementasikan antarmuka.
Contoh kopling ketat:
class CustomerRepository
{
private readonly Database database;
public CustomerRepository(Database database)
{
this.database = database;
}
public void Add(string CustomerName)
{
database.AddRow("Customer", CustomerName);
}
}
class Database
{
public void AddRow(string Table, string Value)
{
}
}
Contoh kopling longgar:
class CustomerRepository
{
private readonly IDatabase database;
public CustomerRepository(IDatabase database)
{
this.database = database;
}
public void Add(string CustomerName)
{
database.AddRow("Customer", CustomerName);
}
}
interface IDatabase
{
void AddRow(string Table, string Value);
}
class Database implements IDatabase
{
public void AddRow(string Table, string Value)
{
}
}
Contoh lain di sini .
Topi itu "longgar digabungkan" ke tubuh. Ini berarti Anda dapat dengan mudah melepas topi tanpa membuat perubahan pada orang / tubuh. Ketika Anda bisa melakukan itu maka Anda memiliki "kopling longgar". Lihat di bawah untuk elaborasi.
Pikirkan kulitmu. Itu menempel di tubuh Anda. Cocok seperti sarung tangan. Tetapi bagaimana jika Anda ingin mengubah warna kulit Anda dari mengatakan putih ke hijau? Bisakah Anda bayangkan betapa menyakitkannya untuk mengupas kulit Anda, mengecatnya, dan kemudian menempelkannya kembali pada dll? Mengubah kulit Anda sulit karena itu tergabung erat dengan tubuh Anda. Anda tidak bisa melakukan perubahan dengan mudah. Anda harus mendesain ulang manusia secara fundamental untuk memungkinkan hal ini.
Tuhan bukanlah programmer berorientasi objek yang baik.
Sekarang pikirkan berpakaian di pagi hari. Anda tidak suka biru? Tidak masalah: Anda bisa mengenakan baju merah sebagai gantinya. Anda dapat melakukan ini dengan mudah dan mudah karena baju itu tidak benar-benar terhubung ke tubuh Anda dengan cara yang sama seperti kulit Anda.Kemejanya tidak tahu atau peduli dengan tubuh apa yang sedang terjadi . Dengan kata lain, Anda bisa mengganti pakaian, tanpa benar-benar mengubah tubuh Anda.
Singkatnya, konsep dasar.
Ini penting karena peranti lunak selalu berubah. Secara umum Anda ingin dapat dengan mudah memodifikasi kode Anda, tanpa mengubah kode Anda. Saya tahu itu terdengar seperti sebuah oxymoron, tapi tolong bersabarlah.
Contoh CSV / JSON / DB: Jika seseorang menginginkan hasil mereka dalam file CSV daripada JSON dll., Atau jika Anda ingin beralih dari MySQL ke PostGreSQL Anda harus dapat membuat perubahan itu dengan sangat mudah dalam kode Anda, tanpa harus menulis ulang seluruh kelas dll. Dengan kata lain, Anda tidak ingin memasangkan aplikasi Anda secara ketat dengan implementasi basis data tertentu (mis. Mysql) atau ke output tertentu (mis. file CSV). Karena, seperti yang tak terhindarkan dalam perangkat lunak, perubahan akan datang. Ketika mereka datang, itu jauh lebih mudah jika bagian-bagian Anda dari kode Anda secara longgar digabungkan.
Contoh Suku Cadang Mobil: Jika seseorang ingin mobil mereka menggunakan hitam , Anda tidak harus mendesain ulang seluruh mobil untuk melakukan itu. Mobil dan suku cadangnya akan menjadi contoh sempurna dari arsitektur yang digabungkan secara longgar. Jika Anda ingin mengganti mesin Anda dengan yang lebih baik, Anda harus dapat dengan mudah melepas mesin Anda tanpa terlalu banyak usaha dan menukarnya dengan yang lebih baik. Jika mobil Anda hanya bekerja dengan Mesin Rolls Royce 1234 dan tidak ada mesin lain - maka mobil Anda akan terhubung erat dengan mesin itu (Rolls Royce 1234). Akan lebih baik jika Anda mengubah desain mobil Anda sehingga akan bekerja dengan apa punmesin, sehingga sedikit lebih longgar ditambah dengan komponennya. Bahkan lebih baik jika mobil Anda dapat bekerja tanpa membutuhkan mesin sama sekali! Sejumlah kopling akan terjadi, tetapi Anda harus berusaha meminimalkannya sebanyak mungkin. Mengapa? Karena ketika persyaratan berubah kita harus tetap dapat memberikan perangkat lunak berkualitas baik, sangat cepat dan kita dibantu dalam tujuan itu dengan longgar.
Singkatnya, kopling longgar membuat kode lebih mudah diubah. Jawaban di atas menyediakan beberapa kode yang layak dibaca saat ini.
Re: @TimoHuovinen komentar - konsep kopling longgar berjalan seiring dengan konsep polimorfisme. Jika Anda memahami analogi dasar kemeja / suku cadang mobil, maka Anda akan siap untuk memahami polimorfisme. Cara terbaik, pada titik ini adalah membaca contoh kode yang disediakan oleh kolega saya yang dapat diperkirakan dalam jawaban lain di utas ini. Jika saya katakan lagi, Anda mungkin kelebihan beban dengan terlalu banyak info.
Dalam desain berorientasi objek, jumlah kopling mengacu pada seberapa banyak desain satu kelas tergantung pada desain kelas lain. Dengan kata lain, seberapa sering perubahan di kelas A terkait dengan perubahan di kelas B? Kopling ketat berarti dua kelas sering berubah bersama, kopling longgar berarti mereka sebagian besar independen. Secara umum, kopling longgar direkomendasikan karena lebih mudah untuk diuji dan dirawat.
Anda mungkin menemukan makalah ini oleh Martin Fowler (PDF) bermanfaat.
Secara umum Tight Coupling buruk tetapi sebagian besar waktu, karena mengurangi fleksibilitas dan kegunaan ulang kode, itu membuat perubahan jauh lebih sulit, menghambat testability dll.
Tightly Coupled Object adalah objek yang perlu tahu sedikit tentang satu sama lain dan biasanya sangat bergantung pada satu sama lain antarmuka. Mengubah satu objek dalam aplikasi yang digabungkan ketat seringkali memerlukan perubahan pada sejumlah objek lainnya, Dalam aplikasi kecil kita dapat dengan mudah mengidentifikasi perubahan dan ada sedikit peluang untuk kehilangan apa pun. Tetapi dalam aplikasi besar inter-dependensi ini tidak selalu diketahui oleh setiap programmer atau ada kesempatan untuk melewatkan perubahan. Tetapi setiap set objek yang digabungkan secara longgar tidak bergantung pada yang lain.
Singkatnya dapat kita katakan, lepas kopling adalah tujuan desain yang berusaha untuk mengurangi saling ketergantungan antara komponen suatu sistem dengan tujuan mengurangi risiko bahwa perubahan dalam satu komponen akan memerlukan perubahan dalam komponen lainnya. Loose coupling adalah konsep yang jauh lebih umum yang dimaksudkan untuk meningkatkan fleksibilitas suatu sistem, membuatnya lebih mudah dirawat, dan membuat keseluruhan kerangka kerja lebih 'stabil'.
Kopling mengacu pada tingkat pengetahuan langsung yang dimiliki satu elemen terhadap elemen lainnya. kita dapat mengatakan misalnya: A dan B, hanya B mengubah perilakunya hanya ketika A mengubah perilakunya. Sistem yang digabungkan secara longgar dapat dengan mudah dipecah menjadi elemen-elemen yang dapat didefinisikan.
Ketika dua objek digabungkan secara longgar, mereka dapat berinteraksi tetapi memiliki sedikit pengetahuan satu sama lain.
Desain yang digabungkan secara longgar memungkinkan kami membangun sistem OO fleksibel yang dapat menangani perubahan.
Pola desain pengamat adalah contoh yang baik untuk membuat kelas digabungkan secara longgar, Anda dapat melihatnya di Wikipedia .
Ekstrak dari posting blog saya di kopling:
Apa itu Kopling Ketat : -
Seperti definisi par di atas, Tightly Coupled Object adalah objek yang perlu diketahui tentang objek lain dan biasanya sangat bergantung pada antarmuka masing-masing.
Ketika kita mengubah satu objek dalam aplikasi yang digabungkan secara ketat, seringkali diperlukan perubahan pada sejumlah objek lainnya. Tidak ada masalah dalam aplikasi kecil kita dapat dengan mudah mengidentifikasi perubahan. Tetapi dalam kasus aplikasi besar inter-dependensi ini tidak selalu diketahui oleh setiap konsumen atau pengembang lain atau ada banyak peluang perubahan di masa depan.
Mari kita ambil kode demo keranjang belanja untuk memahami kopling ketat:
namespace DNSLooseCoupling
{
public class ShoppingCart
{
public float Price;
public int Quantity;
public float GetRowItemTotal()
{
return Price * Quantity;
}
}
public class ShoppingCartContents
{
public ShoppingCart[] items;
public float GetCartItemsTotal()
{
float cartTotal = 0;
foreach (ShoppingCart item in items)
{
cartTotal += item.GetRowItemTotal();
}
return cartTotal;
}
}
public class Order
{
private ShoppingCartContents cart;
private float salesTax;
public Order(ShoppingCartContents cart, float salesTax)
{
this.cart = cart;
this.salesTax = salesTax;
}
public float OrderTotal()
{
return cart.GetCartItemsTotal() * (2.0f + salesTax);
}
}
}
Masalah dengan contoh di atas
Kopling Ketat menciptakan beberapa kesulitan.
Di sini, OrderTotal()
metode memberi kami jumlah lengkap untuk item kereta saat ini. Jika kami ingin menambahkan fitur diskon di sistem keranjang ini. Sangat sulit dilakukan dalam kode di atas karena kita harus membuat perubahan di setiap kelas karena sangat erat.
Loose coupling berarti tingkat ketergantungan antara dua komponen sangat rendah.
Contoh: SIM GSM
Kopling ketat berarti tingkat ketergantungan antara dua komponen sangat tinggi.
Contoh: CDMA Mobile
Cara saya memahaminya adalah, bahwa arsitektur yang digabungkan secara ketat tidak memberikan banyak fleksibilitas untuk perubahan jika dibandingkan dengan arsitektur yang digabungkan secara longgar.
Tetapi dalam kasus arsitektur yang digabungkan secara longgar, format pesan atau platform operasi atau pembenahan logika bisnis tidak berdampak pada ujung lainnya. Jika sistem dimatikan untuk perbaikan, tentu saja ujung lainnya tidak akan dapat mengakses layanan untuk sementara waktu tetapi selain itu, ujung yang tidak berubah dapat melanjutkan pertukaran pesan seperti sebelum revamp.
Tight Coupling berarti satu kelas tergantung pada kelas lain.
Loose Coupling berarti satu kelas tergantung pada antarmuka daripada kelas.
Dalam kopling ketat , ada ketergantungan kode keras yang dideklarasikan dalam metode.
Dalam kopling longgar , kita harus melewati ketergantungan secara eksternal pada saat runtime alih-alih kode-keras. (Sistem pasangan lepas menggunakan antarmuka untuk mengurangi ketergantungan dengan kelas.)
Misalnya, kami memiliki sistem yang dapat mengirim output dalam dua cara atau lebih seperti output JSON, output CSV, dll.
public interface OutputGenerator {
public void generateOutput();
}
public class CSVOutputGenerator implements OutputGenerator {
public void generateOutput() {
System.out.println("CSV Output Generator");
}
}
public class JSONOutputGenerator implements OutputGenerator {
public void generateOutput() {
System.out.println("JSON Output Generator");
}
}
// In Other Code, we write Output Generator like...
public class Class1 {
public void generateOutput() {
// Here Output will be in CSV-Format, because of hard-coded code.
// This method tightly coupled with CSVOutputGenerator class, if we want another Output, we must change this method.
// Any method, that calls Class1's generateOutput will return CSVOutput, because Class1 is tight couple with CSVOutputGenerator.
OutputGenerator outputGenerator = new CSVOutputGenerator();
output.generateOutput();
}
}
Dalam contoh di atas, jika kita ingin mengubah output dalam JSON, maka kita perlu menemukan dan mengubah seluruh kode, karena Class1 sangat erat dengan kelas CSVOutputGenerator.
public interface OutputGenerator {
public void generateOutput();
}
public class CSVOutputGenerator implements OutputGenerator {
public void generateOutput() {
System.out.println("CSV Output Generator");
}
}
public class JSONOutputGenerator implements OutputGenerator {
public void generateOutput() {
System.out.println("JSON Output Generator");
}
}
// In Other Code, we write Output Generator like...
public class Class1 {
public void generateOutput(OutputGenerator outputGenerator) {
// if you want to write JSON, pass object of JSONOutputGenerator (Dependency will be passed externally to this method)
// if you want to write CSV, pass object of CSVOutputGenerator (Dependency will be passed externally to this method)
// Due to loose couple with class, we don't need to change code of Class1, because Class1 is loose coupled with CSVOutputGenerator or JSONOutputGenerator class
// Any method, that calls Class1's generateOutput will desired output, because Class1 does not tight couple with CSVOutputGenerator or JSONOutputGenerator class
OutputGenerator outputGenerator = outputGenerator;
output.generateOutput();
}
}
Ada alat tertentu yang menyediakan injeksi ketergantungan melalui pustaka mereka, misalnya dalam .net kita memiliki ninject Library .
Jika Anda melangkah lebih jauh di java maka spring menyediakan kemampuan ini.
Objek yang digabungkan secara longgar dapat dibuat dengan memperkenalkan Antarmuka dalam kode Anda, itulah yang dilakukan sumber ini.
Katakan dalam kode yang Anda tulis
Myclass m = new Myclass();
sekarang pernyataan ini dalam metode Anda mengatakan bahwa Anda bergantung pada myclass
hal ini yang disebut erat. Sekarang Anda memberikan beberapa injeksi konstruktor, atau injeksi properti dan objek instantiating maka itu akan menjadi longgar digabungkan.
Ada banyak jawaban bagus di sini menggunakan analogi tetapi seorang teman di tempat kerja memberi saya contoh yang saya sukai lebih dari semua yang disebutkan di sini ... Mata dan Kacamata!
Kopling Ketat
Kopling ketat akan menjadi mata. Jika saya ingin memperbaiki penglihatan saya, saya sangat mahal untuk mendapatkan transplantasi mata dan memiliki risiko yang cukup besar. Tetapi bagaimana jika perancang (menjadi ras manusia) menemukan cara yang lebih baik. Tambahkan fitur yang secara longgar digabungkan ke tubuh sehingga dapat dengan mudah diubah! (ya .. kacamata)
Kopling longgar
Saya dapat dengan mudah mengganti kacamata tanpa merusak visi yang mendasarinya. Saya bisa melepas kacamata dan visi saya akan seperti itu sebelumnya (tidak lebih baik atau lebih buruk). Menggunakan berbagai pasang kacamata mengubah cara kita melihat dunia melalui mata kita dengan sedikit risiko dan perawatan yang mudah.
Ringkasan
Jadi, lain kali seseorang bertanya kepada Anda "siapa yang peduli jika kode saya digabungkan dengan erat?" Jawabannya adalah semua tentang upaya untuk berubah, upaya untuk mempertahankan dan risiko perubahan.
Jadi bagaimana ini dilakukan dalam C #? Antarmuka dan Injeksi Ketergantungan!
EDIT
Ini contoh yang baik dari pola Dekorator juga, di mana mata adalah kelas yang kami dekorasikan dengan memenuhi persyaratan antarmuka tetapi memberikan fungsionalitas yang berbeda (mis. Kacamata hitam, kacamata baca, kaca pembesar untuk perhiasan, dll)
Longgar kopling dan jawaban untuk dependensi hardcod gaya lama dan masalah terkait masalah seperti sering kompilasi ketika ada perubahan dan penggunaan kembali kode. Ini menekankan pada penerapan logika pekerja dalam komponen dan menghindari solusi khusus kode kawat di sana.
Loose Coupling = IoC Lihat ini untuk penjelasan yang lebih mudah.
Loose Coupling adalah proses memberikan dependensi yang dibutuhkan kelas Anda secara tidak langsung tanpa memberikan semua informasi dependensi (yaitu dari antarmuka) jika kopling ketat Anda berikan secara langsung dalam dependensi yang bukan cara pengkodean yang baik.
Ini tentang tingkat ketergantungan kelas ke yang lain yang sangat rendah dan longgar serta sangat tinggi. Untuk menjadi jelas dalam arsitektur orientasi layanan, layanan secara longgar digabungkan satu sama lain terhadap monolitik yang ketergantungan kelas satu sama lain dengan sengaja
Jika kreasi / keberadaan suatu objek bergantung pada objek lain yang tidak dapat dirancang, koplingnya yang rapat. Dan, jika ketergantungan bisa disesuaikan, kopling longgar. Pertimbangkan sebuah contoh di Jawa:
class Car {
private Engine engine = new Engine( "X_COMPANY" ); // this car is being created with "X_COMPANY" engine
// Other parts
public Car() {
// implemenation
}
}
Klien Car
kelas dapat membuat satu dengan mesin HANYA "X_COMPANY".
Pertimbangkan untuk memutus hubungan ini dengan kemampuan untuk mengubahnya:
class Car {
private Engine engine;
// Other members
public Car( Engine engine ) { // this car can be created with any Engine type
this.engine = engine;
}
}
Sekarang, a Car
tidak bergantung pada mesin "X_COMPANY" karena dapat dibuat dengan tipe.
Catatan khusus Java: menggunakan antarmuka Java hanya untuk de-coupling bukan pendekatan desing yang tepat. Di Jawa, sebuah antarmuka memiliki tujuan - untuk bertindak sebagai kontrak yang secara intris menyediakan perilaku / keuntungan de-coupling.
Komentar Bill Rosmus dalam jawaban yang diterima memiliki penjelasan yang bagus.
Kopling ketat berarti kelas dan objek bergantung satu sama lain. Secara umum, kopling ketat biasanya tidak baik karena mengurangi fleksibilitas dan penggunaan kembali kode sementara kopling longgar berarti mengurangi ketergantungan kelas yang menggunakan kelas yang berbeda secara langsung.
Tight Coupling Objek yang tergabung erat adalah objek yang perlu diketahui tentang objek lain dan biasanya sangat bergantung pada antarmuka masing-masing. Mengubah satu objek dalam aplikasi yang digabungkan ketat seringkali memerlukan perubahan pada sejumlah objek lainnya. Dalam aplikasi kecil, kita dapat dengan mudah mengidentifikasi perubahan dan ada sedikit peluang untuk kehilangan apa pun. Tetapi dalam aplikasi besar, inter-dependensi ini tidak selalu diketahui oleh setiap programmer dan ada kemungkinan untuk mengabaikan perubahan. Contoh:
class A {
public int a = 0;
public int getA() {
System.out.println("getA() method");
return a;
}
public void setA(int aa) {
if(!(aa > 10))
a = aa;
}
}
public class B {
public static void main(String[] args) {
A aObject = new A();
aObject.a = 100; // Not suppose to happen as defined by class A, this causes tight coupling.
System.out.println("aObject.a value is: " + aObject.a);
}
}
In the above example, the code that is defined by this kind of implementation uses tight coupling and is very bad since class B knows about the detail of class A, if class A changes the variable 'a' to private then class B breaks, also class A's implementation states that variable 'a' should not be more than 10 but as we can see there is no way to enforce such a rule as we can go directly to the variable and change its state to whatever value we decide.
Output
aObject.a value is: 100
Loose Coupling
Loose coupling is a design goal to reduce the inter-dependencies between components of a system with the goal of reducing the risk that changes in one component will require changes in any other component.
Loose coupling is a much more generic concept intended to increase the flexibility of the system, make it more maintainable and makes the entire framework more stable.
Example:
class A {
private int a = 0;
public int getA() {
System.out.println("getA() method");
return a;
}
public void setA(int aa) {
if(!(aa > 10))
a = aa;
}
}
public class B {
public static void main(String[] args) {
A aObject = new A();
aObject.setA(100); // No way to set 'a' to such value as this method call will
// fail due to its enforced rule.
System.out.println("aObject value is: " + aObject.getA());
}
}
Dalam contoh di atas, kode yang didefinisikan oleh implementasi semacam ini menggunakan kopling longgar dan direkomendasikan karena kelas B harus melalui kelas A untuk mendapatkan statusnya di mana aturan diberlakukan. Jika kelas A diubah secara internal, kelas B tidak akan pecah karena hanya menggunakan kelas A sebagai cara komunikasi.
Output
getA() method
aObject value is: 0