Pola Mediator di Jawa

1. Ikhtisar

Pada artikel ini, kita akan melihat Pola Mediator, salah satu pola perilaku Pemerintah Australia . Kami akan menjelaskan tujuannya dan menjelaskan kapan kami harus menggunakannya.

Seperti biasa, kami juga akan memberikan contoh kode sederhana.

2. Pola Mediator

Dalam pemrograman berorientasi objek, kita harus selalu mencoba mendesain sistem sedemikian rupa sehingga komponen dapat digabungkan secara longgar dan dapat digunakan kembali . Pendekatan ini membuat kode kita lebih mudah dipelihara dan diuji.

Namun, dalam kehidupan nyata, kita sering kali perlu berurusan dengan kumpulan objek dependen yang kompleks. Ini adalah saat Pola Mediator mungkin berguna.

Maksud dari Pola Mediator adalah untuk mengurangi kompleksitas dan ketergantungan antara objek yang digabungkan erat yang berkomunikasi langsung satu sama lain . Ini dicapai dengan membuat objek mediator yang menangani interaksi antara objek dependen. Akibatnya, semua komunikasi melalui mediator.

Ini mendorong kopling longgar, karena sekumpulan komponen yang bekerja bersama tidak lagi harus berinteraksi secara langsung. Sebaliknya, mereka hanya merujuk ke satu objek mediator. Dengan cara ini, juga lebih mudah untuk menggunakan kembali objek-objek ini di bagian lain dari sistem.

3. Diagram UML Pola Mediator

Sekarang mari kita lihat polanya secara visual:

Pada diagram UML di atas, kita dapat mengidentifikasi peserta berikut:

  • Mediator mendefinisikan antarmuka yang digunakan objek Rekan untuk berkomunikasi
  • Rekan mendefinisikan kelas abstrak yang memiliki satu referensi ke Mediator
  • ConcreteMediator merangkum logika interaksi antara objek Rekan
  • ConcreteColleague1 dan ConcreteColleague2 berkomunikasi hanya melalui Mediator

Seperti yang bisa kita lihat, objek Rekan tidak merujuk satu sama lain secara langsung. Sebaliknya, semua komunikasi dilakukan oleh Mediator .

Akibatnya, ConcreteColleague1 dan ConcreteColleague2 dapat digunakan kembali dengan lebih mudah.

Juga, jika kita perlu mengubah cara objek Rekan bekerja bersama, kita hanya perlu mengubah logika ConcreteMediator . Atau kita bisa membuat implementasi Mediator baru.

4. Implementasi Java

Sekarang kita memiliki gagasan yang jelas tentang teori tersebut, mari kita lihat contoh untuk lebih memahami konsep dalam praktiknya.

4.1. Contoh Skenario

Bayangkan kita sedang membangun sistem pendingin sederhana yang terdiri dari kipas angin, catu daya, dan tombol. Menekan tombol akan menghidupkan atau mematikan kipas angin. Sebelum kita menyalakan kipas angin, kita perlu menyalakan listriknya. Demikian pula, kita harus mematikan daya segera setelah kipas dimatikan.

Sekarang mari kita lihat contoh penerapannya:

public class Button { private Fan fan; // constructor, getters and setters public void press(){ if(fan.isOn()){ fan.turnOff(); } else { fan.turnOn(); } } }
public class Fan { private Button button; private PowerSupplier powerSupplier; private boolean isOn = false; // constructor, getters and setters public void turnOn() { powerSupplier.turnOn(); isOn = true; } public void turnOff() { isOn = false; powerSupplier.turnOff(); } }
public class PowerSupplier { public void turnOn() { // implementation } public void turnOff() { // implementation } }

Selanjutnya, mari kita uji fungsionalitasnya:

@Test public void givenTurnedOffFan_whenPressingButtonTwice_fanShouldTurnOnAndOff() { assertFalse(fan.isOn()); button.press(); assertTrue(fan.isOn()); button.press(); assertFalse(fan.isOn()); }

Semuanya sepertinya bekerja dengan baik. Namun perhatikan bagaimana kelas Button, Fan, dan PowerSupplier digabungkan erat . The Tombol beroperasi langsung pada Fan dan Fan berinteraksi dengan kedua Tombol dan PowerSupplier.

Akan sulit untuk menggunakan kembali kelas Tombol di modul lain. Juga, jika kita perlu menambahkan catu daya kedua ke dalam sistem kita, maka kita harus memodifikasi logika kelas Fan .

4.2. Menambahkan Pola Mediator

Sekarang, mari terapkan Pola Mediator untuk mengurangi ketergantungan antara kelas kita dan membuat kode lebih dapat digunakan kembali.

Pertama, mari perkenalkan kelas Mediator :

public class Mediator { private Button button; private Fan fan; private PowerSupplier powerSupplier; // constructor, getters and setters public void press() { if (fan.isOn()) { fan.turnOff(); } else { fan.turnOn(); } } public void start() { powerSupplier.turnOn(); } public void stop() { powerSupplier.turnOff(); } }

Selanjutnya, mari kita ubah kelas yang tersisa:

public class Button { private Mediator mediator; // constructor, getters and setters public void press() { mediator.press(); } }
public class Fan { private Mediator mediator; private boolean isOn = false; // constructor, getters and setters public void turnOn() { mediator.start(); isOn = true; } public void turnOff() { isOn = false; mediator.stop(); } }

Sekali lagi, mari kita uji fungsionalitasnya:

@Test public void givenTurnedOffFan_whenPressingButtonTwice_fanShouldTurnOnAndOff() { assertFalse(fan.isOn()); button.press(); assertTrue(fan.isOn()); button.press(); assertFalse(fan.isOn()); }

Sistem pendingin kami bekerja seperti yang diharapkan.

Sekarang setelah kita menerapkan Pola Mediator, tidak ada kelas Tombol , Kipas , atau PowerSupplier yang berkomunikasi secara langsung . Mereka hanya memiliki satu referensi ke Mediator.

Jika kami perlu menambahkan catu daya kedua di masa mendatang, yang harus kami lakukan hanyalah memperbarui logika Mediator ; Kelas tombol dan Fan tetap tidak tersentuh.

Contoh ini menunjukkan betapa mudahnya kita dapat memisahkan objek dependen dan membuat sistem kita lebih mudah dipelihara.

5. Kapan Menggunakan Pola Mediator

The Mediator Pattern is a good choice if we have to deal with a set of objects that are tightly coupled and hard to maintain. This way we can reduce the dependencies between objects and decrease the overall complexity.

Additionally, by using the mediator object, we extract the communication logic to the single component, therefore we follow the Single Responsibility Principle. Furthermore, we can introduce new mediators with no need to change the remaining parts of the system. Hence, we follow the Open-Closed Principle.

Sometimes, however, we may have too many tightly coupled objects due to the faulty design of the system. If this is a case, we should not apply the Mediator Pattern. Instead, we should take one step back and rethink the way we've modeled our classes.

Seperti semua pola lainnya, kami perlu mempertimbangkan kasus penggunaan khusus kami sebelum menerapkan Pola Mediator secara membabi buta .

6. Kesimpulan

Di artikel ini, kita belajar tentang Pola Mediator. Kami menjelaskan masalah apa yang dipecahkan pola ini dan kapan kami harus benar-benar mempertimbangkan untuk menggunakannya. Kami juga menerapkan contoh sederhana dari pola desain.

Seperti biasa, contoh kode lengkap tersedia di GitHub.