Live a simple life

@rain2sunny
站內發個消息給我，咱們聯系聯系！

招聘兼職？

@shinewang
你的帖子標題，“拉風”
你的帖子內容，“雷人”
你的跟貼，“鏢悍”

證明完畢！

類型初始化 VS 實例初始化 ^_^

1、首先確定是否是你說的缺少依賴的問題
2、簡單的插件依賴關系缺少，結合編譯錯誤稍微看一下應該就可以解決了
3、如果真的插件依賴關系比較復雜，可以借助Plug-in Dependencies視圖

@蔡超
挺準的^_^

代碼搞混了^_^ 不好意思！
已經更新了

關于初始化有兩個概念：類型初始化和實例初始化^_^

"但相同的HashCode一定產生相同的index，從而影響產生Hash沖突"
這句話比較有用

內容已經補充完畢，并更新了代碼，希望對大家有幫助

下一節內容：為我們的編輯器配置自定義即時校驗

下班了，先把源碼附上，里面有測試用test.tld

大學最重要是學好基礎課：C語言，數據結構，操作系統，有興趣也把匯編好好學學。
課余時間可以看看java之類的，做點小項目，練練手。


基礎課遠比后者重要！！！基礎好了，什么都好說

補充一副圖片

@srdrm
你要的內容補充完了

回答你最后一個問題吧，和SOA沒關系，概念包裝

馬上發布的6系列算是真正支持SOA，采用的是SCA、SDO規范


別被忽悠了

不要只觀察規則的jsp內容對應的document是怎樣的
也要看看不規則的（不符合jsp語法的）jsp內容對應的document是怎樣的

這很重要！！！直接影響后面你定制的行為是否健壯！！！

@Jack.Wang
看書（當然要是好書）和經驗缺一不可，看書有助于更好、更快的積累有價值的經驗，最后寫代碼的時候，發揮作用的肯定是經驗。

想靠自己的實踐積累出來一些經典書上面的結論，顯然有點高估自己了^_^ 但是實踐積累肯定能夠更好地理解書本內容，感覺有點不一樣了哈

剛寫這篇閑侃，比平時吃飯晚了10分鐘。 該吃過飯去小超時買煙，眼看著最后一包紅雙喜被另外一個哥們買去了，剩下的只有中華和幾種很爛的煙了。 思考再三，拿了包爛的

贊同樓主觀點，包的設計應該是在通用的設計原則的指導下完成

應該以很多個維度來綜合地看待這個問題，盡量考慮到各個規則（例如盡量分離抽象和實現，更好的遵循開閉原則....），不要和經典的規則發生沖突～_～

有的人可能更喜歡從技術視角進行劃分，例如可能會出現**.factory類型的包，里面放置了供用戶調用的工程類；有的人則可能更喜歡從業務角度進行劃分等。

大的原則是存在的，具體細節因人而異 ^_^。

路過 ^_^

@linuxer
你說的是一種辦法，在很多場景下可以這么做。我寫這篇隨筆的時候，就想集中精力來看一下一個行為封裝伴隨的上下文問題...

“大量的運算邏輯可放在瀏覽器端了”
怎么聽著有點懸乎的 ^_^

@tomay
謝謝你的指教

@隔葉黃鶯
哈哈。
回到實際，樓主文章中說的主題和異常配置也有點遠，覺得樓主好像意在說一個設計模式

過度倒是談不上。
Eclipse的絕對部分代碼都是要給用戶來使用或者擴展的，高質量的代碼和高超的設計實現是基礎，設計模式這個工具被它們用活了。很多時候，在調試代碼的時候，順便撒兩眼，都很長見識，設計模式用戶很活

看一下Eclipse本身代碼，再看一下WTP的源碼，差距就出來了～_～

新鮮，改天也玩玩

@隔葉黃鶯 @尋道者

一個框架給我們提供了服務的同時，肯定會給我們提供了相應的限制。我覺得，很多時候在決定要使用一個開源框架或者新的方法論（例如AOP）的時候，不但要看到框架的作用，也需要投入很大精力來分析一下框架的短板和限制。當然，是基于我們的需求來分析，如果脫離這一點，那就沒有意義了，純技術去分析一個框架可以當作閑來無事時的消遣～_～

@popoer
挺美好的想法

聽說過，而且還定制過它的源碼

@隔葉黃鶯
“尋道者”和你講的不是一個層面的問題。“尋道者”講的是設計模式，你說的框架使用。你這么比，樓主有可能會生氣。

@隔葉黃鶯
也斗膽接著聊一下你說的那個問題。從抽象層面講，我們如果想要處理一個行為的變化，一般需要干這幾件事情：
抽象變化，封裝變化
數據上下文
控制上下文

這種流行框架中的異常處理配置機制就真的好嗎，如果用戶想進行自定義的控制下文呢（例如摟主文中的）？？？如果數據上下文變化較為頻繁呢？？？（當然，這可能是由于起初對需求抽象不夠，對已知擴展沒有做詳細分析）

我們再切換到另外一個角度來看這個問題，任何一個框架肯定就是提供可復用的數據和行為。這種異常處理的配置機制暫且看作框架提供的行為支持吧。 那我可能會問了？我一個業務處理過程本身就包含了異常處理，我干嗎再去配啊，而且給我分開了，以后還要維護這個配置文件？？？

這種異常配置的機制有它的好處，也有它的適用場景，再一個那就是取決于開發者的嗜好....

@隔葉黃鶯:我只是有興趣瞎評論一下，錯誤請指正

更多的公共代碼的放置問題，骨架突出的成份小

被揭發之后才貼上去的，有什么意思呀，強烈鄙視此等虛偽。。。 ？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？


