38.3 雇工模式 38.3.1 雇工合作 我是一個富豪（當然只是想象中的），家里有很多傭人，家務活基本上不用我動手，我只要動動口就可以了，在這里每個人都有不同分工，我可以指揮廚師把廚房弄干凈，這是他的地盤；我可以指揮園丁把花園收拾干凈、漂亮，這是他應該做的；我還可以讓裁縫把我的衣服收拾干凈。注意看，我這里列舉出的三個對象（廚師、園丁、裁縫）都具有相同的功能：清潔。從另一方面說，廚房、花園、衣服都具有被清潔的特性，我們從這一例子入手，編寫代碼如代碼清單38-32所示。 代碼清單38-32 三個對象的被清潔特質 //可以被清潔的對象 public?interface?Cleanable?{ ?????//被清潔 ?????public?void?celaned(); } //花園 class?Garden?implements?Cleanable{ ?????public?void?celaned(){ ??????????System.out.println(“花園被清潔干凈”); ?????} } //廚房 class?Kitchen?implements?Cleanable{ ?????public?void?celaned(){ ??????????System.out.println(“廚房被清潔干凈”); ?????} } //衣服 class?Cloth?implements?Cleanable{ ?????public?void?celaned(){ ??????????System.out.println(“衣服被清潔干凈”); ?????} } 三個對象（廚房、花園、衣服）的共同特征抽取出來，同時也需要把廚師、裁縫、園丁的共同特征也抽象出來。從我這個主人的角度看來，他們三者都是清潔者，只是輸入的對象不同而已，如代碼清單38-33所示。 代碼清單38-33 抽象的清潔者 public?class?Cleaner?{ ?????//清潔 ?????public?void?clean(Cleanable?clean){ ??????????clean.celaned(); ?????} } 非常簡單，就這么一個清潔者就可以廚師、園丁、裁縫。我們再編寫一個場景類，描述一下發生了什么事，如代碼清單38-34所示。 代碼清單38-34 場景類 public?class?Client?{ ?????public?static?void?main(String[]?args)?{ ??????????//廚師清潔廚房 ??????????Cleaner?cookie?=?new?Cleaner(); ??????????cookie.clean(new?Kitchen()); ??????????//園丁清潔花園 ??????????Cleaner?gardener?=?new?Cleaner(); ??????????gardener.clean(new?Garden()); ??????????//裁縫清潔衣服 ??????????Cleaner?tailer?=?new?Cleaner(); ??????????tailer.clean(new?Cloth()); ?????} } 場景寫完了，運行一下，就可以看到廚師打掃了廚房，園丁清潔了花園，裁縫清潔了衣服。代碼很簡單，但是諸位有沒有發覺這和我們通常的分析是不同的。通常的做法是：既然廚師、園丁、裁縫都具有清潔的功能，那就定義一個接口描述三者的清潔功能，然后再定義三個類，分別代表廚師、園丁、裁縫實現這個接口。這是一種常用的解決辦法，可以解決該問題，但今天我們從另外一個側面進行分析，引出一個新的模式:雇工模式。 38.3.2 雇工模式的意圖 雇工模式也叫做仆人模式（Servant Design Pattern），其意圖是： 雇工模式是行為模式的一種，它為一組類提供通用的功能，而不需要類實現這些功能，它是命令模式的一種擴展[[1]](#)。 看看我們的例子，廚師、裁縫、園丁是一組類，都具有清潔的能力，但是我們卻沒實現，而是采用一種更優雅的方式來實現，這就是雇工模式。雇工模式的類圖如圖38-7所示。  圖38-7 雇工模式通用類圖 在類圖中，IServiced是用于定義“一組類”所具有的功能，其示例代碼如代碼清單38-35所示。 代碼清單38-35 通用功能 public?interface?IServiced?{ ?????//具有的特質或功能 ?????public?void?serviced(); } 針對不同的服務對象具備不同的服務內容，也就是具體的功能實現IServiced接口即可，示例代碼如代碼清單38-36所示。 代碼清單38-36 定義具體功能 public?class?Serviced1?implements?IServiced?{ ?????public?void?serviced(){?????????? ?????} } public?class?Serviced2?implements?IServiced{ ?????public?void?serviced(){?????????? ?????} } 功能定義完畢后，我們需要由一個雇工來執行這些功能。簡單地說，就是需要有一個執行者，可以把一組功能聚集起來，示例代碼如代碼清單38-37所示。 代碼清單38-37 雇工類 public?class?Servant?{ ?????//服務內容 ?????public?void?service(IServiced?serviceFuture){ ??????????serviceFuture.serviced(); ?????} } 在整個雇工模式中，所有具有IServiced功能的類可以實現該接口，然后由雇工類Servant進行集合，完成一組類不用實現通用功能而具有相應職能的目的。 38.3.3 最佳實踐 在日常的開發過程中，我們可能已經接觸過雇工模式，只是我們沒有把它抽取出來，也沒有匯編成冊。或許大家已經看出這與命令模式非常相似，讀者可以回顧第15章，會發現雇工模式是命令模式的一種簡化，但它更符合我們實際的需要，更容易引入開發場景中。 [[1]](#)原文是A behavioral pattern used to offer some functionality to a group of classes without defining that functionality in each of them。