Live a simple life

@rain2sunny
站內(nèi)發(fā)個(gè)消息給我，咱們聯(lián)系聯(lián)系！

招聘兼職？

@shinewang
你的帖子標(biāo)題，“拉風(fēng)”
你的帖子內(nèi)容，“雷人”
你的跟貼，“鏢悍”

證明完畢！

類型初始化 VS 實(shí)例初始化 ^_^

1、首先確定是否是你說(shuō)的缺少依賴的問(wèn)題
2、簡(jiǎn)單的插件依賴關(guān)系缺少，結(jié)合編譯錯(cuò)誤稍微看一下應(yīng)該就可以解決了
3、如果真的插件依賴關(guān)系比較復(fù)雜，可以借助Plug-in Dependencies視圖

@蔡超
挺準(zhǔn)的^_^

代碼搞混了^_^ 不好意思！
已經(jīng)更新了

關(guān)于初始化有兩個(gè)概念：類型初始化和實(shí)例初始化^_^

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

內(nèi)容已經(jīng)補(bǔ)充完畢，并更新了代碼，希望對(duì)大家有幫助

下一節(jié)內(nèi)容：為我們的編輯器配置自定義即時(shí)校驗(yàn)

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

大學(xué)最重要是學(xué)好基礎(chǔ)課：C語(yǔ)言，數(shù)據(jù)結(jié)構(gòu)，操作系統(tǒng)，有興趣也把匯編好好學(xué)學(xué)。
課余時(shí)間可以看看java之類的，做點(diǎn)小項(xiàng)目，練練手。


基礎(chǔ)課遠(yuǎn)比后者重要?。?！基礎(chǔ)好了，什么都好說(shuō)

補(bǔ)充一副圖片

@srdrm
你要的內(nèi)容補(bǔ)充完了

回答你最后一個(gè)問(wèn)題吧，和SOA沒(méi)關(guān)系，概念包裝

馬上發(fā)布的6系列算是真正支持SOA，采用的是SCA、SDO規(guī)范


別被忽悠了

不要只觀察規(guī)則的jsp內(nèi)容對(duì)應(yīng)的document是怎樣的
也要看看不規(guī)則的（不符合jsp語(yǔ)法的）jsp內(nèi)容對(duì)應(yīng)的document是怎樣的

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

@Jack.Wang
看書（當(dāng)然要是好書）和經(jīng)驗(yàn)缺一不可，看書有助于更好、更快的積累有價(jià)值的經(jīng)驗(yàn)，最后寫代碼的時(shí)候，發(fā)揮作用的肯定是經(jīng)驗(yàn)。

想靠自己的實(shí)踐積累出來(lái)一些經(jīng)典書上面的結(jié)論，顯然有點(diǎn)高估自己了^_^ 但是實(shí)踐積累肯定能夠更好地理解書本內(nèi)容，感覺(jué)有點(diǎn)不一樣了哈

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

贊同樓主觀點(diǎn)，包的設(shè)計(jì)應(yīng)該是在通用的設(shè)計(jì)原則的指導(dǎo)下完成

應(yīng)該以很多個(gè)維度來(lái)綜合地看待這個(gè)問(wèn)題，盡量考慮到各個(gè)規(guī)則（例如盡量分離抽象和實(shí)現(xiàn)，更好的遵循開閉原則....），不要和經(jīng)典的規(guī)則發(fā)生沖突～_～

有的人可能更喜歡從技術(shù)視角進(jìn)行劃分，例如可能會(huì)出現(xiàn)**.factory類型的包，里面放置了供用戶調(diào)用的工程類；有的人則可能更喜歡從業(yè)務(wù)角度進(jìn)行劃分等。

大的原則是存在的，具體細(xì)節(jié)因人而異 ^_^。

路過(guò) ^_^

@linuxer
你說(shuō)的是一種辦法，在很多場(chǎng)景下可以這么做。我寫這篇隨筆的時(shí)候，就想集中精力來(lái)看一下一個(gè)行為封裝伴隨的上下文問(wèn)題...

“大量的運(yùn)算邏輯可放在瀏覽器端了”
怎么聽著有點(diǎn)懸乎的 ^_^

@tomay
謝謝你的指教

@隔葉黃鶯
哈哈。
回到實(shí)際，樓主文章中說(shuō)的主題和異常配置也有點(diǎn)遠(yuǎn)，覺(jué)得樓主好像意在說(shuō)一個(gè)設(shè)計(jì)模式

