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)
{
}
}
Sejauh ini apa yang Anda katakan masuk akal. Bisakah Anda jelaskan bagaimana mekanisme kopling dapat berhubungan dengan pola Pengamat?
Jim
1
Pola pengamat dijelaskan di sini: en.wikipedia.org/wiki/Observer_pattern . Karena kelas Subjek dapat mempertahankan daftar kelas yang diwarisi dari 'Pengamat', tanpa benar-benar mengetahui tipe konkret dari kelas-kelas tersebut, ini adalah contoh dari kopling longgar. Subjek tidak bergantung pada Pengamatnya atau masalah internal mereka. Pengamat tidak bergantung pada Subjek atau salah satu keprihatinannya.
Jonathan
4
Antarmuka Java adalah alat yang dapat membantu ini. Namun mereka tidak diharuskan. Konsep program ke antarmuka bukan implementasi berarti program untuk metode / atribut publik (atau atribut yang dimaksudkan untuk digunakan oleh penelepon eksternal ketika bahasa tidak mendukung pengubah akses, seperti C). Antarmuka seharusnya menghormati kontrak tersirat ini dengan tidak mengubah. Dalam bahasa tanpa pengubah akses (seperti C), itu berarti hanya menggunakan antarmuka / fungsi yang dipublikasikan dan tidak mengenai yang dimaksudkan untuk digunakan secara internal, karena itu dapat berubah sesuai kebutuhan untuk mendukung fungsi yang dipublikasikan.
Bill Rosmus
3
@jonathanconway terima kasih, Pak, tetapi kedua kode melakukan hal yang sama: lalu apa perbedaan di antara mereka? yaitu keuntungan apa yang ada untuk longgar ditambah?
BKSpurgeon
1
Saya telah melihat (pada dasarnya) contoh ini sebelumnya. Menurut pendapat saya bukankah itu penting jika ada banyak jenis database yang akan digunakan. Jika Anda berencana untuk hanya memiliki satu, maka apakah itu buruk untuk menggunakan implementasi secara langsung, lalu nanti jika Anda perlu menyuntikkan berbagai jenis, maka refactor penggunaan tunggal Database untuk menggunakan antarmuka? Daripada menambahkan banyak kode pelat ketel yang sepertinya tidak diperlukan?
Carlos Bribiescas
178
Penjelasan tanpa kode APAPUN
Contoh Ringkasan:
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.
Kopling ketat (Contoh Lengkap)
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.
Poin Kunci # 1 : Dengan kata lain, jika Anda ingin mengubah kulit, Anda juga HARUS mengubah desain tubuh Anda juga karena keduanya disatukan - keduanya dipasangkan dengan erat.
Tuhan bukanlah programmer berorientasi objek yang baik.
Kopling longgar (Contoh Lengkap)
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.
Itu poin kunci # 2. Jika Anda mengganti baju Anda, maka Anda tidak dipaksa untuk mengubah tubuh Anda - ketika Anda bisa melakukannya, maka Anda memiliki kopling longgar. Ketika Anda tidak bisa melakukan itu, maka Anda memiliki kopling ketat.
Singkatnya, konsep dasar.
Mengapa semua ini penting?
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 Praktis dari Kopling di Saat Pengodean
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.
Ringkasan
Singkatnya, kopling longgar membuat kode lebih mudah diubah. Jawaban di atas menyediakan beberapa kode yang layak dibaca saat ini.
Prinsip Polimorfisme dan SOLID
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.
ini adalah penjelasan yang diremehkan untuk programmer baru. Sulit untuk membaca kata-kata besar yang kami tampilkan, begitu Anda memahami dasar-dasarnya, maka lebih mudah untuk pergi ke kata-kata besar lol
user2763557
6
Ada beberapa hal yang harus dipasangkan dengan erat dan sebagian lagi digabungkan dengan lingkungannya. Penggunaan kulit bukanlah analogi yang tepat untuk pemasangan ketat. Jika kulit dianggap erat dengan tubuh, demikian pula setiap bagian lainnya. Tubuh (secara keseluruhan) harus memiliki bagian (terintegrasi erat) agar berfungsi dengan baik (mungkin seperti yang dipikirkan oleh alam - arsitek yang brilian). Jika bagian-bagian itu dirancang untuk dapat diganti (sesederhana mengganti topi) maka, makna tubuh 'manusia' kehilangan definisinya. Komentar 1/2.
lupchiazoem
6
Contohnya, jika kulit dibuat bisa diganti, maka kepala juga harus bisa diganti menjadi baru. Jika itu terjadi, maka orang mungkin tidak dapat dikenali dari satu pertemuan ke pertemuan lainnya. Analogi penggabungan ketat / longgar yang baik adalah - mobil dan bagian-bagiannya, komputer dan bagian-bagiannya dll ... Jika ada masalah dengan mouse / keyboard komputer, dapat diganti dengan bagian lain daripada membuat seluruh komputer tidak berguna dan membuang. Komentar 2/2.
lupchiazoem
1
@ BKSpurgeon Penjelasan luar biasa !! dan cara Anda untuk mengambil contoh untuk penjelasan juga sangat bagus.
Kiran Joshi
5
Dijelaskan dengan sangat kreatif. Saya sangat erat dengan jawaban ini.
AliN11
72
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.
"Seberapa sering perubahan di kelas A terkait perubahan di kelas B?" Saya perlu contoh singkat untuk kalimat di atas ??
Kumaresan Perumal
15
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.
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.
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.
Digabungkan ketat
publicinterfaceOutputGenerator{publicvoid generateOutput();}publicclassCSVOutputGeneratorimplementsOutputGenerator{publicvoid generateOutput(){System.out.println("CSV Output Generator");}}publicclassJSONOutputGeneratorimplementsOutputGenerator{publicvoid generateOutput(){System.out.println("JSON Output Generator");}}// In Other Code, we write Output Generator like...publicclassClass1{publicvoid 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 =newCSVOutputGenerator();
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.
Longgar digabungkan
publicinterfaceOutputGenerator{publicvoid generateOutput();}publicclassCSVOutputGeneratorimplementsOutputGenerator{publicvoid generateOutput(){System.out.println("CSV Output Generator");}}publicclassJSONOutputGeneratorimplementsOutputGenerator{publicvoid generateOutput(){System.out.println("JSON Output Generator");}}// In Other Code, we write Output Generator like...publicclassClass1{publicvoid 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 classOutputGenerator 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 myclasshal 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.
Saya tidak berpikir kopling longgar sama dengan inversi kontrol. Pembalikan kontrol adalah teknik yang sangat berguna untuk mengurangi kopling desain Anda, tetapi ada banyak teknik lain.
Don Kirkby
2
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 Carkelas 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 Cartidak 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.
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:
Contoh kopling longgar:
Contoh lain di sini .
sumber
Penjelasan tanpa kode APAPUN
Contoh Ringkasan:
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.
Kopling ketat (Contoh Lengkap)
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.
Kopling longgar (Contoh Lengkap)
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.
Mengapa semua ini penting?
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 Praktis dari Kopling di Saat Pengodean
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.
Ringkasan
Singkatnya, kopling longgar membuat kode lebih mudah diubah. Jawaban di atas menyediakan beberapa kode yang layak dibaca saat ini.
Prinsip Polimorfisme dan SOLID
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.
Atribusi Gambar .
sumber
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.
sumber
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.
sumber
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 .
sumber
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:
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.sumber
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
sumber
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.
sumber
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.
Digabungkan ketat
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.
Longgar digabungkan
sumber
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
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.sumber
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)
sumber
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.
sumber
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.
sumber
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
sumber
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:
Klien
Car
kelas dapat membuat satu dengan mesin HANYA "X_COMPANY".Pertimbangkan untuk memutus hubungan ini dengan kemampuan untuk mengubahnya:
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.
sumber
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:
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.
sumber