我可以負責任的講，我發的時候就注明了！！！ 而且是在文章的最開頭和簡介中都明確注明了！！！！！！！！！！如果你還有什么疑問，我可以給你他msn，這樣可以嗎？？？

如果你和我認識，有什么個人意見你可以當面跟我提！！！我博客上也有我的msn，你也可以在msn上面和我講。這種匿名人身攻擊沒什么意思的！！！請你自重！！！

原文的作者和我是同事，也是我現在參與的產品主架構師，很長一段時間我跟他學了不東西，非常尊重他

【Eclipse插件開發】引用：使用CommonNavigator開發資源管理器--基礎篇
【說明】
引用了組里一個架構師的一片文章，寫的很好的（尤其是里面看起來比較抽象、閑侃的部分）！！！


樓上的大哥看到了嗎？？？？？？？

@cheneystar
樓上說的很對的！

有些情況下Eclipse就是不編譯了，例如自動編譯選項開放，但是資源修改保存之后仍舊不編譯，查看所有的工程配置，都正常。

我原理遠程調試過這個問題，發現資源變化的時候，Eclipse不會去調build job了，具體當時沒有細看，大致猜測應該是Eclipse的工作區資源管理狀態出了問題。

解決這種問題，就是退出eclipse實例，然后eclipse -clean ..... 看運氣了，一般可以解決

類似的影響時間的場景還有不少，需要注意，例如：
1、關于流的使用。是否過于頻繁的使用了輸入流，例如我們的一個實例狀態依賴于底層的文件，而且這個對象被使用的非常頻繁，是否每次都需要去讀這個文件？？？可能引入一個簡單的時間戳，檢查一下，需要更新就去讀一次文件，然后更新一下實例狀態就ok了。還有需要頻繁使用輸出流輸出的場景下，是否考慮過簡單的切換成緩沖輸出流，就可以提高很多性能呢???
2、IWorkspaceRunnable使用，是否每次都需要鎖住整個工作區呢？？？
3、插件啟動類啟動代碼中是否干了過多的不必要的活呢？？？
4、是否過于頻繁的去查詢Eclipse的擴展注冊表呢？？？這可是個很龐大的樹性對象啊。。。

等等.................

鼓勵一把

java虛擬機對類加載本身就做了同步處理。！！！

同一個類加載器實例不可能對同一類型加載多次
不同的類加載器實例可能會對同一全名類型記載多次，那本質上是不同的類型了，類加載器實例一個很核心的作用就是來維護命名空間

@aaa
不能這么說。
樓主寫的可能過于抽象

繼續

@xxuu503
1、我的建議是用PDEUnit進行插件開發過程中的單元測試。但是有一個問題，那就是在對ui插件進行測試的時候，也會較為繁瑣，目前沒有看到什么特別出色的工具。基本上就是啟一個workbench或者使用鍵盤鉤子的技術

2、第二個問題當然沒有違反分層原則。其實，分層原則很廣泛：
基礎功能模塊和上層具體功能模塊分層
模塊ui和非ui部分進行分層
具體實現細節中注意分層思想，避免緊耦合

m之上可能有很多個c，針對的場景不一樣，v肯定是場景的一部分 ~_~

現在ext真的有點走紅了
最近看到不少產品中的web解決方案都用了ext

@mark
圖片放上去了

@polygoncell
不知道你寫了幾年代碼了

@polygoncell
我也只是和你打個比喻

繼承封裝變化....靜態能繼承嗎？
－－－－－－－－－簡單工廠（靜態工廠方法）和工廠方法的最本質區別

如果你真的有封裝變化的需求，那你用工廠方法問題不大。如果現有變化比較少，而且能夠預想到的擴展需求不大，就別用工廠方法了...


當然你可能有你特定的需求，而且也沒法三言兩句說的很清楚。說實在的，你的那個反射...什么什么的... 有點亂～_～


你的代碼是在使用工廠方法，但是這個創建過程有點煩瑣...不需要搞成這樣

“編碼中對“可預見性”的代碼結構適應，擴展接口預留”
個人覺得這種事情在編碼之前還是預先想一點的，至少從整體系統或者重點模塊的層面上大致想一下，否則，完全推遲到編碼時候再去做，那就有點懸了。除非項目組確實有幾個老道的高手，否則......就有點困難了

@BeanSoft
"OSGI 不過又是某些人炒作的新概念 或者說 尚未完善"

不能說單純的炒作新概念了，畢竟是一種不錯的組件化開發理論

尚未完善是真的。包括OSGI到底適應于那些場景等等，現在也都是人云亦云

記得《Java與模式》那本書中，有對java中多次分配的討論。

# re: 使用重構移除丑陋的if else代碼（5） 2008-08-04 18:46 polygoncell
@zhuxing

理論上來說，creation method也是可以的，不過這樣一來就導致Performer類和過多的其他類產生耦合（因為處理每一個狀態需要用到完全不同的類），我用factory就是為了保持performer干凈。要是一定要用creation method的話，performer都可以省了，直接寫一個復雜的enum，而每一個enum實例正好就是creation method。


大哥：只能說，俺長見識了！ ～_～

如果簡單針對樓主的代碼，個人覺得這么重構有點過了。

我提出置疑，針對的是：你用工廠方法模式的理由充分嗎？

我想強調兩點：
1、再仔細揣摩一下你的需求。是不是用個靜態方法（creation method）的方式更合理一些？
2、看一下你周圍的工作伙伴，這么寫會不會增大代碼的負責度？（這個問題的標準是有你的同伴來決定，不能自己判斷）


最后強調一下：
在學習模式導向重構的時候，看看最基本的重構技巧是否已經熟悉了。我看你那個getPerformers()方法，就有點難受。為什么要把if語句嵌套的那么深呢？？？