Observer Pattern
The observer defines a one-to-many dependency between collaborating objects. The observer enables the partitioning of a system into observers that react when their subjects change state. It is used in many event-based systems to separate the event source from the event monitors. The observer design pattern is shown in Figure 3.5. The concrete observers attach themselves to the subject in a way that the subject knows which observers to notify when its state changes. The observers register themselves to the subjects in which they are interested. A subject may have multiple observers, and an observer may listen to several subjects. The update method may contain a flag, indicating which subject changed state in the case of a many-to-many relationship.
The problem with the standard observer pattern is that the type information gets lost if the subject or observer hierarchies are derived. A single observer does not know which subject subclass changed the state. There are, however, several special design patterns that solve the problem. Nevertheless, some of them are not applicable for Symbian OS environment because they require RTTI (run-time type indication) to work. RTTI can be seen as an extension to static (compile-time) type indication. It offers to the user information on
|
Subject | ||
|
Observer | ||
|
+<<abstract>>Attach() +<<abstract>>Detach() +<<virtual>>Notify() |
-> | |
|
+<<abstract>>Update() | ||
|
+<<virtual>>Attach() +<<virtual>>Detach() Concrete Observer Figure 3.5 Observer design pattern pointers and references, which is similar to the type information a compiler maintains during compiling. |
Post a comment