Structural Patterns要解決什麼問題(上)?

Nov. 22 16:00~18:00


在談完「Creational Patterns要解決什麼問題」之後（請參考《上集》、《中集》、《下集》），接下來分析一下structural pattern要解決的問題。延續之前在探討「Creational Patterns要解決什麼問題」的時候Teddy所想到兩個問題，將這兩個問題套用在structural pattern上面：

1. 這7個structural pattern到底是要解決什麼問題？
2. 它們之間的差別是什麼？

首先看一下GoF書中對於這7個structural pattern的Intent：

• Adapter: Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.
• Bridge: Decouple an abstraction from its implementation so that the two can vary independently.
• Composite: Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
• Decorator: Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
• Facade: Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.
• Flyweight: Use sharing to support large numbers of fine-grained objects efficiently.
• Proxy: Provide a surrogate or placeholder for another object to control access to it.

仔細一看這7個pattern的Intent都蠻像是Solution的，要找出這7個pattern所要解決的問題，就必須自己歸納一下。不過其實也不用自己歸納，在GoF的書中，有幫每一類的pattern做了一些分析比較，請翻開GoF第137頁的第一句：
Structural patterns are concerned with how classes and objects are composed to form larger structures.
把這句改寫一下應該就OK了。
Problem：How do you compose classes and objects to form larger structures? (你如何組織類別與物件以產生更大的結構?)
這個問題描述算是一個很一般化且共通的問題，可以適用於這7個structural pattern。但是，光是這樣不足以區隔這7個pattern，也就無法推導出針對這7個pattern，要採用哪種特定的Solution。請問鄉民，如果這7個pattern的問題都一樣，要如何區隔它們？如果有看過這系列文章的鄉民，這個問題的答案應該很清楚了：從個別pattern的Force可以演化出不同的Solution。

***

今天介紹第Adapter、Facade、Proxy這三個pattern的Force，是何種Force導致我們選擇不同的Solution。
使用Adapter

• 你想要使用一個已經存在的類別（且/或者包含這個類別的子類別），雖然這個類別在功能上符合你的需求，但是它的介面和你所期待的並不相容。
• 你想要設計可被重複使用的類別，希望這個類別可以跟不相關或是未知的其他類別一起合作。也就是說，你希望類別之間既使介面互不相容也可以一起合作。

使用Facade

• 你想要減少子系統與客戶端程式的相依性，如此一來當子系統內部改變的時候，它的客戶端將不會受到影響。
• 你希望子系統可以很容易地被使用。。

使用Proxy

• 你有一個功能已經實作完成的物件。
• 因為一些非功能面需求，例如減少記憶體使用、增加操作性能，可想要控制物件的產生、初始化、存取控制等cross-cutting concerns。如果直接修改原本的物件來加入這些控制將會違反基本的物件導向設計原則。
• 為了達到資訊隱藏，物件的客戶端應該不需要知道物件的內部實作。因此，不管物件是因為需要而及時被產生，或是物件是否位在本地端或是遠端這類的問題，客戶端應該不需要知道。

***

看完這三個pattern的force，再回頭思考原本的問題：你如何組織類別與物件以產生更大的結構？

• Adapter告訴鄉民們，若現有的類別或物件在功能上是符合所需的，只是因為介面與你所期待的並不相容，則可以藉由Adapter這個模式，來組織類別與物件，以便產生一個更大的結構。要如何藉由Adapter組織一個更大的結構，則是要參考Adapter的Solution，今天是探討Problem與Force，就不談Solution了 。
• Facade告訴鄉民們，你有一個子系統，現在有客戶端的程式想要使用這個子系統（所以你的系統結構變大了…這不是廢話嗎 ）。如果你希望客戶端程式不要受到子系統內部物件結構或關係改變的影響，而且希望客戶端程式可以很容易地使用這個子系統，則可以套用Facade。
• Proxy告訴鄉民們，有一個功能已經OK的物件，你希望對這個物件增加一些cross-cutting concerns的控制（例如物件產生、初始化、存取控制、保護等）。你最好不要直接去修改原本的物件，而是可以透過Proxy（增加一個新的類別），來達到這些控制的目的。這個Proxy會包含原本那個已經存在的物件，所以產生一個新的、更大的結構（這樣解釋會不會有點牽強 ）。

***

還是要再打一下廣告，「Design Patterns這樣學就會了：入門實作班」開課日期改到2013年1月19、20、26日（週六、日、六）。對設計模式有興趣的鄉民們可以參考一下 XD。

***

友藏內心獨白：最近可能會有很多置入性行銷的文章 。