※ 引述《wong0101 (wong0101)》之銘言：
: 最近在碰android的source code,
: 發現很多class的命名都有相似之處,
: 例如: xxxManager, xxManagerService, Policy, Utilities..等
: 感覺這些class做的事情有一定的相似之處
: 例如:
: xxManagerService在整個android環境中只有一個實例(嗎?)
: Utilities會放一些常用的static方法(嗎?)
: 我想請教的是
: (1)上述舉例的這些類別(xxxManager, xxManagerService, Policy, Utilities)
: 他們有什麼樣的共同特性呢?讓我們能根據命名知道這個class的功用
: (2)另外還有什麼樣的命名方式是我上面沒舉例到的呢
: 先謝謝大家了~
這跟 java 的 Design Pattern 有關係
以資料庫存取來說
就會分為三類 Entity, DAO, Service
命名規則則是
Entity = TableName
DAO = TableNameDAO
Service = TableNameService
而各自負責的工作分別是
Entity 為 Table 的實體資料物件
DAO 為存取資料的窗口
Service 則是做中間的邏輯判斷, DAO 之間的交流以及其他各式處理
而你的 Controller 只要負責呼叫 Service 取得你要的資料即可
而由以上範例你可以發現
Service 就是負責主要的邏輯處理
不論是從網路撈資料還是從檔案或資料庫
都會在這邊處理為一個物件後 回傳給 Controller
再由 Controller 分配給某個 View 進行處理然後顯示
再說得簡單一點
其實就是一種讓開發者之間可以更好的交流程式碼的一種設計方法
所謂的交流最重要的就是 交接!!!!!!
至少你看名稱就知道那個東西可能在做些什麼
所以程式設計師有80%的時間在想名字要怎麼取(!?)
但其實要遵守 Design Pattern 不靠自動化工具還滿花時間的
有時候我自己也是 阿~ 隆吼哩啦~ 程式碼隨便丟
不過最後都會後悔為什麼當初不照著做 然後認命慢慢搬
若要深入的瞭解這一方面
可以找找看主流的 java design pattern
除了我上面提到的資料庫存取以外還有很多
例如 Builder, Null Object 等等
這方面如果公司有前輩帶會學得比較快 觀念也會比較清楚
像我都是自己慢慢 Google 學得就比慢 觀念也很雜
至於要不要照著做就是看你自己了
畢竟很多 Design Pattern 主要還是針對維護方面
不論是減少 Debug 的難度還是加速 Debug 的速度
一開始難免會影響開發速度
但這種事情是先苦後甘啦
除非你 Coding 完就離職 然後對公司懷有恨意
不過最後悽慘的也是接手的人而不是公司就是了