Apa itu "kopling longgar?" Tolong berikan contoh

Sepertinya saya tidak bisa memahami konsep "longgar." Saya kira itu tidak membantu bahwa kata "longgar" biasanya memiliki konotasi negatif, jadi saya selalu lupa bahwa pemasangan longgar adalah hal yang baik .

Apakah seseorang tolong tunjukkan beberapa kode "sebelum" dan "setelah" (atau pseudocode) yang menggambarkan konsep ini?

Pertimbangkan aplikasi keranjang belanja sederhana yang menggunakan kelas CartContents untuk melacak barang-barang di keranjang belanja dan kelas Pesanan untuk memproses pembelian. Pesanan perlu menentukan nilai total konten dalam keranjang, mungkin melakukannya seperti:

Contoh Digabungkan Tightly:

public class CartEntry
{
    public float Price;
    public int Quantity;
}

public class CartContents
{
    public CartEntry[] items;
}

public class Order
{
    private CartContents cart;
    private float salesTax;

    public Order(CartContents cart, float salesTax)
    {
        this.cart = cart;
        this.salesTax = salesTax;
    }

    public float OrderTotal()
    {
        float cartTotal = 0;
        for (int i = 0; i < cart.items.Length; i++)
        {
            cartTotal += cart.items[i].Price * cart.items[i].Quantity;
        }
        cartTotal += cartTotal*salesTax;
        return cartTotal;
    }
}

Perhatikan bagaimana metode OrderTotal (dan dengan demikian kelas Order) bergantung pada detail implementasi dari CartContents dan kelas CartEntry. Jika kami mencoba mengubah logika ini untuk mendapatkan diskon, kami kemungkinan harus mengubah ketiga kelas. Juga, jika kita berubah menggunakan koleksi Daftar untuk melacak item kita harus mengubah kelas Order juga.

Sekarang, inilah cara yang sedikit lebih baik untuk melakukan hal yang sama:

Contoh kurang digabungkan:

public class CartEntry
{
    public float Price;
    public int Quantity;

    public float GetLineItemTotal()
    {
        return Price * Quantity;
    }
}

public class CartContents
{
    public CartEntry[] items;

    public float GetCartItemsTotal()
    {
        float cartTotal = 0;
        foreach (CartEntry item in items)
        {
            cartTotal += item.GetLineItemTotal();
        }
        return cartTotal;
    }
}

public class Order
{
    private CartContents cart;
    private float salesTax;

    public Order(CartContents cart, float salesTax)
    {
        this.cart = cart;
        this.salesTax = salesTax;
    }

    public float OrderTotal()
    {
        return cart.GetCartItemsTotal() * (1.0f + salesTax);
    }
}

Logika yang khusus untuk implementasi item baris keranjang atau koleksi keranjang atau pesanan dibatasi hanya untuk kelas itu. Jadi kita bisa mengubah implementasi dari kelas-kelas ini tanpa harus mengubah kelas lainnya. Kita bisa mengambil decoupling ini lebih jauh dengan meningkatkan desain, memperkenalkan antarmuka, dll, tapi saya pikir Anda mengerti maksudnya.

Banyak produk terintegrasi (terutama oleh Apple) seperti iPod , iPads adalah contoh yang baik dari kopling ketat: sekali baterai mati Anda mungkin juga membeli perangkat baru karena baterai disolder tetap dan tidak akan lepas, sehingga membuat penggantian sangat mahal. Pemain yang digabungkan secara longgar memungkinkan penggantian baterai dengan mudah.

Hal yang sama berlaku untuk pengembangan perangkat lunak: umumnya (jauh) lebih baik memiliki kode yang digabungkan secara longgar untuk memfasilitasi ekstensi dan penggantian (dan untuk membuat bagian-bagian individual lebih mudah dimengerti). Tapi, sangat jarang, dalam keadaan khusus kopling ketat dapat menguntungkan karena integrasi ketat beberapa modul memungkinkan untuk optimasi yang lebih baik.

Saya akan menggunakan Java sebagai contoh. Katakanlah kita memiliki kelas yang terlihat seperti ini:

