希望用物件表現出“某乙是某甲的代理人”，要怎樣表現其關係呢？
圖一、如何表達某乙是某甲的代理人？
圖二、代理關係(A)
圖二為最安全的表達方式，用簡單的 association 表示出委託人與代理人角色，這樣的表示方法如果用在概念傳達是有效的，但如果是實作的用途則明顯不足，人員與代理關係物件雖然有關聯性，但這樣的關聯要由誰維護？是人員要管理這兩條關聯還是代理關係要維護？亦或是個別管理一組關聯性？如果是個別管理一組，那又是由誰管理委託人？由誰維護代理人？
圖三、代理關係(B)
圖三是利用具方向性的關聯來表達出代理關係，這種表達方式較為精確，除了能夠表達出代理關係的概念之外，也能清楚表示委託人與代理人之間的實作方式。
從實作層面看，委託人(人員)物件必須管理代理關係物件，而代理關係物件必須管理代理人(人員)物件，因此，委託人透過物件之間的關連性推演可以知道其代理人為何者，推演案例：某甲(委託人物件)代理關係物件某乙(代理人物件)。看到圖三的案例後，或許有些讀者會認為這就是表達某乙是某甲的代理人的標準答案，如果是以重新開發與設計的角度去看，也許是不錯的設計方案；請各位想想如果整個情境變成是在既有系統當中增加新的代理人機制，這樣的設計方案會有何種影響？
圖四、代理關係(C)
如果要在既有系統當中增加新的代理人機制，或許我們會採用圖四的案例，委託人與代理人物件都由代理關係去管理，實作過程中可以不用改寫人員物件，也可以達到擴充代理人機制的目標，不但可以增加人員物件重用(Reuse)的次數，也可以降低修改或重新開發程式的成本，可謂一舉數得。
一個問題可以有多種的解決方案，是不是覺得很有趣？還是你一直希望我能提供一個標準答案給你？看過了以上案例後，請各位讀者思考一番，或許你還可以找到更多的解決方案呢！
結語
這篇文章並不是要強調UML或者OOAD，也不希望各位誤以為這裡講的就是標準答案，不同的領域專家或許會有更好的見解！我要強調的是技術解決方案(Technical Solution)是因應需求而生，同樣的需求能衍生出不同的解決方案，有些方案易維護、有些方案可以有效降低建置成本…，了解需求、掌握需求才能提供適切的解決方案。
強力推薦：敏捷溯模(Agile Modeling)
沒有留言:
張貼留言