- 抽象類與接口區別
- 語法上：抽象類：有屬性，可以有方法具體實現，子類必須實現父類的抽象方法 ；接口：接口只有方法定義，沒有屬性和方法實現
- 場景上：抽象類：is-a的關係，解決代碼重用問題；接口：has-a關係，爲了和代碼解耦，可以理解成一種協議
2.基於接口編程而不是實現編程
ImageStore image = new PrivateImageStore() 這種代碼如何避免
配置文件+反射/工程模式
- 爲什麼建議多用組合少用繼承
- 用組合、繼承、委託可以替代繼承（多態、代碼複用、is-a）
- 繼承層級過深不利於理解和擴展性和維護性
- vo、bo、Entity代碼很多重複，可以用組合方式或者繼承一個基類
- 業務上常用的基於貧血模式的MVC違反了OOP嗎？
- Repository+Service+Control這種數據和方法隔離的方式 典型的面向過程的編程方式，稱爲貧血模式：業務在Service，Bo只有數據沒有業務
- DDD(Domain Driven Design)領域驅動設計 充血模式:Domain 相當於貧血模式的Bo 不過同時包含業務和數據
- solid(單一責任制、開閉原則、裏式替換原則、接口隔離原則、控制反轉原則)
- 裏式替換：與多態相似，不同點在於裏式替換不能改變父類的邏輯
- 控制反轉：控制指的是對程序流程控制，反轉指的是本來由程序員控制整個流程，交給了程序去控制
依賴注入：編碼技巧，不在類裏面new方式去創建對象，而是在外面創建好，通過參數去傳遞
依賴注入框架
名詞解釋
Kiss原則：Keep it short And Simple 保持代碼簡單
YAGNI原則：You Ain't Gone Need it 不去編寫不需要的代碼
DRY原則: Don't Repeat YouSelf 不要編寫重複的代碼
- 改善代碼質量的建議
- 命名
- 長度：類名可以表達準確點，不簡寫，變量名可以簡寫點
- 利用上下文簡寫變量名： 比如 Class User ---> name 而不用userName
- 命名可讀可搜索：比如插入數據 用的是insertXXX 就不要再用addXXX
- 接口和抽象類命名 IUserService---->UserService 或 UserService----->UserServiceImpl 抽象類 AbstractConfiguration
- 註釋
註釋 why what how
維護註釋也需要成本
- 代碼風格
- 代碼行長度、類長度、函數長度 控制
- 類成員排列(靜態 public protected private)
- import導入排列 (按字母順序)
- 編碼技巧
- 排除複雜方法
- 不要用參數控制程序執行
- if else不要過多嵌套
- 程序出錯 返回：錯誤碼、NUll值、空對象、異常對象(吞掉，打印日誌；直接拋出，包裝拋出)
- 濫用get set 返回的集合(不可變)
- Constant和Utils不要設計大而全，修改一處，依賴的全部要重新編譯
