Live a simple life

非常不同意樓主的內容

調試和寫代碼矛盾嗎？？？
沒有調試功能，代碼能寫的那邊流利嗎？？？如果你能，那你牛！
調試怎么會和編碼規范、設計扯的這么緊了？？？摟主的認識是這樣？？？
。。。
遇到高人了：代碼一次編寫就通過？？？連測試也通過了？？？

牛人天天牛，今天特別牛 ~_~

@鬼狗

是筆誤，因該是啟動類加載器，已經修改

@rainjacy:

你是？

個人覺得摟主文章里面對“開閉原則”的理解有點狹隘

首先，開閉原則本身重在強調系統真個框架在引入新擴展的時候能夠提供比較自然的擴展，外部使用的抽象層面的東西不需要做很大的改動。而且，從本質上將，開閉原則也有一定的成分是愿景，不然就不會將其提高到了OO編程5大原則之一了

其次，客戶端的調用代碼的需要改動，是不是據此就判斷是打破了開閉原則了。個人覺得不是這樣的。

估計樓主是在客戶端代碼里面包含了一定的選擇特定工廠的任務，覺得新工廠的進入，需要增加判斷語句，以便使用新的工廠實現。進一步延伸講，這只是一個客戶端，真正的系統中可能有很多很多的類似客戶端。如果講工廠的選擇操作做一個封裝，那多個客戶端選擇工廠的行為操作本身就可以進行封裝了，例如：
getFactory(int factoryID) {//...}


個人意見，僅供參考！

同時贊同樓上@LB評論的觀點

鼓勵一把！

@BlogJava的第一塊磚：

很不錯，說明了observer本質上是用來解藕的
美可能為了社會和諧，不想只便宜一個男的。

樓主的文章很跟形式，符合黨中央“建立和諧社會”的精神！

俺也遇到過entry沒有顯示寫入，訪問出問題了

寫的還是不錯的

ISP作為OO中5個最主要的設計原則之一，在實際運用的時候往往會在實現細節上面出問題，關鍵是如何管理窄接口對應實例的問題，核心是創建實例化任務的封裝。

以樓主的例子為例，樓主很好的利用的creation method（以靜態公共接口提供實例）的方式，很好的將目標接口對應實例創建和初始化進行了封裝，并和窄接口的使用客戶端進行了解藕。如果不是這樣，那么ISP的原則可能就在客戶端創建實例的過程中被扭曲了。

更負責一些的情況，可以果斷的采用工廠的方式提供實例。寧可稍微過度設計，也要堅決避免藕合。

1、不同的場景，會很大程度上決定使用的調優方法的差異
例如針對一個后臺分布式web應用進行調優和針對一個類似有IDE的產品進行調優就會有很大的不同。

2、目標性能瓶頸也很很大程度上決定調優方法的差異
例如你面臨的調整到底是時間占用的問題還是空間占用的問題

...



最后，很多時候開發人員需要對代碼進行時間占用的優化，可以使用很多工具進行監測，但是千萬別忘記一點，那就是簡單的時間戳作用可是很大的啊...

@BlueDavy
看了你一些回帖，支持你一把。

樓主現在在那個公司高就？

@yswift

yswift同志說的一針見血！

同意樓上（wxm ）說的，建議一般不要從語法的層面進行區分。

很關鍵的一個區別：接口更加靈活，同時能夠更好地支持動態擴展。例如，類之間的繼承結構體現出了一個中縱向的結構，而接口則可以橫向的切入。
再者，接口一般用來封裝一個抽象的主題，多表現在行為的變化封裝和擴展。



還有，我們在設計一個類型的時候，考慮兩件事情：
1、定義其責任，即對外提供的服務，并定義通信的規則。
2、如何創建和實現化改類型。

1解決了如何使用類型的問題，2解決了如何創建的問題。接口相比抽象類能更加自然的將兩者進行解耦，而且能夠明顯加大2的自由度，因為很多時候我們是用工廠的方式對外提供實例。

其實，很多的爭論點在如何放置公共功能的問題。其實很多牛人寫程序，很多時候很自然的運用Interface/Default Impl的方式，即：你定義了一個接口，順便提供一個相應的抽象類，提供一些默認的實現。

寫的挺不錯的，就是有點亂～_～
再重新組織一下思路

函數體挺大的啊...

條件斷點
異常斷點
類加載斷點
熱替換
....
這些應該是eclipse開發者經常使用到的

調試功能使用的熟練程度，也會從一定程度反應出一個開發人員的基本功。扎實的調試能力，對修復bug、研究新代碼、加速代碼編寫速度等都有很大的作用