public class ABC
{
   public void doDiskAccess() {...}
}

Ketika saya memanggil kelas, saya perlu melakukan sesuatu seperti ini:

ABC abc = new ABC();

abc. doDiskAccess();

Sejauh ini baik. Sekarang katakanlah saya memiliki kelas lain yang terlihat seperti ini:

public class XYZ
{
   public void doNetworkAccess() {...}
}

Itu terlihat persis sama dengan ABC, tetapi katakanlah itu berfungsi melalui jaringan bukan pada disk. Jadi sekarang mari kita menulis program seperti ini:

if(config.isNetwork()) new XYZ().doNetworkAccess();
else new ABC().doDiskAccess();

Itu bekerja, tapi agak sulit. Saya dapat menyederhanakan ini dengan antarmuka seperti ini:

public interface Runnable
{
    public void run();
}

public class ABC implements Runnable
{
   public void run() {...}
}

public class XYZ implements Runnable
{
   public void run() {...}
}

Sekarang kode saya dapat terlihat seperti ini:

Runnable obj = config.isNetwork() ? new XYZ() : new ABC();

obj.run();

Lihat seberapa bersih dan lebih sederhana untuk memahami itu? Kami baru saja memahami prinsip dasar pertama dari kopling longgar: abstraksi. Kunci dari sini adalah untuk memastikan bahwa ABC dan XYZ tidak bergantung pada metode atau variabel apa pun dari kelas yang memanggil mereka. Itu memungkinkan ABC dan XYZ menjadi API yang sepenuhnya independen. Atau dengan kata lain, mereka "dipisahkan" atau "longgar digabungkan" dari kelas induk.

Tetapi bagaimana jika kita membutuhkan komunikasi antara keduanya? Nah, maka kita dapat menggunakan abstraksi lebih lanjut seperti Model Peristiwa untuk memastikan bahwa kode induk tidak perlu dipasangkan dengan API yang telah Anda buat.

Maaf, tapi "kopling longgar" bukan masalah pengkodean, ini masalah desain. Istilah "pelonggaran longgar" terkait erat dengan keadaan "kohesi tinggi" yang diinginkan, berlawanan tetapi saling melengkapi.

Loose coupling berarti bahwa elemen desain individu harus dibangun sehingga jumlah informasi yang tidak perlu yang perlu mereka ketahui tentang elemen desain lainnya berkurang.

Kohesi tinggi adalah semacam "ikatan ketat", tetapi Kohesi tinggi adalah keadaan di mana elemen desain yang benar-benar perlu diketahui satu sama lain dirancang agar mereka bekerja bersama secara bersih dan elegan.

Intinya adalah, beberapa elemen desain harus mengetahui detail tentang elemen desain lainnya, sehingga mereka harus dirancang seperti itu, dan tidak secara tidak sengaja. Elemen desain lain tidak boleh tahu detail tentang elemen desain lain, jadi elemen itu harus dirancang dengan cara itu, sengaja, dan bukan secara acak.

Menerapkan ini dibiarkan sebagai latihan untuk pembaca :).

Kode digabungkan ketat bergantung pada implementasi konkret. Jika saya membutuhkan daftar string dalam kode saya dan saya menyatakannya seperti ini (di Jawa)

ArrayList<String> myList = new ArrayList<String>();

maka saya bergantung pada implementasi ArrayList.

Jika saya ingin mengubahnya menjadi kode yang digabungkan secara longgar, saya menjadikan referensi saya tipe antarmuka (atau abstrak lainnya).

List<String> myList = new ArrayList<String>();

Ini mencegah saya memanggil metode apa punmyList yang khusus untuk implementasi ArrayList. Saya terbatas hanya pada metode-metode yang didefinisikan dalam antarmuka Daftar. Jika nanti saya memutuskan bahwa saya benar-benar membutuhkan LinkedList, saya hanya perlu mengubah kode saya di satu tempat, tempat saya membuat Daftar baru, dan bukan di 100 tempat di mana saya membuat panggilan ke metode ArrayList.

