# 操作復雜對象結構——訪問者模式（一） 想必大家都去過醫院，雖然沒有人喜歡去醫院（愛崗敬業的醫務工作人員除外，微笑）。在醫生開具處方單（藥單）后，很多醫院都存在如下處理流程：劃價人員拿到處方單之后根據藥品名稱和數量計算總價，藥房工作人員根據藥品名稱和數量準備藥品，如圖26-1所示：  在圖26-1中，我們可以將處方單看成一個藥品信息的集合，里面包含了一種或多種不同類型的藥品信息，不同類型的工作人員（如劃價人員和藥房工作人員）在操作同一個藥品信息集合時將提供不同的處理方式，而且可能還會增加新類型的工作人員來操作處方單。 在軟件開發中，有時候我們也需要處理像處方單這樣的集合對象結構，在該對象結構中存儲了多個不同類型的對象信息，而且對同一對象結構中的元素的操作方式并不唯一，可能需要提供多種不同的處理方式，還有可能增加新的處理方式。在設計模式中，有一種模式可以滿足上述要求，其模式動機就是以不同的方式操作復雜對象結構，該模式就是我們本章將要介紹的訪問者模式。 26.1 OA系統中員工數據匯總 Sunny軟件公司欲為某銀行開發一套OA系統，在該OA系統中包含一個員工信息管理子系統，該銀行員工包括正式員工和臨時工，每周人力資源部和財務部等部門需要對員工數據進行匯總，匯總數據包括員工工作時間、員工工資等。該公司基本制度如下： (1) 正式員工(Full time Employee)每周工作時間為40小時，不同級別、不同部門的員工每周基本工資不同；如果超過40小時，超出部分按照100元/小時作為加班費；如果少于40小時，所缺時間按照請假處理，請假所扣工資以80元/小時計算，直到基本工資扣除到零為止。除了記錄實際工作時間外，人力資源部需記錄加班時長或請假時長，作為員工平時表現的一項依據。 (2) 臨時工(Part time Employee)每周工作時間不固定，基本工資按小時計算，不同崗位的臨時工小時工資不同。人力資源部只需記錄實際工作時間。 人力資源部和財務部工作人員可以根據各自的需要對員工數據進行匯總處理，人力資源部負責匯總每周員工工作時間，而財務部負責計算每周員工工資。 Sunny軟件公司開發人員針對上述需求，提出了一個初始解決方案，其核心代碼如下所示： ``` import java.util.*; class EmployeeList { private ArrayList<Employee> list = new ArrayList<Employee>(); //員工集合 //增加員工 public void addEmployee(Employee employee) { list.add(employee); } //處理員工數據 public void handle(String departmentName) { if(departmentName.equalsIgnoreCase("財務部")) //財務部處理員工數據 { for(Object obj : list) { if(obj.getClass().getName().equalsIgnoreCase("FulltimeEmployee")) { System.out.println("財務部處理全職員工數據！"); } else { System.out.println("財務部處理兼職員工數據！"); } } } else if(departmentName.equalsIgnoreCase("人力資源部")) //人力資源部處理員工數據 { for(Object obj : list) { if(obj.getClass().getName().equalsIgnoreCase("FulltimeEmployee")) { System.out.println("人力資源部處理全職員工數據！"); } else { System.out.println("人力資源部處理兼職員工數據！"); } } } } } ``` 在EmployeeList類的handle()方法中，通過對部門名稱和員工類型進行判斷，不同部門對不同類型的員工進行了不同的處理，滿足了員工數據匯總的要求。但是該解決方案存在如下幾個問題： (1) EmployeeList類非常龐大，它將各個部門處理各類員工數據的代碼集中在一個類中，在具體實現時，代碼將相當冗長，EmployeeList類承擔了過多的職責，既不方便代碼的復用，也不利于系統的擴展，違背了“單一職責原則”。 (2)在代碼中包含大量的“if…else…”條件判斷語句，既需要對不同部門進行判斷，又需要對不同類型的員工進行判斷，還將出現嵌套的條件判斷語句，導致測試和維護難度增大。 (3)如果要增加一個新的部門來操作員工集合，不得不修改EmployeeList類的源代碼，在handle()方法中增加一個新的條件判斷語句和一些業務處理代碼來實現新部門的訪問操作。這違背了“開閉原則”，系統的靈活性和可擴展性有待提高。 (4)如果要增加一種新類型的員工，同樣需要修改EmployeeList類的源代碼，在不同部門的處理代碼中增加對新類型員工的處理邏輯，這也違背了“開閉原則”。 如何解決上述問題？如何為同一集合對象中的元素提供多種不同的操作方式？訪問者模式就是一個值得考慮的解決方案，它可以在一定程度上解決上述問題（解決大部分問題）。訪問者模式可以為為不同類型的元素提供多種訪問操作方式，而且可以在不修改原有系統的情況下增加新的操作方式。