我的問題太奇怪了,我現在想不出更好的標題。無論如何,我正在尋找一種方法來命名 2 個類,但無法弄清楚什么是最好的前進方式。我明白這是一個基于意見的問題,但我堅持這個......所以我很感激對此的任何意見項目:A -> 類名:Call(這個類將代表從一部電話到另一部電話的呼叫)其他類可能/可能不會子類化這個特定類,如果是這樣,這些子類的名稱可能會以某種方式與父類相關(CallState 、CallEndPoint、CallSomething)。這個類不會知道數據庫的存在,可以說這個類將是通用電話驅動程序的一部分。項目:B -> 類名:調用?(這將代表數據庫中的實際表。該表將包含有關呼叫的一些信息,例如呼叫 ID、進入系統的時間等,以及可能/可能與呼叫無關的其他信息)。此類將本質上用作 RowMapper?,F在,這兩個項目很可能會合并在一起,如果我將這些類命名為相同的名稱,那么我最終會在一個項目中得到 2 個相同名稱的類,用于 2 個不同的目的?,F在,如果我是唯一一個構建此應用程序的人,我可能會消化這一點,但是如果多人開始在該應用程序上工作,那么其他人就會感到困惑,尤其是如果更多的類將遵循相同的模式。
2 回答

慕娘9325324
TA貢獻1783條經驗 獲得超4個贊
現在,這兩個項目很可能會合并在一起,如果我將這些類命名為相同的名稱,那么我最終會在一個項目中得到 2 個相同名稱的類,用于 2 個不同的目的。
當在同一個應用程序中,兩個具有不同職責/數據的類需要具有相同的簡單名稱(即沒有包)時,您確實應該將其視為需要考慮并且很可能修復的東西。
當然,您可以在不同的包中定義這些類,但它真的能解決您的問題嗎?我不認為。它會使事情變得不那么清楚,因為客戶端代碼可能會使用錯誤的代碼,并且每次開發人員操作/讀取Call
代碼時,他們都必須想知道他們當前正在應對“哪個調用”。
今天你有兩個截然不同的Call
. 有了如此寬松的命名約定,為什么將來不使用新的命名約定呢?
真的,這不是個好主意。
問題的根源在于您設計應用程序的方式。
您將模型分為兩個部分:一個類中的不可知持久性部分和另一個類中的數據持久性部分。這是一個選擇(我個人避免這樣做),但如果你做出這個選擇,你必須堅持到底:用不同的名字清楚地區分每個班級。此選項必須可見,不能僅隱藏在包名稱中。
例如: Call (domain) and CallEntity (persistence)
或以相反的方式CallDTO(domain) and Call(persistence)
添加回答
舉報
0/150
提交
取消