Pola-Pola Perancangan/ Design Patterns Observer Design Pattern
Imam Cholissodin, S.Si., M.Kom UBmail :
[email protected] | Blog : http://imamcs.lecture.ub.ac.id
Outline Introduction to Observer General Example
Motivation for Using Example of the Problem Aspects of Observer Design
Generalized Structure Two Ways to Implement Updates General Implementation Benefits of the Observer Pattern Trouble Spots
Introduction to Observer • A Gang of Four (GoF) design pattern, salah satu pola yang dibahas dalam Desain Pattern : Elements of Reusable ObjectOriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. • Observer mendefinisikan kebergantungan antar objek dalam bentuk one-to-many atau many-to-many. • Ketika kondisi suatu objek mengalami perubahan, maka semua objek lain yang bergantung pada objek tersebut akan diperbarui secara otomatis. • Digunakan untuk penanganan event (event handling) di mana diperlukan konsistensi antara objek, misalnya Swing Framework untuk pengembangan GUI.
General Example Misalkan Anda memiliki beberapa data yang dapat ditampilkan dalam tabel, grafik batang atau pie chart. Perubahan data yang mendasari harus tercermin/tergambar dalam semua tiga tampilan tersebut. Di sinilah Observer Desain Pattern digunakan (sangat berguna).
Motivation for Using • Diperlukan untuk memelihara konsistensi antara obyek terkait ketika suatu sistem berisi kumpulan kelas yang saling bekerja sama. • Konsistensi ini tidak boleh dilakukan melalui kelas yang berhubungan sangat erat karena ini mengurangi usabilitas/penggunaan kembali dari kelas-kelas erat yang telah digabungkan. • Kebutuhan yang terukur. Di sini harus ada batasan yang jelas terkait dengan jumlah objek yang bergantung pada satu atau lebih dengan obyek lainnya.
Example of the Problem: •
Misalkan anda meng-coding sebuah aplikasi di mana stasiun cuaca (weather station) meng-update tiga obyek, yang satu menampilan kondisi saat ini (current conditions,), yang satunya lagi menghitung data secara statistik dari waktu ke waktu (up to date), dan satu lainnya yang membuat prakiraan (forecast).
•
Berikut ini adalah contoh pendekatan yang cukup jelas/ The Obvious Approach : public class WeatherData { [declarations and getters/setters diabaikan/dihilangkan] public void measurements changed(){ float temp = getTemperature(); float humidity = getHumidity(); float pressure = getPressure(); currentConditionsDisplay.update(temp, humidity, pressure); statisticsDisplay.update(temp, humidity, pressure); forecastDisplay.update(temp, humidity, pressure);
} } Elisabeth Freeman, Eric Freeman, Sierra, and Bates, Head First Design Patterns,O’Reilly 2004
Problems With The Obvious Approach public void measurementsChanged(){ float temp = getTemperature(); float humidity = getHumidity(); float pressure = getPressure(); currentConditionsDisplay.update(temp, humidity, pressure); statisticsDisplay.update(temp, humidity, pressure); forecastDisplay.update(temp, humidity, pressure);
} Problems base/ Permasalahan : • Bagian program yang cenderung berubah dijadikan satu dengan bagian program yang tidak mungkin berubah. • update() panggilan yang dikodekan untuk objek nyata, bukan type. • Perlu mengubah koding program jika pelanggannya (subscribers) berubah.
Observer akan mengatasi masalah ini
Three Major Aspects of Observer 1. The Subject, yang merupakan objek yang diamati. 2. The Observer, yang mengamati Subyek. 3. Hubungan antara 1 dan 2 :
Melampirkan (attach) / melepaskan (detach) atau Berlangganan (subscribe) / tidak berlangganan (unsubscribe) . Pembaruan (update).
Generalized Structure
Generalized Structure (cont.) • Subject ▫ Interface untuk ConcreteSubjects ▫ Membutuhkan implementasi untuk menyediakan setidaknya metode berikut : subscribe / attach. unsubscribe / detach. notify untuk semua observer dariperubahan kondisi yang ada.
• ConcreteSubject ▫ Mengimplementasikan antarmuka Subyek (Subject interface). ▫ Mengelola referensi (references) baik langsung atau tidak langsung dengan satu atau lebih ConcreteObservers. ▫ Terus melacak keadaannya (state) sendiri. ▫ Ketika terjadi perubahan keadaan (state), maka state tersebut akan mengirimkan pemberitahuan (notification) kepada semua Observers dengan memanggil (call) metode update() mereka.
Generalized Structure (cont.) Observer Interface untuk ConcreteObserver objects Membutuhkan suatu update method
ConcreteObserver Ini adalah objek yang sebenarnya (actual object) yang mengamati keadaan (state) ConcreteSubject tersebut. State yang dikelola harus selalu konsisten dengan keadaan Subjectnya. Mengimplementasikan metode update().
Generalized Structure (cont.)
Two Ways to Implement Updates • The Push Model ▫ Subject mengirimkan semua informasi yang diperlukan terkait apapun perubahan yang terjadi kepada semua Observers. ▫ memberi (pushes) informasi kepada Observer sebagai parameter dengan metode update(). ▫ Membutuhkan asumsi tentang apa yang Observers perlu tahu. ▫ Mungkin perlu untuk memberikan ijin berlangganan (subscription) untuk perubahan yang relevan saja, tetapi ini akan menambah kompleksitas dari progam.
• The Pull Model ▫ Subject mengirimkan indikasi kepada Observer bahwa perubahan telah terjadi. ▫ Observers menggunakan public methods dari Subject untuk melakukan query information yang mereka inginkan. ▫ Hal ini terserah dari Observer untuk menarik semua informasi yang diperlukan dari Subject dalam rangka untuk memberikan efek perubahan yang relevan. ▫ Subject membutuhkan beberapa asumsi tentang apa saja yang ingin diketahui oleh Observers.
General Implementation Subjects dapat melacak Observers melalui ArrayLists atau struktur data lainnya. Observers dapat melacak beberapa Subjects dan mendapatkan data yang berbeda dari masing-masing. Pull model menggunakan metode pembaruan yang mengambil referensi ke Subjects sebagai parameter. Subjects harus memicu (men-trigger) metode update ketika state-nya berubah.
General Implementation Metode yang mengubah keadaan (state) dengan memanggil (call) metode stateChanged() : public void notifyObservers(){ for(Observer o: observers) o.update();
} public void stateChanged(){ // do other things / melakukan hal-hal yang lainnya notifyObservers(); // do whatever else still needs doing / melakukan apa saja yang masih perlu dilakukan. } public void setMeasurements(arguments….) { // set instance variables first / mengatur variabel tingkat pertama stateChanged(); }
Simple Example: Swing Button With Listeners Swing JButtons adalah Subjects; Listeners adalah Observers JButton extends AbstractButton, suatu abstract class yang memerlukan methods to add and remove listeners, serta beberapa types of notify() methods. ActionListener mengharuskan pelaksana program (implementers) memiliki metode actionPerformed() (update()). Dapat menambahkan sebanyak listeners yang anda ingin terhadap JButton, selama mereka mengimplementasikan ActionListener.
Familiar Example: Swing Button With Listeners public class SwingObserverExample{ Jframe frame; [stuff omitted] public void go() { frame = new JFrame(); JButton button = new JButton("Should I do it?"); button.addActionListener(new AngelListener()); button.addActionListener(new DevilListener()); frame.getContentPane().add(BorderLayout.CENTER, button); [frame property code omitted] } // using inner classes in this very simple example class AngelListener implements ActionListener { public void actionPerformed(ActionEvent event) { System.out.println("Don't do it"); } } class DevilListener implements ActionListener { public void actionPerformed(ActionEvent event) { System.out.println("Come on, do it!"); } } } When we click the button, both listeners are notified and take action. Elisabeth Freeman, Eric Freeman, Sierra, and Bates, Head First Design Patterns,O’Reilly 2004, p. 73
Implementation in Java Java telah built-in untuk mendukung konsep Observer. java.util.Observable class dapat di-extended oleh Subject. java.util.Observer interface dapat diimplementasikan oleh kelas yang ingin mengamati (observe) Subject.
UML Diagram for Observable/Observer Classes
Methods in java.util.Observable Observable() Membuat Observable object(Subject) tanpa melakukan inisialisasi Observers.
setChanged() Mengindikasikan bahwa suatu Subject telah berubah dalam beberapa cara.
hasChanged() Returns True jika metode setChanged() sudah dipanggil kembali (recently) daripada metode clearChanged(). Returns False jika sebaliknya.
clearChanged() Menunjukkan bahwa objek ini telah melakukan pemberitahuan kepada semua observers terhadap perubahan-perubahan terbaru. Hal ini akan dilakukan call secara otomatis oleh metode notifyObservers().
countObservers() Mengembalikan jumlah objek yang Observing Subject.
Methods in java.util.Observable (cont.) addObserver(Observer o) Menambahkan Observer object dikirimkan ke daftar Observers untuk disimpan oleh Subject.
deleteObserver(Observer o) / deleteObservers() Menghapus Observer object yang dilalui atau semua Observer object dari masing-masing daftar Observers yang disimpan oleh Subject.
Methods in java.util.Observable (cont.) notifyObservers(Object arg) / notifyObservers() Jika suatu Subject telah berubah, metode ini memberitahu semua Observers dan kemudian memanggil metode clearChanged(). Ketika diberikan suatu arg sebagai parameter dalam pemanggilan fungsi, Observer dapat mengetahui mana saja atribut Subject yang telah berubah, jika sebaliknya Observer bisa diberikan notifikasi tanpa menentukan arg-nya.
Methods in java.util.Observer update(Observable o, Object arg) Dipanggil (called) ketika Subject telah berubah. o adalah Subject yang dimaksud/ bersangkutan, dan arg adalah argumen yang dapat dikirimkan untuk memberitahu Observer mana saja yang atribut Subject-nya telah berubah.
Limitations of Built-In Implementation Observable is a class, not an interface Tidak dapat menambahkan perilaku (behavior ) ke kelas nyata yang subclass-nya memiliki suatu perilaku yang lain dan berbeda. Karena tidak ada Observable interface, Anda tidak dapat membuat implementasi yang bekerja dengan Observer tetapi tidak termasuk subclass yang Observable.
Tidak dapat menulis/membentuk kelas lain yang memiliki suatu Observable (kelas yang dapat diamati) karena setChanged() yang ada bersifat protected.
Limitations of Built-In Implementation
Benefits of the Observer Pattern • Penghubung antara Subject dan Observer Objects. • Banyak Observers dapat ditambahkan ke Subject tanpa harus memodifikasi Subject. • Menggunakan kembali Subject tanpa perlu menggunakan kembali siapapun Observers mereka sebelumnya. Hal sebaliknya juga berlaku. • Subject mampu melacak daftar dari Observers. • Subject tidak perlu mengetahui kelas konkret Observers-nya, tetapi cukup hanya dengan mengimplementasikan masingmasing antarmuka Observer (Observer interface).
Trouble Spots • Harus memberikan banyak notifikasi jika Observers memperbarui klien/ pelanggan mereka sendiri atau jika mereka juga membuat perubahan terhadap Subject-nya. • Mengulangi pemberitahuan bila terjadi perubahan secara berurutan/ beruntun. • "Menggantung di referensi“/ “Dangling references” untuk Subjects atau Observers ketika salah satu jenis/tipenya dihapus secara manual dalam non-garbage collected environments. Maka diharuskan perlu memberitahu Observers ketika Subjects tersebut dihapus, dan sebaliknya. • keadaan subjek (Subject state) harus konsisten (self-consistent) sebelum memanggil (calling) notify(), terutama yang menggunakan Pull Model. • Harus berhati-hati untuk tidak melakukan push irrelevant information pada observers dengan Push Model. • Jika update() gagal, Observer tidak bisa mengetahui apakah informasi yang hilang tersebut penting ataukah tidak penting.
Terima kasih
Imam Cholissodin, S.Si., M.Kom Mail :
[email protected] | Blog : http://imamcs.lecture.ub.ac.id
