尋找Force實驗4：Facade篇

Oct. 09 22:43~23:29

外牆是很重要滴。

***

今天來找Facade pattern的Force，依照慣例先把Intent改成Problem。

Intent

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

第一句話「Provide a unified interface to a set of interfaces in a subsystem」感覺像是solution，第二句話「Facade defines a higher-level interface that makes the subsystem easier to use」可以「聞到」一點點Problem的味道--就從這一句makes the subsystem easier to use改寫成第一版的Problem吧。

Problem：How do you use a subsystem?

中文：你如何使用一個子系統？

接下來看一下GoF書中Facade pattern的Motivation，看看能不能找到Force或是其他東西。

Motivation

Structuring a system into subsystems helps reduce complexity. A common design goal is to minimize the communication and dependencies between subsystems. One way to achieve this goal is to introduce a facade object that provides a single, simplified interface to the more general facilities of a subsystem.

上面這一段標示為藍色的字，看起來像是一個Force。

Force 1: You want to reduce dependencies between the subsystem and its client so that when the subsystem changes, the client will not be affected.

繼續看下去。

Consider for example a programming environment that gives applications access to its compiler subsystem. This subsystem contains classes such as Scanner, Parser, ProgramNode, BytecodeStream, and ProgramNodeBuilder that implement the compiler…(省略)

To provide a higher-level interface that can shield clients from these classes, the compiler subsystem also includes a Compiler class. This class defines a unified interface to the compiler's functionality. The Compiler class acts as a facade…(省略)

以上這兩段都在舉例子。

***

最後看一下Applicability。

Applicability

• you want to provide a simple interface to a complex subsystem. Subsystems often get more complex as they evolve. Most patterns, when applied, result in more and smaller classes. This makes the subsystem more reusable and easier to customize, but it also becomes harder to use for clients that don't need to customize it. A facade can provide a simple default view of the subsystem that is good enough for most clients. Only clients needing more customizability will need to look beyond the facade.
• there are many dependencies between clients and the implementation classes of an abstraction. Introduce a facade to decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability.
• you want to layer your subsystems. Use a facade to define an entry point to each subsystem level. If subsystems are dependent, then you can simplify the dependencies between them by making them communicate with each other solely through their facades.

***

Applicability推敲過程省略（應該沒什麼鄉民想知道吧 ），直接看Teddy所找出的Force，在這之前先把剛剛寫出的Problem列出來：

Problem: How do you use a subsystem?

Force:

• You want to reduce dependencies between the subsystem and its clients so that when the subsystem changes, the clients will not be affected.
• The subsystem should be as easy-to-use as possible.

***

不曉得鄉民們有沒有發現，Teddy在找Force的時候是先從比較簡單的pattern開始找起…XD，等哪一天GoF的23個pattern的Force第一版都整理好之後，就可以準備著手開始規劃《設計模式的逆襲》了。不過今天下午和指導教授聊了一下天，又再度被宣導「Problem Frame」的好處，讓Teddy有點小分心想要「轉台」到Problem Frame這個議題上面…Orz。今天原本是想要介紹Problem Frame的，後來想了一下，還是先幫Design Pattern「集氣」一下，不然太發散的話事情真的都要做不完拉。

***

友藏內心獨白：不過Problem Frame還是要找時間好好整理一下，對Product Owner的訓練會很有幫助滴。