最近看了一些項目代碼，了解了它得架構(gòu)和設(shè)計?；旧虾芘宸Ｒ驗檫@些代碼是幾年以前寫的。但是很多書中提到的模式，原則都得到了運(yùn)用。但是也有一些地方有不同看法，我覺得很多地方用得并不恰當(dāng)。
1. 濫用繼承。比如在類結(jié)構(gòu)中已經(jīng)用了模板模式，照理說子類按照需要覆蓋模板中的實(shí)現(xiàn)即可?？墒遣恢鲇诤畏N目的。有的子類卻是抽象的，需要從該抽象子類再次擴(kuò)展，導(dǎo)致繼承樹不必要的深。
2. 濫用接口。經(jīng)?？吹浇涌谥卸x了一堆的方法，而且該接口只有一種實(shí)現(xiàn)。這種接口純粹是擺設(shè)，這樣的接口根本不能指望它有穩(wěn)定性。實(shí)際情況是接口將隨著實(shí)現(xiàn)的改變而改變。你說要這樣的接口干嗎？
3. 喜歡抽象出框架，但是這些框架對于當(dāng)前的應(yīng)用來說真實(shí)不必要的復(fù)雜。事實(shí)上沒有增加重用，反而降低了代碼的可讀性。
4. 濫用工廠模式。大家不是覺得模式很難實(shí)際運(yùn)用嗎。真想用模式嗎？那還不簡單。給每個對象都定義一個工廠類不就的了嗎？說心里話，我真看不出那些工廠模式到底實(shí)現(xiàn)什么設(shè)計上的好處。
5. 抽象的能力不夠。在一個分頁的實(shí)現(xiàn)中。把查尋字符串抽象到了一個類中。正確的方法應(yīng)該是把查詢結(jié)果抽象出來。
項目在進(jìn)化的過程中很容易變得越來越難維護(hù)，畢竟很多不同的思想和不同人的代碼揉和到了一起。出現(xiàn)各種問題也是正常的。
希望在別的項目中能引以為戒。