Pola-Pola Perancangan/ Design Patterns

Observer Design Pattern

Imam Cholissodin, S.Si., M.Kom UBmail : imamcs@ub.ac.id | 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 Object-Oriented 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 Subject-nya.

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 masing-masing 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 : imamcs@ub.ac.id | Blog : http://imamcs.lecture.ub.ac.id