Tentu saja, Anda dapat membuat Instanate ArrayList menggunakan deklarasi pertama dan menahan diri dari tidak menggunakan metode apa pun yang bukan bagian dari antarmuka Daftar, tetapi menggunakan deklarasi kedua membuat kompilator membuat Anda jujur.

Tingkat perbedaan antara jawaban di sini menunjukkan mengapa itu akan menjadi konsep yang sulit untuk dipahami tetapi untuk membuatnya sesederhana yang saya bisa gambarkan:

Agar saya tahu bahwa jika saya melempar bola kepada Anda, maka Anda dapat menangkapnya, saya benar-benar tidak perlu tahu berapa usia Anda. Saya tidak perlu tahu apa yang Anda makan untuk sarapan, dan saya benar-benar tidak peduli siapa orang pertama yang Anda sukai. Yang perlu saya ketahui adalah Anda bisa menangkapnya. Jika saya tahu ini, maka saya tidak peduli jika Anda, saya melemparkan bola kepada Anda atau saudara Anda.

Dengan bahasa non-dinamis seperti c # atau Java dll, kami menyelesaikan ini melalui Antarmuka. Jadi katakanlah kita memiliki antarmuka berikut:

public ICatcher
{
   public void Catch();
}

Dan sekarang katakanlah kita memiliki kelas berikut:

public CatcherA : ICatcher
{
   public void Catch()
   {
      console.writeline("You Caught it");
   }

}
public CatcherB : ICatcher
{
   public void Catch()
   {
      console.writeline("Your brother Caught it");
   }

}

Sekarang CatcherA dan CatcherB mengimplementasikan metode Catch, sehingga layanan yang membutuhkan Catcher dapat menggunakan keduanya dan tidak benar-benar peduli. Jadi layanan yang digabungkan secara ketat mungkin secara langsung memulai contoh yang tertangkap

public CatchService
{
   private CatcherA catcher = new CatcherA();

   public void CatchService()
   {
      catcher.Catch();
   }

}

Jadi CatchService dapat melakukan apa yang telah ditetapkan untuk dilakukan, tetapi menggunakan CatcherA dan akan selalu menggunakan CatcherA. Keras dikodekan, jadi tetap di sana sampai seseorang datang dan refactor itu.

Sekarang mari kita ambil opsi lain, yang disebut injeksi ketergantungan:

public CatchService
{
   private ICatcher catcher;

   public void CatchService(ICatcher catcher)
   {
      this.catcher = catcher;
      catcher.Catch();
   }
}

Jadi teman-teman yang berhubungan dengan CatchService dapat melakukan hal berikut:

CatchService catchService = new CatchService(new CatcherA());

atau

CatchService catchService = new CatchService(new CatcherB());

Ini berarti bahwa layanan Catch tidak digabungkan dengan CatcherA atau CatcherB.

Ada beberapa strategi lain untuk layanan kopling longgar seperti ini seperti penggunaan kerangka kerja IOC dll.

Anda dapat menganggap kopling (ketat atau longgar) sebagai jumlah usaha yang diperlukan untuk memisahkan kelas tertentu dari ketergantungannya pada kelas lain. Sebagai contoh, jika setiap metode di kelas Anda memiliki sedikit blok akhirnya di bagian bawah di mana Anda membuat panggilan ke Log4Net untuk mencatat sesuatu, maka Anda akan mengatakan kelas Anda sangat erat dengan Log4Net. Jika kelas Anda berisi metode pribadi yang disebut LogSomething yang merupakan satu-satunya tempat yang disebut komponen Log4Net (dan metode lain semuanya disebut LogSomething sebagai gantinya), maka Anda akan mengatakan bahwa kelas Anda secara longgar digabungkan ke Log4Net (karena itu tidak akan memakan banyak waktu upaya untuk mengeluarkan Log4Net dan menggantinya dengan yang lain).

Definisi

Pada dasarnya, kopling adalah seberapa banyak objek atau set objek tertentu bergantung pada objek lain atau set objek lain untuk menyelesaikan tugasnya.