過(guò)度倒是談不上。
Eclipse的絕對(duì)部分代碼都是要給用戶來(lái)使用或者擴(kuò)展的，高質(zhì)量的代碼和高超的設(shè)計(jì)實(shí)現(xiàn)是基礎(chǔ)，設(shè)計(jì)模式這個(gè)工具被它們用活了。很多時(shí)候，在調(diào)試代碼的時(shí)候，順便撒兩眼，都很長(zhǎng)見識(shí)，設(shè)計(jì)模式用戶很活

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

新鮮，改天也玩玩

@隔葉黃鶯 @尋道者

一個(gè)框架給我們提供了服務(wù)的同時(shí)，肯定會(huì)給我們提供了相應(yīng)的限制。我覺(jué)得，很多時(shí)候在決定要使用一個(gè)開源框架或者新的方法論（例如AOP）的時(shí)候，不但要看到框架的作用，也需要投入很大精力來(lái)分析一下框架的短板和限制。當(dāng)然，是基于我們的需求來(lái)分析，如果脫離這一點(diǎn)，那就沒(méi)有意義了，純技術(shù)去分析一個(gè)框架可以當(dāng)作閑來(lái)無(wú)事時(shí)的消遣～_～

@popoer
挺美好的想法

聽說(shuō)過(guò)，而且還定制過(guò)它的源碼

@隔葉黃鶯
“尋道者”和你講的不是一個(gè)層面的問(wèn)題?！皩さ勒摺敝v的是設(shè)計(jì)模式，你說(shuō)的框架使用。你這么比，樓主有可能會(huì)生氣。

@隔葉黃鶯
也斗膽接著聊一下你說(shuō)的那個(gè)問(wèn)題。從抽象層面講，我們?nèi)绻胍幚硪粋€(gè)行為的變化，一般需要干這幾件事情：
抽象變化，封裝變化
數(shù)據(jù)上下文
控制上下文

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

我們?cè)偾袚Q到另外一個(gè)角度來(lái)看這個(gè)問(wèn)題，任何一個(gè)框架肯定就是提供可復(fù)用的數(shù)據(jù)和行為。這種異常處理的配置機(jī)制暫且看作框架提供的行為支持吧。 那我可能會(huì)問(wèn)了？我一個(gè)業(yè)務(wù)處理過(guò)程本身就包含了異常處理，我干嗎再去配啊，而且給我分開了，以后還要維護(hù)這個(gè)配置文件？？？

這種異常配置的機(jī)制有它的好處，也有它的適用場(chǎng)景，再一個(gè)那就是取決于開發(fā)者的嗜好....

@隔葉黃鶯:我只是有興趣瞎評(píng)論一下，錯(cuò)誤請(qǐng)指正

更多的公共代碼的放置問(wèn)題，骨架突出的成份小

被揭發(fā)之后才貼上去的，有什么意思呀，強(qiáng)烈鄙視此等虛偽。。。 ？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？


我可以負(fù)責(zé)任的講，我發(fā)的時(shí)候就注明了?。。?而且是在文章的最開頭和簡(jiǎn)介中都明確注明了！?。。。。。。。。∪绻氵€有什么疑問(wèn)，我可以給你他msn，這樣可以嗎？？？

如果你和我認(rèn)識(shí)，有什么個(gè)人意見你可以當(dāng)面跟我提?。?！我博客上也有我的msn，你也可以在msn上面和我講。這種匿名人身攻擊沒(méi)什么意思的?。?！請(qǐng)你自重?。。?

原文的作者和我是同事，也是我現(xiàn)在參與的產(chǎn)品主架構(gòu)師，很長(zhǎng)一段時(shí)間我跟他學(xué)了不東西，非常尊重他

【Eclipse插件開發(fā)】引用：使用CommonNavigator開發(fā)資源管理器--基礎(chǔ)篇
【說(shuō)明】
引用了組里一個(gè)架構(gòu)師的一片文章，寫的很好的（尤其是里面看起來(lái)比較抽象、閑侃的部分）！??！


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

@cheneystar
樓上說(shuō)的很對(duì)的！

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

我原理遠(yuǎn)程調(diào)試過(guò)這個(gè)問(wèn)題，發(fā)現(xiàn)資源變化的時(shí)候，Eclipse不會(huì)去調(diào)build job了，具體當(dāng)時(shí)沒(méi)有細(xì)看，大致猜測(cè)應(yīng)該是Eclipse的工作區(qū)資源管理狀態(tài)出了問(wèn)題。

解決這種問(wèn)題，就是退出eclipse實(shí)例，然后eclipse -clean ..... 看運(yùn)氣了，一般可以解決

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

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

鼓勵(lì)一把

java虛擬機(jī)對(duì)類加載本身就做了同步處理。?。。?

