基于Scala Trait的設計模式
在《作為Scala語法糖的設計模式》中，我重點介紹了那些已經融入Scala語法的設計模式。今天要介紹的兩個設計模式，則主要與Scala的trait有關。
Decorator Pattern
在GoF 23種設計模式中，Decorator Pattern算是一個比較特殊的模式。它充分利用了繼承和組合(或者委派)各自的優勢，將它們混合起來，不僅讓優勢擴大，還讓各自的缺點得到了抵消。Decorator模式的核心思想其實是“職責分離”，即將要裝飾的職責與裝飾的職責分離，從而使得它們可以在各自的繼承體系下獨立演化，然后通過傳遞對象(組合)的形式完成對被裝飾職責的重用。
從某種角度來講，裝飾職責與被裝飾職責之間的分離與各自抽象，不妨可以看做是Bridge模式的變種。但不同之處在于Decorator模式又額外地引入了繼承，但不是為了重用，而是為了多態，使得裝飾者因為繼承自被裝飾者，從而擁有了被裝飾的能力。所以說，繼承的引入真真算得上是點睛之筆了。
理解Decorator模式，一定要理解繼承與組合各自扮演的角色。簡而言之，就是：
- 繼承：裝飾者的多態
- 組合：被裝飾者的重用
正因為此，在Java代碼中實現Decorator模式，要注意裝飾器類在重寫被裝飾器的業務行為時，一定要通過傳入的對象來調用被裝飾者的行為。假設傳入的被裝飾者對象為decoratee，則調用時就一定是decoratee，而不是super(由于繼承的關系，裝飾類是可以訪問super的)。
例如BufferedOutputStream類作為裝飾類，要裝飾OutputStream的write行為，就必須這樣實現：
- public interface OutputStream {
- void write(byte b);
- void write(byte[] b);
- }
- public class FileOutputStream implements OutputStream { /* ... */ }
- public class BufferedOutputStream extends OutputStream {
- //這里是組合的被裝飾者
- protected final OutputStream decoratee;
- public BufferedOutputStream(OutputStream decoratee) {
- this.decoratee = decoratee;
- }
- public void write(byte b) {
- //這里應該是調用decoratee, 而非super，雖然你可以訪問super
- decoratee.write(buffer)
- }
- }
然而，在Scala中實現Decorator模式，情況卻有些不同了。Scala的trait既體現了Java Interface的語義，卻又可以提供實現邏輯(相當于Java 8的default interface)，并在編譯時采用mixin方式完成代碼的重用。換言之，trait已經***地融合了繼承與組合的各自優勢。因此，在Scala中若要實現Decorator模式，只需要定義trait去實現裝飾者的功能即可：
- trait OutputStream {
- def write(b: Byte)
- def write(b: Array[Byte])
- }
- class FileOutputStream(path: String) extends OutputStream { /* ... */ }
- trait Buffering extends OutputStream {
- abstract override def write(b: Byte) {
- // ...
- super.write(buffer)
- }
- }
在Buffering的定義中，根本看不到組合的影子，且在對write方法進行重寫時，調用的是super，這與我前面講到的內容背道而馳啊!
區別在于組合(delegation)的時機。在Java(原諒我，因為使用Scala的緣故，我對Java 8的default interface沒有研究，不知道是否與scala的trait完全相同)語言中，組合是通過傳遞對象方式完成的職責委派與重用，也就是說，組合是在運行時發生的。Scala的實現則不然，在trait中利用abstract override關鍵字來完成一種stackable modifications，這種方式被稱之為Stackable Trait Pattern。這種語法僅能用于trait，它表示trait會將某個具體類針對該方法提供的實現混入(mixin)到trait中。裝飾的客戶端代碼如下：
- new FileOutputStream("foo.txt") with Buffering
FileOutputStream的write方法實現在編譯時就被混入到Buffering中。所以可以稱這種組合為靜態組合。
Dependency Injection
Dependency Injection(依賴注入或者稱為IoC，即控制反轉)其實應該與依賴倒置原則結合起來理解，首先應該保證不依賴于實現細節，而是依賴于抽象(接口)，然后，再考慮將具體依賴從類的內部轉移到外面，并在運行時將依賴注入到類的內部。這也是Dependency Injection的得名由來。
在Java世界，多數情況下我們會引入框架如Spring、Guice來完成依賴注入(這并不是說依賴注入一定需要框架，嚴格意義上，只要將依賴轉移到外面，然后通過set或者構造器注入依賴，都可以認為是實現了依賴注入)，無論是基于xml配置，還是annotation，或者Groovy，核心思想都是將對象之間的依賴設置(裝配)轉交給框架來完成。Scala也有類似的IoC框架。但是，多數情況下，Scala程序員會充分利用trait與self type來實現所謂的依賴注入。這種設計模式在Scala中常常被昵稱為Cake Pattern。
一個典型的案例就是將一個Repository的實現注入到Service中。在Scala中，就應該將Repository的抽象定義為trait，然后在具體的Service實現中，通過Self Type引入Repository：
- trait Repository {
- def save(user: User)
- }
- trait DatabaseRepository extends Repository { /* ... */ }
- trait UserService {
- self: Repository =>
- def create(user: User) {
- //這里調用的是Repository的save方法
- //調用Self Type的方法就像調用自己的方法一般
- save(user)
- }
- }
- //這里的with完成了對DatabaseRepository依賴的注入
- new UserService with DatabaseRepository
Cake Pattern遵循了Dependency Inject的要求，只是它沒有像Spring或者Guice那樣徹底將注入依賴的職責轉移給外部框架，而是將注入的權利交到了調用者手里。這樣會導致調用端代碼并沒有完全與具體依賴解耦，但在大多數情況下，這種輕量級的依賴注入方式，反而更討人喜歡。
在Scala開發中，我們常常會使用Cake Pattern。在我的一篇文章《一次設計演進之旅》中，就引入了Cake Pattern來完成將ReportMetadata依賴的注入。
【本文為51CTO專欄作者“張逸”原創稿件，轉載請聯系原作者】