Kopling Tinggi

Pikirkan mobil. Agar mesin menyala, kunci harus dimasukkan ke dalam kunci kontak, dihidupkan, bensin harus ada, percikan harus terjadi, piston harus menyala, dan mesin harus hidup. Bisa dibilang bahwa mesin mobil sangat digabungkan ke beberapa objek lainnya. Ini kopling tinggi, tapi itu bukan hal yang buruk.

Kopling longgar

Pikirkan kontrol pengguna untuk halaman web yang bertanggung jawab untuk memungkinkan pengguna memposting, mengedit, dan melihat beberapa jenis informasi. Kontrol tunggal dapat digunakan untuk membiarkan pengguna memposting informasi baru atau mengedit informasi baru. Kontrol harus dapat dibagi antara dua jalur yang berbeda - baru dan edit. Jika kontrol ditulis sedemikian rupa sehingga memerlukan beberapa jenis data dari halaman yang akan berisi itu, maka Anda bisa mengatakan itu terlalu tinggi digabungkan. Kontrol seharusnya tidak memerlukan apa pun dari halaman wadahnya.

Ini adalah konsep yang cukup umum, jadi contoh kode tidak akan memberikan gambaran keseluruhan.

Seorang pria di sini di tempat kerja berkata kepada saya, "pola seperti fraktal, Anda dapat melihatnya ketika Anda memperbesar sangat dekat, dan ketika Anda memperbesar jauh ke tingkat arsitektur."

Membaca halaman wikipedia singkat dapat memberi Anda kesan umum ini:

http://en.wikipedia.org/wiki/Loose_coupling

Sejauh contoh kode spesifik ...

Berikut adalah satu kopling longgar yang baru-baru ini saya kerjakan, dari hal-hal Microsoft.Practices.CompositeUI.

    [ServiceDependency]
    public ICustomizableGridService CustomizableGridService
    {
        protected get { return _customizableGridService; }
        set { _customizableGridService = value; }
    }

Kode ini menyatakan bahwa kelas ini memiliki ketergantungan pada CustomizableGridService. Alih-alih hanya langsung merujuk implementasi yang tepat dari layanan, itu hanya menyatakan bahwa itu memerlukan BEBERAPA implementasi dari layanan itu. Kemudian pada saat runtime, sistem menyelesaikan ketergantungan itu.

Jika tidak jelas, Anda dapat membaca penjelasan yang lebih rinci di sini:

http://en.wikipedia.org/wiki/Dependency_injection

Bayangkan bahwa ABCCustomizableGridService adalah implementasi yang ingin saya hubungkan di sini.

Jika saya memilih untuk, saya dapat menarik keluar dan menggantinya dengan XYZCustomizableGridService, atau StubCustomizableGridService tanpa perubahan sama sekali ke kelas dengan ketergantungan ini.

Jika saya mereferensikan ABCCustomizableGridService secara langsung, maka saya perlu melakukan perubahan pada referensi tersebut untuk bertukar dalam implementasi layanan lain.

Coupling berkaitan dengan dependensi antar sistem, yang bisa berupa modul kode (fungsi, file, atau kelas), alat dalam pipa, proses server-klien, dan sebagainya. Semakin tidak umum ketergantungannya, semakin "erat" mereka menjadi, karena mengubah satu sistem diperlukan mengubah sistem lain yang bergantung padanya. Situasi ideal adalah "lepas kopling" di mana satu sistem dapat diubah dan sistem yang bergantung padanya akan terus bekerja tanpa modifikasi.

Cara umum untuk mencapai kopling longgar adalah melalui antarmuka yang terdefinisi dengan baik. Jika interaksi antara dua sistem didefinisikan dengan baik dan ditaati di kedua sisi, maka akan lebih mudah untuk memodifikasi satu sistem sambil memastikan bahwa konvensi tidak rusak. Ini biasanya terjadi dalam prakteknya bahwa tidak ada antarmuka yang ditetapkan dengan baik, menghasilkan desain yang ceroboh dan kopling ketat.