同一個(gè)類加載器實(shí)例不可能對(duì)同一類型加載多次
不同的類加載器實(shí)例可能會(huì)對(duì)同一全名類型記載多次，那本質(zhì)上是不同的類型了，類加載器實(shí)例一個(gè)很核心的作用就是來(lái)維護(hù)命名空間

@aaa
不能這么說(shuō)。
樓主寫的可能過(guò)于抽象

繼續(xù)

@xxuu503
1、我的建議是用PDEUnit進(jìn)行插件開發(fā)過(guò)程中的單元測(cè)試。但是有一個(gè)問(wèn)題，那就是在對(duì)ui插件進(jìn)行測(cè)試的時(shí)候，也會(huì)較為繁瑣，目前沒(méi)有看到什么特別出色的工具?；旧暇褪菃⒁粋€(gè)workbench或者使用鍵盤鉤子的技術(shù)

2、第二個(gè)問(wèn)題當(dāng)然沒(méi)有違反分層原則。其實(shí)，分層原則很廣泛：
基礎(chǔ)功能模塊和上層具體功能模塊分層
模塊ui和非ui部分進(jìn)行分層
具體實(shí)現(xiàn)細(xì)節(jié)中注意分層思想，避免緊耦合

m之上可能有很多個(gè)c，針對(duì)的場(chǎng)景不一樣，v肯定是場(chǎng)景的一部分 ~_~

現(xiàn)在ext真的有點(diǎn)走紅了
最近看到不少產(chǎn)品中的web解決方案都用了ext

@mark
圖片放上去了

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

@polygoncell
我也只是和你打個(gè)比喻

繼承封裝變化....靜態(tài)能繼承嗎？
－－－－－－－－－簡(jiǎn)單工廠（靜態(tài)工廠方法）和工廠方法的最本質(zhì)區(qū)別

如果你真的有封裝變化的需求，那你用工廠方法問(wèn)題不大。如果現(xiàn)有變化比較少，而且能夠預(yù)想到的擴(kuò)展需求不大，就別用工廠方法了...


當(dāng)然你可能有你特定的需求，而且也沒(méi)法三言兩句說(shuō)的很清楚。說(shuō)實(shí)在的，你的那個(gè)反射...什么什么的... 有點(diǎn)亂～_～


你的代碼是在使用工廠方法，但是這個(gè)創(chuàng)建過(guò)程有點(diǎn)煩瑣...不需要搞成這樣

“編碼中對(duì)“可預(yù)見性”的代碼結(jié)構(gòu)適應(yīng)，擴(kuò)展接口預(yù)留”
個(gè)人覺(jué)得這種事情在編碼之前還是預(yù)先想一點(diǎn)的，至少?gòu)恼w系統(tǒng)或者重點(diǎn)模塊的層面上大致想一下，否則，完全推遲到編碼時(shí)候再去做，那就有點(diǎn)懸了。除非項(xiàng)目組確實(shí)有幾個(gè)老道的高手，否則......就有點(diǎn)困難了

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

不能說(shuō)單純的炒作新概念了，畢竟是一種不錯(cuò)的組件化開發(fā)理論

尚未完善是真的。包括OSGI到底適應(yīng)于那些場(chǎng)景等等，現(xiàn)在也都是人云亦云

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

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

理論上來(lái)說(shuō)，creation method也是可以的，不過(guò)這樣一來(lái)就導(dǎo)致Performer類和過(guò)多的其他類產(chǎn)生耦合（因?yàn)樘幚砻恳粋€(gè)狀態(tài)需要用到完全不同的類），我用factory就是為了保持performer干凈。要是一定要用creation method的話，performer都可以省了，直接寫一個(gè)復(fù)雜的enum，而每一個(gè)enum實(shí)例正好就是creation method。


大哥：只能說(shuō)，俺長(zhǎng)見識(shí)了！ ～_～

如果簡(jiǎn)單針對(duì)樓主的代碼，個(gè)人覺(jué)得這么重構(gòu)有點(diǎn)過(guò)了。

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

我想強(qiáng)調(diào)兩點(diǎn)：
1、再仔細(xì)揣摩一下你的需求。是不是用個(gè)靜態(tài)方法（creation method）的方式更合理一些？
2、看一下你周圍的工作伙伴，這么寫會(huì)不會(huì)增大代碼的負(fù)責(zé)度？（這個(gè)問(wèn)題的標(biāo)準(zhǔn)是有你的同伴來(lái)決定，不能自己判斷）


最后強(qiáng)調(diào)一下：
在學(xué)習(xí)模式導(dǎo)向重構(gòu)的時(shí)候，看看最基本的重構(gòu)技巧是否已經(jīng)熟悉了。我看你那個(gè)getPerformers()方法，就有點(diǎn)難受。為什么要把if語(yǔ)句嵌套的那么深呢？？？