尋找Force：Observer篇

Sept. 26 16:20~17:42

 

鄉民們還記得Teddy最近經常提到關於pattern的一個重要觀念，那就是pattern的六大元素：

1. Pattern Name：模式名稱，增加開發者的設計字彙。
2. Context：描述問題發生的地形地物。
3. Problem：描述問題本身。
4. Force：問題的限制或特性。
5. Solution：解決問題的方法。
6. Resulting Context：套用解決方案之後的結果。

不知道鄉民們看完之後會不會有一個問題：

奇怪，上面這六大元素怎麼跟GoF的Design Patterns這本書所描述的pattern很不一樣啊？

的確，除了Pattern Name相同，其他的五點都不同。看一下者兩者的對應關係（資料來源：http://www.c2.com/cgi/wiki?CanonicalForm）：

六大基本格式	GoF格式
Pattern Name	Pattern Name
NA	Also Known As
Problem	Intent
Context	Applicability
Forces	Motivation
Solution	Participants Structure Collaborations Implementation
	Sample Code
Resulting Context	Consequences
NA	Known Uses
NA	Related Patterns

***

今天Teddy要談的還是force的問題。依據Teddy之前上課的經驗，學員們對於force比較不容易掌握。如果有讀過GoF《Design Patterns》這本書的人可能會覺得很奇怪，書中沒有提到force啊？依據上面這個表，force在GoF的書中，相當於Motivation這一個段落。Teddy舉一個最常被使用的Observer pattern為例子，來看一下如何從GoF書中的Motivation段落找出force。

翻開《Design Patterns》第293-294頁。

Motivation

A common side-effect of partitioning a system into a collection of cooperating classes is the need to maintain consistency between related objects. You don't want to achieve consistency by making the classes tightly coupled, because that reduces their reusability.

這裡就找到第一個force：Achieving consistency by making the classes tightly coupled reduces their reusability.

翻成中文就是：為了達到狀態一致性而將物件緊密耦合在一起（你泥中有我，我泥中有你 XD），將會降低（個別）物件的重複使用性。

For example, many graphical user interface toolkits separate the presentational aspects of the user interface from the underlying application data [KP88, LVC89, P+88, WGM88]. Classes defining application data and presentations can be reused independently. They can work together, too. Both a spreadsheet object and bar chart object can depict information in the same application data object using different presentations. The spreadsheet and the bar chart don't know about each other, thereby letting you reuse only the one you need. But they behave as though they do. When the user changes the information in the spreadsheet, the bar chart reflects the changes immediately, and vice versa.

上面這一大段是解釋第一個force，所以直接忽略，繼續往下找。

This behavior implies that the spreadsheet and bar chart are dependent on the data object and therefore should be notified of any change in its state. And there's no reason to limit the number of dependent objects to two; there may be any number of different user interfaces to the same data.

這裡就找到第二個force：There is no reason to limit the number of dependent objects; there may be any number of different user interfaces to the same data.

翻成中文就是：無須限制資料相依物件的個數，因為可能有任意數量的物件都有興趣想要知道資料（狀態）。

接下來的說明內容其實已經有點像是solution的摘要了，應該也找不到其他force了。

The Observer pattern describes how to establish these relationships. The key objects in this pattern are subject and observer. A subject may have any number of dependent observers. All observers are notified whenever the subject undergoes a change in state. In response, each observer will query the subject to synchronize its state with the subject's state.

This kind of interaction is also known as publish-subscribe. The subject is the publisher of notifications. It sends out these notifications without having to know who its observers are. Any number of observers can subscribe to receive notifications.

***

結論，從Observer pattern的Motivation找到兩個force。

• 為了達到狀態一致性而將物件緊密耦合在一起（你泥中有我，我泥中有你 XD），將會降低物件的重複使用性。
• 無須限制資料相依物件的個數，因為可能有任意數量的物件都有興趣想要知道資料（狀態）。

再仔細思考一下，上面這兩個force，分別代表兩個non-functional requirement（或是說對於原本要解決問題的兩點限制） ：

• 重複使用性：由於Subject和Observer彼此之間是所謂的abstract coupling（請參考《亂談軟體設計（1）：Cohesion and Coupling》）關係，所以個別都有可能可以在不同的context中被重複使用。
• 可擴充性：可以有任意數量的Observer。

***

那麼，最後剩下一個問題：Observer pattern的solution是否有滿足上面這兩個force？要回答這個問題之前，再幫鄉民們回顧一下force的涵義：

• Force是問題的限制或特性。
• Force告訴我們為什麼模式所要解決的「問題」是一個真正的問題；為什麼這個問題很難，為什麼這個問題需要一個聰明的，甚至是違反直覺的解決方案。Force也是了解為何會採用此種解決方案（而非其他方案）的關鍵。
• The often contradictory considerations to be considered when choosing a solution to a problem. Each solution considers certain forces. It optimizes some and may totally ignore others. The relative importance of the forces is determined by the context.

看到這邊，突然想到，耶，Observer pattern所要解決的問題是什麼？查看上表，Problem在GoF的格式裡面是Intent，所以來看一下Observer的Intent：

Define a one-to-many dependency between objects so that when one objet changes state, all its dependents are notified and updated automatically.

耶，這個句子不是問句耶，怎麼可以稱作是一個問題呢？很簡單，把它改成問句不就好了：

How do you define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically?

Problem有了，接著請鄉民們自己看一下Observer pattern的solution，是否除了解決這個problem以外，也同時滿足了上面這兩個force？

 

這邊要請鄉民們稍微花點時間思考一下，如果僅有problem還沒有考慮上面這兩個force，你最後得到的solution，很可能就不是現在所看到Observer的這個樣子。所以force的確是「問題的限制或特性」，會影響最後採用何種solution。

***

友藏內心獨白：經過這樣的分析，任督二脈至少也該打 斷 通一脈了吧 XD。