Beberapa contoh:

• Aplikasi tergantung pada perpustakaan. Di bawah kopling ketat, aplikasi istirahat pada versi lib yang lebih baru. Google untuk "DLL Hell".

• Aplikasi klien membaca data dari server. Di bawah kopling ketat, perubahan ke server memerlukan perbaikan di sisi klien.

• Dua kelas berinteraksi dalam hierarki Object-Oriented. Di bawah kopling ketat, perubahan ke satu kelas mengharuskan kelas lain diperbarui agar sesuai.

• Beberapa alat baris perintah berkomunikasi dalam pipa. Jika dipasangkan dengan erat, perubahan ke versi satu alat baris perintah akan menyebabkan kesalahan pada alat yang membaca hasilnya.

Coupling mengacu pada bagaimana kelas yang sangat berbeda terhubung satu sama lain. Kelas berpasangan ketat mengandung banyak interaksi dan dependensi.

Kelas longgar digabungkan adalah sebaliknya dalam hal ketergantungan mereka satu sama lain dijaga agar tetap minimum dan sebagai gantinya bergantung pada antarmuka publik yang didefinisikan dengan baik satu sama lain.

Lego, mainan yang SNAP bersama-sama akan dianggap longgar digabungkan karena Anda hanya bisa menjepit potongan-potongan dan membangun sistem apa pun yang Anda inginkan. Namun, puzzle memiliki potongan-potongan yang SANGAT tergabung. Anda tidak dapat mengambil bagian dari satu puzzle (sistem) dan memasukkannya ke dalam puzzle yang berbeda, karena sistem (puzzle) sangat tergantung pada potongan yang sangat spesifik yang dibangun khusus untuk "desain" tertentu. Lego dibuat dengan cara yang lebih umum sehingga dapat digunakan di Rumah Lego Anda, atau di Lego Alien Man saya.

Referensi: https://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/

Dua komponen sangat digabungkan ketika mereka bergantung pada implementasi konkrit satu sama lain.

Misalkan saya memiliki kode ini di suatu tempat dalam suatu metode di kelas saya:

this.some_object = new SomeObject();

Sekarang kelas saya bergantung pada SomeObject, dan mereka sangat berpasangan. Di sisi lain, katakanlah saya memiliki metode InjectSomeObject:

void InjectSomeObject(ISomeObject so) { // note we require an interface, not concrete implementation
  this.some_object = so;
}

Kemudian contoh pertama hanya dapat menggunakan SomeObject yang disuntikkan. Ini berguna selama pengujian. Dengan operasi normal, Anda dapat menggunakan kelas-kelas yang berat, menggunakan basis data, menggunakan jaringan dll. Dengan kode yang dipasangkan dengan ketat Anda tidak dapat melakukannya.

Anda dapat membuat beberapa bagian dari easer kerja ini dengan menggunakan wadah injeksi ketergantungan. Anda dapat membaca lebih lanjut tentang DI di Wikipedia: http://en.wikipedia.org/wiki/Dependency_injection .

Terkadang mudah untuk mengambil ini terlalu jauh. Pada titik tertentu Anda harus membuat hal-hal yang konkret, atau program Anda akan kurang mudah dibaca dan dimengerti. Jadi gunakan teknik ini terutama pada batas komponen, dan ketahui apa yang Anda lakukan. Pastikan Anda memanfaatkan kopling longgar. Jika tidak, Anda mungkin tidak membutuhkannya di tempat itu. DI mungkin membuat program Anda lebih kompleks. Pastikan Anda melakukan tradeoff yang baik. Dengan kata lain, pertahankan keseimbangan yang baik. Seperti biasa saat mendesain sistem. Semoga berhasil!

Pertimbangkan aplikasi Windows dengan FormA dan FormB. FormA adalah formulir utama dan menampilkan FormB. Bayangkan FormB perlu mengirimkan data kembali ke induknya.

Jika Anda melakukan ini:

class FormA 
{
    FormB fb = new FormB( this );

    ...
    fb.Show();
}

class FormB 
{
    FormA parent;

