Java Design Pattern---observer pattern

One, the Observer pattern definition

The observer pattern is defined by:

Define a one-to-many dependency between objects so if one object changes state, all its dependents AER notified and Updated automatically.

Defines a one-to-many dependency between objects so that when an object changes state, all objects that depend on it are notified and automatically updated.

As shown (captured from Head first Design Patterns), it consists of four parts:

1. Subject are observed. is an interface or an abstract class that defines the duties that the observer must implement, and it must be able to add, cancel, and manage the observer and notify the Observer dynamically.

2. Observer Observer. After the observer receives the message, it updates the update operation and processes the received information.

3. ConcreteSubject the specific observed person. Define the business logic of the observer itself, and define which events are notified.

4. Concreteobserver specific observers. Each observer has its own processing logic in the manner in which the information is received and processed by different observers.

Second, the Observer model Advantage

An abstract coupling between the observer and the observer is very easy to expand, whether it is to increase the observer or the observer.

According to the principle of single responsibility, each class's responsibility is single, then how to concatenate each single responsibility into a real complex logical relationship, the observer pattern can play a bridge role.

The observer pattern is typical of loose coupling.

In the Android source code, one of the classic use of the Observer mode is the Android control's event listener model.

Three, the design principle and characteristic of the interactive event transmission of Android

An interactive event is a related event that is triggered when a user interacts with an application by means of a key, touch, swipe, and so on. With the Android control tree, interactive events are propagated from top to bottom along the control tree. A brief picture of the Android control tree is as follows:

When the parent control on the upper level of the control tree receives an interaction event, the target control object for the event is determined, and if the event is exactly what it needs, the event is intercepted for processing, otherwise an attempt is made to distribute the event down to the corresponding child control and propagate the event down the step down until the event is processed or ignored.

Android defines a series of event functions named view.on*** in the view class to receive and handle various types of interactive events, such as the ability to receive keystrokes from the user via the View.onkeydown function. Each child control that is derived from the view class can handle the events required by the control by overloading these event functions.

For example, if a control needs to handle the action of a user pressing a return key, it can be implemented by overloading the View.onkeydown function:

    /** @see android.app.activity#onkeydown (int, android.view.KeyEvent)*/    @Override Public BooleanOnKeyDown(IntKeyCode, KeyEvent event)  {   Listen and process return operations  if ( KeyCode == keyevent.  { dosomething  ();  return true;} return false }            /span>                

The return value of an event function is an important means of controlling event propagation. If the event function returns True, the control has received and completed the handling of the event without further passing the event, whereas if the event function returns FALSE, the control object could not handle the event (or, although it has been processed but still needs to be processed), You need to continue passing to find the control object that can handle it.
For container control ViewGroup, one of its duties is to propagate the interaction events into its child controls. For different events, ViewGroup can choose different modes of communication. For example, if it is a touch event, the ViewGroup object needs to determine which child control the region of the event occurred on, thereby assigning the event to the child control for processing. However, it is not flexible enough to handle event processing in an inherited manner, resulting in a large number of child control types appearing in the system, and the reusability of each control is poor. Therefore, "combination" is used instead of "inheritance". Based on this idea, the view class provides a series of matching event listener functions for the developer to handle the corresponding event, which has an event listener model that uses the observer pattern to complete the Android control. Developers can construct an event listener interface binding for an external observer object and a control object to obtain an event message.

Or, as an example of the above key event, the implementation of the listener's processing is as follows:

Final View.OnkeylistenerListener= New Onkeylistener() { @Override Public BooleanOnKey(ViewV, IntKeyCode, KeyEvent Event) { //Handling Return key events If(KeyCode== KeyEvent.Keycode_back) {DoSomething(); Return True; } return false; } }; ... muisetbutton =  (button   Findviewbyid (r.< Span class= "PLN" >id.// Bind the button to the Listener object muisetbutton setonkeylistener (listener    

By using external objects to handle interactive events, the coupling is low, so that each class control has a better reusability, and no new controls need to be constructed to handle the event.

IV. application of observer mode in Android source code

1. Look at the Onkeylistener interface in the view class source code:

    /*** Interface definition for a callback to being invoked when a key event was * dispatched to this view. The callback'll be invoked before the key * event was given to the view.*/    Public Interface Onkeylistener { /*** Called when a key was dispatched to a view. This allows listeners to * get a chance to respond before the target view. * * @param  V The View the key has been dispatched to. *  @param  KeyCode the code for the physical key is pressed *  @param  Event the key Event object containing full information about * the event. *  @return  True if the listener has consumed the event, false otherwise. */ boolean Onkey ( View V, int keycode< Span class= "pun" >, keyevent event }            /span>               

2. Look again the view class defines the private member Monkeylistener (by way of composition):

PrivateOnkeylistener monkeylistener;  

3. Register Listener

    /**     * Register A callback to being invoked when a key was pressed in this view.     @param l The key listener to attach to this view     */public void Setonkeylistener(  Onkeylistener l){= l;}          

4. The rest is left to the developer. Constructs an external observer object to bind to the event interface of the key to get the event message.

Finally, let us remember the design principles that underpin the "observer pattern": strive for loosely coupled designs between objects, that interact.

Reprinted from: http://www.cnblogs.com/yemeishu/archive/2013/01/05/2845561.html

Java Design Pattern---observer pattern