Teddy的NBear終于開始實現繼承，對我來說又多了一個真正可以探討問題的同行。但是Teddy沒有實現一類一實體的方案，這令我非常失望。我曾在這一方案上付出過太多的艱辛，是因為我知道這種方案的真正價值。在ER模型理論中，關鍵的元素就是實體和關系，對于實體來說，重要的子元素是屬性，屬性的共享可以催生抽象從而導致繼承。對于關系來講，關系包括基數關系、依賴關系和結構關系，其中最主要的結構關系就是特化/泛化關系，映射到OO就是繼承。在我的上一篇文章描述過這樣的關系。

前段時間交付了一個系統。由于該系統只是整個大系統中的第一個子系統，緊隨其后還有三個子系統。為了將每個子系統都公用的部分能夠方便抽取出來，所以采用了一個公共域。該公共域的主要功能是：

1.?????? 認證

2.?????? 權限及授權

3.?????? 日志

4.?????? 即時消息

于是就有了以下的設計(省略了日志部分和即時消息部分)：

這里有一個比較罕見的三元關聯關系：權限、區域和權限所有者。目前這里的區域是指行政區域，省、地市、區縣，等等，當然在設計上完全可以想象成一個任何的范圍對象，表示該權限在該范圍內才有效。而權限僅僅只是一個字符串標識，例如system.management.usermanagement就表示用戶管理權限，當然，權限不是一個動態概念，必須由系統需求來決定的，不過由于比較自由所以更容易維護。

相比之下權限所有者就比較復雜一點，包括兩大類：第一類是用戶，第二類是用戶組。同時用戶與用戶組又是關聯關系，而運行時每個用戶所執行的權限是用戶自己的權限加所在的用戶組的權限的并集。所以，第一層繼承是從權限所有者到用戶和用戶組的繼承。另外，用戶分做兩類：一類是本地用戶，即在系統內有效的用戶，由本系統認證；第二類是單點登錄用戶，或者稱為門戶用戶，與企業其他應用系統共享一套用戶認證。

日志系統比較復雜。除了登錄日志、異常日志外，所有的改動都要有記錄。所以，就有了從日志到登錄日志、異常日志、改動日志的繼承關系，同時也有了從改動日志到插入日志、編輯日志、刪除日志的繼承關系。

是否一定需要導入復雜的繼承關系？我認為是必不可少的。雖然有的人也采用沒有繼承關系的方案解決得很好，但是對后續的設計一定比我復雜很多。例如，用戶對象將會分散到系統的各個角落，對用戶的抽象令用戶對象不再關注認證方式和認證的信息。這符合我的原則：繼承關系存在的唯一理由就是關系共享導致的抽象。而日志的共享，是依據一個從業務實現和表現層所帶來的對抽象日志的管理。這就是：每一個日志被記錄后，受配置所控制，可以通過Email、SMS或者其他任何可以采用的方式即時向外發布。

系統運行一段時間以后，用戶希望將消息系統一日志結合起來，用戶可訂閱一些日志作為即時消息。這個提議非常好，立即被我接受。于是，我需要從用戶那里派生出一個GhostUser出來，將這個Ghost用戶與具體的日志進行關聯。當然，GhostUser是無法登錄的，僅僅是作為即時消息系統中的占位用戶。于是就有了以下的設計，呵呵，很容易看出來，以前的數據表不需要任何修改，如果用戶系統中有大量的實際數據，那么這次更新也就不會造成任何麻煩：

如果你采用單表，或者一個具體類一個表，能很清爽地解決么？

重復一下我以前文章中的論點：

1.單表實現的繼承是回避了繼承關系，事實上是采用其他的關系替代繼承關系，所以不要稱之為“單表實現繼承”；

2.每個具體表一張表實現的繼承在某種程序上實現了繼承，但是這種繼承的交通非常有限，不足以很靈活地處理復雜的關系。

轉載于:https://www.cnblogs.com/Barton131420/archive/2006/08/11/474127.html

總結

以上是生活随笔為你收集整理的再说继承关系的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。