    public FormB( FormA parent )
    {
        this.parent = parent;
    }     
}

FormB sangat erat digabungkan ke FormA. FormB tidak dapat memiliki induk selain dari tipe FormA.

Jika, di sisi lain, Anda memiliki FormB mempublikasikan acara dan meminta FormA berlangganan acara tersebut, maka FormB dapat mendorong data kembali melalui acara tersebut ke pelanggan apa pun yang dimiliki acara tersebut. Dalam hal ini, FormB bahkan tidak tahu itu berbicara kembali ke induknya; melalui sambungan longgar acara menyediakan itu hanya berbicara dengan pelanggan. Jenis apa pun sekarang bisa menjadi induk dari FormA.

rp

Dalam ilmu komputer ada arti lain untuk "lepas kopling" bahwa tidak ada orang lain yang diposting di sini, jadi ... Ini dia - semoga Anda akan memberi saya beberapa suara sehingga ini tidak hilang di bagian bawah tumpukan! SANGAT subjek jawaban saya termasuk dalam jawaban komprehensif untuk pertanyaan ...

Istilah "Loose Coupling" pertama kali memasuki komputasi sebagai istilah yang digunakan sebagai kata sifat mengenai arsitektur CPU dalam konfigurasi multi-CPU. Istilah lawannya adalah "kopling ketat". Loose Coupling adalah ketika CPU tidak berbagi banyak sumber daya yang sama dan Tight Coupling adalah ketika mereka melakukannya.

Istilah "sistem" dapat membingungkan di sini jadi tolong uraikan situasinya dengan cermat.

Biasanya, tetapi tidak selalu, banyak CPU dalam konfigurasi perangkat keras di mana mereka ada dalam satu sistem (seperti dalam kotak "PC" individu) akan digabungkan secara ketat. Dengan pengecualian beberapa sistem berperforma sangat tinggi yang memiliki subsistem yang benar-benar berbagi memori utama di seluruh "sistem", semua sistem yang dapat dibagi secara longgar digabungkan.

Istilah Tightly Coupled dan Loosely Coupled diperkenalkan sebelum CPU multi-threaded dan multi-core diciptakan, sehingga istilah ini mungkin memerlukan beberapa teman untuk sepenuhnya mengartikulasikan situasi saat ini. Dan, memang, hari ini orang mungkin memiliki sistem yang mencakup kedua jenis dalam satu sistem keseluruhan. Mengenai sistem perangkat lunak saat ini, ada dua arsitektur umum, satu dari masing-masing varietas, yang cukup umum ini harus familliar.

Pertama, karena pertanyaannya adalah apa, beberapa contoh sistem Loosely Coupled:

• VaxClusters
• Linux Clusters

Sebaliknya, beberapa contoh Tightly Coupled:

• Sistem operasi Semetrical-Multi-Processing (SMP) - mis. Fedora 9
• CPU multi-utas
• CPU Multi-Core

Dalam komputasi hari ini, contoh-contoh dari keduanya yang beroperasi dalam satu sistem keseluruhan tidak jarang. Sebagai contoh, ambil Pentium dual atau quad core CPU modern yang menjalankan Fedora 9 - ini adalah sistem komputasi yang sangat erat. Kemudian, gabungkan beberapa dari mereka dalam Linux Cluster yang digabungkan secara longgar dan Anda sekarang memiliki komputasi yang digabungkan secara longgar dan erat! Oh, bukankah perangkat keras modern hebat!

Dalam bahasa yang sederhana, digabungkan secara longgar berarti tidak tergantung pada peristiwa lain yang terjadi. Ini dijalankan secara independen.

Beberapa jawaban panjang di sini. Prinsipnya sangat sederhana. Saya menyerahkan pernyataan pembukaan dari wikipedia :

"Kopling longgar menggambarkan hubungan yang kuat antara dua atau lebih sistem atau organisasi dengan semacam hubungan pertukaran.

Setiap ujung transaksi membuat persyaratannya eksplisit dan membuat beberapa asumsi tentang ujung lainnya. "

