1樓：
查了一些資料，補充一下：
其實不用太過糾結物件設計的是否符合OO，比如不是說User與Message是1v多關係，就一定要在User中加入List messages這樣的屬性來表示這種關係。
而要秉承幾個原則：
1.實現簡單且符合業務需求。2.模組化。3.靈活性。4.易於擴充套件。
比如在上面的User與Message這個1v多關係上，在業務中我們可能要經常的根據某個Message來找User，並且在Message中加入user這個屬性在OR實施中並不複雜、效能下降不多，那麼我我們的Message物件可以保留這樣的設計：
class
Message
但User中加入messages這個屬性，雖然看起來更OO了，因為它反映出了所謂的1對多關係，並且在實際業務中有需求。
class
User
2樓：者年
不僅僅是 OO 問題，而涉及工程問題，得分析看業務需求如何。
class
User
class
Message
3樓：仇偉佳
可以這麼分析，User和Message本身沒有那麼緊的聯絡，他們的關係不像Car和Wheel那麼緊密（經常看到的例子），所以只能說User和Message有關係而已，因此可以加乙個中間類UserMessage來表示這層關係. 然後在UserMessage裡加上各種Message相關的介面。
另外，也可以用MessageBox作為類名，看上去更直觀一些。
class User
class Message
class MessageBox
4樓：趙北雲
別人會告訴你這樣做的"結果"是什麼你需要自己判斷這個"結果"的益處是否是你需要的壞處是不是你能承受的然後做決定
別再想這種無聊的事情了
如何看待物件導向（OOD）的過度設計？
跟需求有很大關係。現在普遍承認oo程式設計在gui最終實現中還是有很大好處的。可以很大低降低使用複雜度。但伺服器端則不一樣，很多情況下僅僅需求乙個輸入乙個輸出，呼叫層次太多會造成效能降低和維護難度。而且一般呼叫間，相關度不高 會從設計上盡量分開，不用oo還簡單點。題主列舉的名人大多不是做ui的 沒有...
系統許可權設計的一些構想？
紅秀招 乙個需要流轉管理的系統，不論是給內部使用，還是合作夥伴用，都不可避免的遇到乙個問題 如何應對不同流轉過程的帳號及帳號對應的許可權設計 如果我們把流程寫死了，以應對乙個甲方，一旦產品需要拓展市場化，各個部門和合作關係，則需要靈活配置，以便軟體系統能夠應付。常用的帳號及許可權，市面上都已形成規範...
logo設計與VI設計都有一些什麼聯絡呢？
JChen 你好，我是專做品牌形象設計的耳田君，簡單說 VI系統包含LOGO 形象點比喻 VI就像人的整體外在形象，LOGO是人的臉。 柚嶼 舉個例子，就像你要做乙個VI手冊，開篇你就需要去介紹人家的logo，做個互動吧，你也要用人家logo，做Vi設計你大概率是逃不開要和人家的logo打交道。做個...