Saya mengusulkan Tes Kopling Kode yang sangat sederhana :

1. Bagian A dari kode secara erat digabungkan ke Bagian B dari kode jika ada modifikasi yang mungkin untuk Bagian B yang akan memaksa perubahan dalam Bagian A untuk menjaga kebenaran.

2. Bagian A dari kode tidak tergabung erat dengan Bagian B dari kode jika tidak ada modifikasi yang memungkinkan untuk Bagian B yang akan membuat perubahan ke Bagian A diperlukan.

Ini akan membantu Anda memverifikasi berapa banyak kopling yang ada di antara bagian-bagian kode Anda. untuk alasan yang melihat posting blog ini: http://marekdec.wordpress.com/2012/11/14/loose-coupling-tight-coupling-decoupling-what-is-that-all-about/

Ketika Anda membuat objek kelas menggunakan newkata kunci di beberapa kelas lain, Anda sebenarnya melakukan kopling ketat (praktik buruk) alih-alih Anda harus menggunakan kopling longgar yang merupakan praktik yang baik

--- A.java ---

package interface_package.loose_coupling;

public class A {

void display(InterfaceClass obji)
{
    obji.display();
    System.out.println(obji.getVar());
}
}

--- B.java ---

package interface_package.loose_coupling;

public class B implements InterfaceClass{

private String var="variable Interface";

public String getVar() {
    return var;
}

public void setVar(String var) {
    this.var = var;
}

@Override
public void display() {
    // TODO Auto-generated method stub
    System.out.println("Display Method Called");
}
}

--- InterfaceClass ---

package interface_package.loose_coupling;

public interface InterfaceClass {

void display();
String getVar();
}

--- MainClass ---

package interface_package.loose_coupling;

public class MainClass {

public static void main(String[] args) {
    // TODO Auto-generated method stub

    A obja=new A();
    B objb=new B();
    obja.display(objb);     //Calling display of A class with object of B class 

}
}

Penjelasan:

Dalam contoh di atas, kami memiliki dua kelas A dan B

Kelas B mengimplementasikan Interface yaitu InterfaceClass.

InterfaceClass mendefinisikan Kontrak untuk kelas B karena InterfaceClass memiliki metode abstrak kelas B yang dapat diakses oleh kelas lain misalnya A.

Di Kelas A kami memiliki metode tampilan yang dapat kecuali objek kelas yang mengimplementasikan InterfaceClass (dalam kasus kami ini adalah kelas B). Dan pada metode objek kelas A adalah memanggil display () dan getVar () kelas B

Dalam MainClass kita telah membuat objek Kelas A dan B. Dan memanggil metode tampilan A dengan melewatkan objek kelas B yaitu objb. Metode tampilan A akan dipanggil dengan objek kelas B.

Sekarang berbicara tentang kopling longgar. Misalkan di masa depan Anda harus mengubah nama Kelas B ke ABC maka Anda tidak harus mengubah namanya dalam metode tampilan kelas B, cukup buat objek baru (kelas ABC) dan berikan kepada metode tampilan di MailClass. Anda tidak perlu mengubah apa pun di Kelas A

ref: http://p3lang.com/2013/06/loose-coupling-example-using-interface/

Anda dapat membaca lebih lanjut tentang konsep generik "lepas kopling" .

Singkatnya, ini adalah deskripsi hubungan antara dua kelas, di mana masing-masing kelas tahu paling sedikit tentang yang lain dan masing-masing kelas berpotensi terus bekerja dengan baik apakah yang lain ada atau tidak dan tanpa ketergantungan pada implementasi tertentu dari yang lain. kelas.

Kopling longgar, secara umum, adalah 2 aktor yang bekerja secara independen satu sama lain pada beban kerja yang sama. Jadi, jika Anda memiliki 2 server web menggunakan database back-end yang sama, maka Anda akan mengatakan bahwa server web tersebut secara longgar digabungkan. Kopling ketat akan dicontohkan dengan memiliki 2 prosesor pada satu server web ... prosesor tersebut tergabung erat.

Semoga itu agak membantu.