J++ = Java + ?

[深入的思考] 為什么要采用java這個平臺？

從開發(fā)項目的類別角度看java平臺

基于B/S結(jié)構(gòu)的系統(tǒng)，在這個方向上的競爭是激烈的，有專注于此的LAMP（Linux + Apache + Mysql + Php）;也有剛剛興起的Rails（Ruby Frameworks）甚至是號稱快速開發(fā)的ASP.NET;當(dāng)然了java在這個領(lǐng)域里的MVC框架數(shù)都數(shù)不完，比如Struts . Webwork等，然而即便是如此，選擇java作為開發(fā)的理由也是不充分的，因為在這個梯隊里java頂多排名最后。

基于C/S結(jié)構(gòu)的系統(tǒng)，在這個方面java顯然沒有考慮周到，面對VB 、DELPHI、vc這些個如狼似虎的快速開發(fā)IDE，JAVA實在是顯得異常的淡薄，即使你找到了一個可以匹敵這些個ide的工具，面對第三方的組件又會成為一大障礙，所以java在這個方面又一次的輸了。

從java所強(qiáng)調(diào)的特性角度看java平臺

java的重點是業(yè)務(wù)邏輯！（我以前也是如此堅信不移）可是誰有能夠說別的語言不注重業(yè)務(wù)邏輯呢，業(yè)務(wù)邏輯只是一個抽象的概念，java只是依靠ejb提出了業(yè)務(wù)組件而已，其他的語言在實現(xiàn)業(yè)務(wù)邏輯的時候也可以包裝成POJO的形式，看來這個觀點也是失敗的。

java強(qiáng)調(diào)的是跨平臺的優(yōu)勢！這可以理解為初級的、商業(yè)的、忽悠人的詞匯，面對眾多動態(tài)語言如Python，在若干平臺上的表現(xiàn)，java又如何來強(qiáng)調(diào)自己這方面的優(yōu)勢呢？失敗

java支持分布式應(yīng)用的項目！可笑的言論，分布式根本不是值得炫耀的資本，在java之前的c/s項目中何嘗不是分布式的應(yīng)用呢？失敗

既然沒有了這些個優(yōu)勢，我們看看java到底還剩下些什么？對了其實就是應(yīng)用服務(wù)器！然而看過J2EE WITHOUT EJB的讀者肯定知道Spring所希望達(dá)到的目的，也就是脫離應(yīng)用服務(wù)器概念上的J2EE體系實現(xiàn)，既然在作者的眼里APPLICATION SERVER只不過是一個忽悠人的詞匯，那么任何項目都選擇java作為開發(fā)的依據(jù)顯然就是自找苦吃，

那么什么情況下改選擇java作為開發(fā)的平臺呢？
<1> 如果你真的遇到了大型的系統(tǒng)開發(fā)任務(wù)，恭喜你，你終于可以看到分布式對象、集群的優(yōu)勢了。
<2> 客戶是一個java的忠實fans或者是sun、ibm的金牌合作伙伴之類的，選擇java是不得已的，但記住并不能證明java是最好的實現(xiàn)方式
<3> 如果你只想關(guān)心業(yè)務(wù)邏輯的實現(xiàn)，對于事務(wù)、緩存、查找等服務(wù)的實現(xiàn)沒有興趣的話，倒是不妨考慮采用ejb的形式，當(dāng)然前提是你不愿意在尋找合適的替代品的情況下。
<4> 如果項目迫切的尋找某種框架的支持，選擇java就是對的，你有眾多優(yōu)秀的、免費的、可擴(kuò)展的、天才的框架可以選擇，更多的時候你是出于尷尬的境地，因為任何一個都讓你心動、而這樣的選擇往往是最痛苦、和快樂的。

正確的選擇
<1>
條件: 如果項目僅僅只是一個小型的網(wǎng)站系統(tǒng)
選擇: LAMP、Rails

<2>
條件: 項目規(guī)模中等
并且項目的時間比較緊，
項目可以架構(gòu)在windows的系統(tǒng)之上，
選擇: .Net? / Delphi

<3>
條件: 大型的系統(tǒng)，有支持分布式對象、集群的要求；或者SUN / IBM的金牌合作伙伴 ; 想要尋找某種優(yōu)秀的框架來解決問題
選擇: java是不二的選擇，可是我想問一下，在現(xiàn)實中你能遇到這樣的項目嗎？

所以，從實際的角度出發(fā)，我們面對的99％可能都是一些符合條件1，2的系統(tǒng)，而選擇java實在是得不償失的。最后以一段Code Complete中的話來作為結(jié)束語

每個程序員都有很多的工具，但并不存在任何一個能夠適用于所有工作的工具，因地制宜的選擇正確工具是成為能有效編程的程序員的關(guān)鍵。

?

作者簡介
XincChen是Xtremework公司創(chuàng)始人.a自從.NET推出以來,1他已使用.NET幫助很多行業(yè)的用戶開發(fā)了體現(xiàn)其商業(yè)理念的軟件產(chǎn)品.aXincChen是.NET和EAI方面的專家,1他與Microsoft和Accenture等多家技術(shù)領(lǐng)先的公司合作,1為它們的客戶提供了優(yōu)秀的解決方案.a在工作之余,1他喜歡讀書.c寫書.c以及靜靜地休息.aApress出版社的另一本書——《BizTalkc2002cDesigncandcImplementation》——也是出自他的筆下.aXincChen擁有哥倫比亞大學(xué)的統(tǒng)計學(xué)文科碩士學(xué)位,1現(xiàn)居國內(nèi),1正在籌建公司在北京的研發(fā)中心.a可通過xchen@Xtremework.com和作者取得聯(lián)系.

個人評論

這本書本來購買時的期望值非常的高，想必是一本細(xì)數(shù).NET框架類的圖書，結(jié)果卻大失所望，而這本書也就因為其技術(shù)上的薄弱而消弱了其價值的表現(xiàn)力，不過作為一本.NET入門級的圖書還是比較的合適，但在CSDN上竟然有四顆半的星的待遇實在不敢恭維。

而且作者的代碼顯然非常的粗造，竟然連起碼的業(yè)務(wù)級數(shù)據(jù)校驗都沒有，在一些功能的分解上也是抹漿糊，可以想象作者并沒有深入的思考而僅僅是去實現(xiàn)功能而已，猜想這樣的框架很可能是作者對于以前工作的簡單抽象而已。

整體上本書除了第一章應(yīng)用框架介紹 、 第二章應(yīng)用框架解析比較的出彩，尤其是創(chuàng)造性的提出了業(yè)務(wù)假設(shè)（Business assumption）的概念還比較的有深度，其他的章節(jié)只是對于其SAF框架的介紹，但在技術(shù)實現(xiàn)上只是對于.NET的若干相關(guān)服務(wù)的簡單包裝而已，對于已經(jīng)在JAVA世界里的人來說,SAF框架其實就是Spring框架在.NET世界的簡單實現(xiàn)版本，但相對于Spring的技術(shù)實力，作者還需要努力才行，不過作者顯然是.NET方面的高手，對于.NET世界提供的雜亂無章的服務(wù)特性以及服務(wù)的原理非常的清楚，這也難怪在這樣的平臺上再去"多此一舉"的開發(fā)另外的框架，無論從技術(shù)上還是推廣上都非常的難！不過領(lǐng)略一下..NET的秀發(fā)也是多少有所收獲的 :)

再次強(qiáng)調(diào)這本書僅僅只能夠算作.NET方面的初級讀物，個人評星3.5 ，請朋友們謹(jǐn)慎購買。

wfc是構(gòu)建在B/S結(jié)構(gòu)上的流程定義工具

具備以下的功能
1> 實現(xiàn)了B/S結(jié)構(gòu)上的工作流定義工具（沒有看到同類型的產(chǎn)品）。
2> 流程定義格式與具體的工作流格式相分離，并可以在此基礎(chǔ)上實現(xiàn)其他的流程定義工具產(chǎn)品。
3> 采用了Buffalo（XML-RPC的javascript實現(xiàn)）實現(xiàn)與后端Servlet的綁定。
4> 可以對具體的節(jié)點進(jìn)行屬性的配置（配置后的數(shù)據(jù)會被綁定為java的List自動傳遞到后端）。

目前還需要改進(jìn)的
1> 修改目前工作流的圖標(biāo)（需要分支、狀態(tài)、合并這樣專業(yè)的圖標(biāo)）
2> 解決瀏覽器的刷新問題。
3> 增加線段的表現(xiàn)形式選項
4> 增加曲線的表現(xiàn)形式，尤其是在多線段的情況下要自動調(diào)整為曲線的形式。


目前的WFC已經(jīng)被Michael Chen（buffalo的作者）收錄在其網(wǎng)站上！地址如下
http://demo.amowa.net/wfc

對于buffalo的關(guān)注早在作者剛發(fā)布的時候就已經(jīng)開始了，起初不太了解buffalo的作用，然而在具體的工作中尋找基于XML-RPC協(xié)議的產(chǎn)品時突然明白了它的價值，不過說簡單一點buffalo是實現(xiàn)了基于javascript的對象的序列化以及反序列化工作。

通用類圖書

卓越獎: Prefactoring by Ken Pugh (O'Reilly)

生產(chǎn)力獎:
Innovation Happens Elsewhere: Open Source as Business Strategy by Ron Goldman, Richard P. Gabriel (Morgan Kaufmann)
Producing Open Source Software: How to Run a Successful Free Software Project by Karl Fogel (O'Reilly)
The Art of Project Management by Scott Berkun (O'Reilly)

技術(shù)類圖書

卓越獎:Agile Web Development with Rails by Dave Thomas, David Hansson, Leon Breedt and Mike Clark (Pragmatic Bookshelf)

生產(chǎn)力獎:
Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries by Krzysztof Cwalina and Brad Abrams (Addison-Wesley)
Practical Common Lisp by Peter Seibel (Apress)
Why Programs Fail: A Guide to Systematic Debugging by Andreas Zeller (Morgan Kaufmann)

企業(yè)項目管理

卓越獎: WelcomRisk 2.6 (Welcom)

生產(chǎn)力獎:
Corticon Business Rules Management 4.0 (Corticon)
JBoss 2 Portal (JBoss)
Visual Studio Team System 2005 (Microsoft)

數(shù)據(jù)庫引擎和數(shù)據(jù)工具

卓越獎: Microsoft SQL Server 2005 (Microsoft)

生產(chǎn)力獎:
Berkeley DB 4.4 (Sleepycat Software)
Google Maps API 2005 (Google)
MySQL 5.0 (MySQL)

缺陷跟蹤，變更和配置管理

卓越獎: Perforce SCM 2005 (Perforce)

生產(chǎn)力獎:
FogBugz 4.0 (Fog Creek)
Guiffy SureMerge 7.0 (Guiffy Software)
JIRA 3.4 (Atlassian Software)

設(shè)計和建模工具

卓越獎:Lattix LDM 2.0 (Lattix)

生產(chǎn)力獎:
Borland Together 2006 for Eclipse (Borland)
Enterprise Architect 6.0 (Sparx Systems)
MindManager Pro 6.0 (Mindjet)

開發(fā)環(huán)境

卓越獎: Visual Studio Team System 2005 (Microsoft)

生產(chǎn)力獎:
Eclipse SDK 3.1 (Eclipse.org)
IntelliJ IDEA 5.0 (JetBrains)
Komodo 3.5 (ActiveState)

類庫、框架和組建

卓越獎: .NET Framework 2.0 (Microsoft)

生產(chǎn)力獎:
Dundas Chart for .NET 5.0 (Dundas Software)
Qt 4.0 (Trolltech)
Spring Framework 1.2.6 (SpringFramework.org)

移動開發(fā)工具

卓越獎: Crossfire 5.6 (AppForge)

生產(chǎn)力獎:
Carbide.c++ Express (Nokia)
Flash Lite 2.0 (Adobe)
NetBeans IDE 4.1 (Sun Microsystems)

項目質(zhì)量管理

卓越獎: Rally 5.6 (Rally Software Development)

生產(chǎn)力獎:
CollabNet Enterprise Edition with Project Dashboard/Task Management 2005 (CollabNet)
QACenter Enterprise Edition 5.1 (Compuware)
TargetProcess Suite 1.4 (TargetProcess)

安全工具

卓越獎: Elemental Compliance System 1.4 (Elemental)

生產(chǎn)力獎:
CodeAssure 2.0 (Secure Software)
DevPartner SecurityChecker 1.0 (Compuware)
Fortify Security Tester 1.0 (Fortify)

測試工具

卓越獎:VMTN Subscription 2005 (VMware)

生產(chǎn)力獎:
Agitator 3.0 (Agitar Software)
AQtime 4.7 (AutomatedQA)
Clover 1.3 (Cenqua)

實用程序

卓越獎:Camtasia Studio 3.0 (TechSmith)

生產(chǎn)力獎:
DevPartner Studio 8 (Compuware)
Fog Creek Copilot 1.2 (Fog Creek Software)
ReSharper 1.5 (JetBrains)

Web開發(fā)工具

卓越獎: Rails 1.0 (rubyonrails.org)

生產(chǎn)力獎:
JBoss Application Server 4x (JBoss)
Macromedia Studio 8 2005 (Adobe)
Zend Studio - Enterprise Edition 5.0 (Zend)

名人堂產(chǎn)品獲獎?wù)?

?Visual Studio Professional Edition (Microsoft)

感慨
??? MS在這次的JOLT中屢獲殊榮，深思。。。

很久都不罵人了，可是一不留心又看到了他寫了惡心文章，實在是讓人憤慨！這位板橋里人的"大名"是從透明的blog上知道的，首先就是感覺這個人的腦子有點問題！不去評論他發(fā)布的那個所謂的框架，就看看他寫的一些文章就足以知道這個人腦袋非常的混亂，在這樣混亂的情況下寫出來的文章也就可想而知了，最近這位所謂的"大俠"又開始害人了

你還在用if else嗎？－ http://www.jdon.com/artichect/ifelse.htm


面向過程設(shè)計和面向?qū)ο笤O(shè)計的主要區(qū)別是：是否在業(yè)務(wù)邏輯層使用冗長的if else判斷。如果你還在大量使用if else，當(dāng)然，界面表現(xiàn)層除外，即使你使用Java/C#這樣完全面向?qū)ο蟮恼Z言，也只能說明你的思維停留在傳統(tǒng)的面向過程語言上。

－我很納悶了作者怎么可以從是否使用if else來判斷一個設(shè)計是否符合OO特性呢？我們看到的if else屬于語言這個層次的東西，而if else僅僅是完成邏輯判斷的語句；如果說作者的這個觀點成立的話，java、c#的語言發(fā)明者應(yīng)該早就明白或者預(yù)測到if else 的"不OO"的特性，也會考慮到在語言層面刪除這樣的邏輯判斷語句，但事實呢？發(fā)明者非但沒有刪除相反其他語言的發(fā)明者也一起發(fā)明了if else語句？！難道是大師們錯了？

還是以大家熟悉的論壇帖子為例子，如ForumMessage是一個模型，但是實際中帖子分兩種性質(zhì)：主題貼（第一個根貼）和回帖（回以前帖子的帖子），這里有一個樸素的解決方案：
建立一個ForumMessage，然后在ForumMessage加入isTopic這樣判斷語句，注意，你這里一個簡單屬性的判斷引入，可能導(dǎo)致你的程序其他地方到處存在if else 的判斷。

　　如果我們改用另外一種分析實現(xiàn)思路，以對象化概念看待，實際中有主題貼和回帖，就是兩種對象，但是這兩種對象大部分是一致的，因此，我將ForumMessage設(shè)為表達(dá)主題貼；然后創(chuàng)建一個繼承ForumMessage的子類ForumMessageReply作為回帖，這樣，我在程序地方，如Service中，我已經(jīng)確定這個Model是回帖了，我就直接下溯為ForumMessageReply即可，這個有點類似向Collection放入對象和取出時的強(qiáng)制類型轉(zhuǎn)換。通過這個手段我消滅了以后程序中if else的判斷語句出現(xiàn)可能。

－作者在這里似乎列舉了一個例子,可是對于帖子和回帖這樣簡單的問題，只要遵守OO的設(shè)計師都會抽象出一個帖子的父類，然而這又能說明什么呢？在具體的業(yè)務(wù)邏輯中難道你不判斷傳遞過來的對象的類別？（現(xiàn)在主題貼與回帖的處理方法是不同的），同樣你無法避免在具體的編碼中使用if else的可能？！


最后總結(jié)：將if else用在小地方還可以，如簡單的數(shù)值判斷；但是如果按照你的傳統(tǒng)習(xí)慣思維，在實現(xiàn)業(yè)務(wù)功能時也使用if else，那么說明你的思維可能需要重塑，你的編程經(jīng)驗越豐富，傳統(tǒng)過程思維模式就容易根深蒂固，想靠自己改變很困難；建議接受專業(yè)頭腦風(fēng)暴培訓(xùn)。

　用一句話總結(jié)：如果你做了不少系統(tǒng)，很久沒有使用if else了，那么說明你可能真正進(jìn)入OO設(shè)計的境地了。（這是本人自己發(fā)明的實戰(zhàn)性的衡量考核標(biāo)準(zhǔn)）。

－顯然作者并不是去討論if else的語言問題，而是為自己的"洗腦培訓(xùn)"打廣告！并講這樣的問題上升到設(shè)計模式、禪的境界，可謂是煞費苦心呀，沒有人說設(shè)計模式不好也沒有人懷疑禪的境界的高深，但不是作者這樣的人靠讀一兩篇文章或者發(fā)布個所謂的"毫無實際意義"的框架就可以領(lǐng)悟到的，還是那句話：長得丑不要緊，不要出來嚇人！不過我還要補(bǔ)充一句就是，不懂不要緊，不要亂說免得害人（因為我們都知道潑婦罵街的道理，雖然沒文化但確實能夠帶來眼球效應(yīng)）。

該死，鼠標(biāo)癱瘓了！
本來以為是Maxthon的問題（在鼠標(biāo)單擊的時候會關(guān)閉一些窗口，并且是隨機(jī)的？?。┻€就這樣的問題給作者寫了一封信？汗。。。經(jīng)過仔細(xì)的尋找原因，原來是自己的鼠標(biāo)的問題（這個鼠標(biāo)跟了我快7年了，Logitech最好的滾軸鼠標(biāo)，要300多塊大洋）有點舍不得，又沒有辦法，該下崗了，一同下崗的也許還有我的鍵盤（TCL的手感級差！:（ ）

不過為了找原因我倒是廢了一番周折，下載和試用了N多的瀏覽器，也看了很多網(wǎng)上的評論對比文章，現(xiàn)在主流的瀏覽器主要就是Opera , Firefox, Maxthon , GreenBrowser , MyIE , TheWorld 等，然而在資源的利用率上這些個產(chǎn)品都非常的讓人失望，難道就沒有一款適合于程序員的胃口的瀏覽器？！

可喜的是偶發(fā)現(xiàn)了GOSURF這款瀏覽器，在眾多的瀏覽器中它的內(nèi)存占用率是最低的，而且它的作者似乎在這方面也是煞費苦心，"一味"的強(qiáng)調(diào)速度，甚至對于鼠標(biāo)手這個及其流行的功能的加入也是非常的謹(jǐn)慎，可以看出作者是個很有個性的程序員，值得期待！

如果你和我一樣對資源的利用率近乎苛刻，可以考慮這樣的一款產(chǎn)品 http://gosurfbrowser.com/?ln=cn

不錯的文章
http://www-128.ibm.com/developerworks/cn/java/j-junit4.html

JUnit 是 Java? 語言事實上的 標(biāo)準(zhǔn)單元測試庫。JUnit 4 是該庫三年以來最具里程碑意義的一次發(fā)布。它的新特性主要是通過采用 Java 5 中的標(biāo)記（annotation）而不是利用子類、反射或命名機(jī)制來識別測試，從而簡化測試。在本文中，執(zhí)著的代碼測試人員 Elliotte Harold 以 JUnit 4 為例，詳細(xì)介紹了如何在自己的工作中使用這個新框架。注意，本文假設(shè)讀者具有 JUnit 的使用經(jīng)驗。

JUnit 由 Kent Beck 和 Erich Gamma 開發(fā)，幾乎毫無疑問是迄今所開發(fā)的最重要的第三方 Java 庫。正如 Martin Fowler 所說，“在軟件開發(fā)領(lǐng)域，從來就沒有如此少的代碼起到了如此重要的作用”。JUnit 引導(dǎo)并促進(jìn)了測試的盛行。由于 JUnit，Java 代碼變得更健壯，更可靠，bug 也比以前更少。JUnit（它本身的靈感來自 Smalltalk 的 SUnit）衍生了許多 xUnit 工具，將單元測試的優(yōu)勢應(yīng)用于各種語言。nUnit (.NET)、pyUnit (Python)、CppUnit (C++)、dUnit (Delphi) 以及其他工具，影響了各種平臺和語言上的程序員的測試工作。

然而，JUnit 僅僅是一個工具而已。真正的優(yōu)勢來自于 JUnit 所采用的思想和技術(shù)，而不是框架本身。單元測試、測試先行的編程和測試驅(qū)動的開發(fā)并非都要在 JUnit 中實現(xiàn)，任何比較 GUI 的編程都必須用 Swing 來完成。JUnit 本身的最后一次更新差不多是三年以前了。盡管它被證明比大多數(shù)框架更健壯、更持久，但是也發(fā)現(xiàn)了 bug；而更重要的是，Java 不斷在發(fā)展。Java 語言現(xiàn)在支持泛型、枚舉、可變長度參數(shù)列表和注釋，這些特性為可重用的框架設(shè)計帶來了新的可能。

JUnit 的停滯不前并沒有被那些想要廢棄它的程序員所打敗。挑戰(zhàn)者包括 Bill Venners 的 Artima SuiteRunner 以及 Cedric Beust 的 TestNG 等。這些庫有一些可圈可點的特性，但是都沒有達(dá)到 JUnit 的知名度和市場占有份額。它們都沒有在諸如 Ant、Maven 或 Eclipse 之類的產(chǎn)品中具有廣泛的開箱即用支持。所以 Beck 和 Gamma 著手開發(fā)了一個新版本的 JUnit，它利用 Java 5 的新特性（尤其是注釋）的優(yōu)勢，使得單元測試比起用最初的 JUnit 來說更加簡單。用 Beck 的話來說，“JUnit 4 的主題是通過進(jìn)一步簡化 JUnit，鼓勵更多的開發(fā)人員編寫更多的測試。”JUnit 4 盡管保持了與現(xiàn)有 JUnit 3.8 測試套件的向后兼容，但是它仍然承諾是自 JUnit 1.0 以來 Java 單元測試方面最重大的改進(jìn)。

注意：該框架的改進(jìn)是相當(dāng)前沿的。盡管 JUnit 4 的大輪廓很清晰，但是其細(xì)節(jié)仍然可以改變。這意味著本文是對 JUnit 4 搶先看，而不是它的最終效果。

http://blog.raylife.com/?p=336

在這個暖暖的午后享受著陽光的溫暖的同時，聽著CUSCO 的專輯實在是一種享受，我喜歡那種寧靜的音樂，因為它帶給你的除了純凈還是純凈。。。。

不想被任何的人打擾，城市的喧鬧讓自己的思想變得復(fù)雜，而唯獨音樂才能夠真正的喚醒你心靈深處的東西，

目前在找工作階段，參加了一些公司的面試，對于目前的一些公司的面試官我真的要說上兩句，比如我去一家"非常著名"（至少在程序界是比較有名氣的）的公司去面試，在回答一些無關(guān)痛癢的自我介紹后，技術(shù)總監(jiān)突然問我"Struts是如何解決多配置文件的問題的？"，當(dāng)時就把我給問住了，主要是自己已經(jīng)很久都沒有做項目了，對于Struts也僅僅停留在使用這樣的基礎(chǔ)上，況且當(dāng)時接觸到的Struts是不支持多配置文件的，所以我只好亂說“將配置文件放在classpath就行了”，顯然這樣的答案是技術(shù)總監(jiān)不愿意聽到的，（想必很多的程序員也會這樣認(rèn)為），可是事情真的就是這樣簡單嗎？

標(biāo)準(zhǔn)答案是：在web.xml中配置ActionServlet的config參數(shù)，在經(jīng)過大腦短暫的思考后我斷定我的回答并沒有錯！

誰說一定要配置這樣的參數(shù)？那只是ActionServlet的"一廂情愿"，如果有一天Struts不高興了，將尋找配置文件的策略更改成：從classpath尋找，你認(rèn)為我說的答案還是錯誤的嗎？

所以我想說這樣的面試問題是弱智的，一個人不可能知道所有的一切，對于現(xiàn)在這個社會如此眾多的框架產(chǎn)品你怎么可能光靠某個問題就斷定一個人的能力呢？

其實如果他可以這樣問：你認(rèn)為配置文件的讀取策略可以有多少種?或者如果是你設(shè)計Struts你會如何解決多配置文件的問題？這樣啟發(fā)式的詢問更會激起面試者的興趣，難道這些個所謂的技術(shù)總監(jiān)不該反思一下？

當(dāng)然，不是僅僅一個這樣的事件引起了自己點憤怒，而是很多很多的所謂的技術(shù)專家的弱智問題，不知道磨滅了多少人的熱情！如果你也是遇到了這樣的尷尬，索性問他一個自己非常另類的問題－比如"內(nèi)部類如何訪問外部類的對象？"

該死，請不要再問我弱智的問題了

在OSWorkflow中最讓人惱火的就是它的接口定義！我會就這些接口的混亂展開一系列的分析，今天先說說Configuration接口

偶繼承了它的Configuration接口

import com.company.engine.workflow.store.IWorkFlowStore;
import com.opensymphony.workflow.StoreException;
import com.opensymphony.workflow.config.Configuration;
import com.opensymphony.workflow.spi.WorkflowStore;

public interface IConfiguration extends Configuration
{
 /**
  * @deprecated getIWorkflowStore()
  */
    WorkflowStore getWorkflowStore() throws StoreException;
   
    /**
     * return WorkFlowStore which implements the interface of IWorkFlowStore
     * @return
     * @throws StoreException
     */
    IWorkFlowStore getIWorkflowStore() throws StoreException;
   
}

你可能奇怪我為何要繼承它的接口（肯定是Bad smell），原因如下，

IWorkFlowStore 接口定義

import com.opensymphony.workflow.StoreException;
import com.opensymphony.workflow.spi.Step;
import com.opensymphony.workflow.spi.WorkflowEntry;
import com.opensymphony.workflow.spi.WorkflowStore;

public interface IWorkFlowStore extends WorkflowStore
{
 
 public Step createCurrentStep(WorkflowEntry _entry , Step _step) throws StoreException;

}

WorkflowStore接口定義

    /**
     * Persists a step with the given parameters.
     *
     * @param entryId The workflow instance id.
     * @param stepId the ID of the workflow step associated with this new
     *               Step (not to be confused with the step primary key)
     * @param owner the owner of the step
     * @param startDate the start date of the step
     * @param status the status of the step
     * @param previousIds the previous step IDs
     * @return a representation of the workflow step persisted
     */
    public Step createCurrentStep(long entryId, int stepId, String owner, Date startDate, Date dueDate, String status, long[] previousIds) throws StoreException;

看到了吧？

其實我只是希望在createCurrentStep時按照OO的方法執(zhí)行，而不是傳遞那些"Bad Smell"的參數(shù)，而OSWorkflow中的WorkflowStore是需要Configuration來獲取的，此時為了增加一個看似合理的方法，需要分別繼承Configuration與WorkflowStore；這還沒有完，你需要實現(xiàn)一個Configuration實現(xiàn)??！

import com.company.engine.workflow.store.IWorkFlowStore;
import com.opensymphony.workflow.StoreException;
import com.opensymphony.workflow.config.DefaultConfiguration;
import com.opensymphony.workflow.spi.WorkflowStore;

public class DefaultIConfiguration extends DefaultConfiguration implements IConfiguration
{
 
    public static DefaultIConfiguration INSTANCE = new DefaultIConfiguration();
    private transient IWorkFlowStore store = null;

 /**
  * @deprecated getIWorkflowStore()
  */
 public WorkflowStore getWorkflowStore() throws StoreException
 {
  return null;
 }

 public IWorkFlowStore getIWorkflowStore() throws StoreException
 {
  if (store == null)
  {
   String clazz = getPersistence();

   try
   {
    store = (IWorkFlowStore) Class.forName(clazz).newInstance();
   }
   catch (Exception ex)
   {
    throw new StoreException("Error creating store", ex);
   }

   store.init(getPersistenceArgs());
  }

  return store;
 }

}

總結(jié)

1。OSWorkflow與WorkflowStore接口的關(guān)系比較的微妙，它需要借助于Configuration接口的實現(xiàn)來獲取到實際的WorkflowStore對象。

2。由于這樣的一種微妙關(guān)系，對WorkflowStore接口的擴(kuò)展必將連帶著需要擴(kuò)展Configuration接口，而產(chǎn)生這樣的"果凍效應(yīng)"的罪魁禍?zhǔn)拙褪怯捎赪orkflowStore接口與Configuration接口耦合的太緊。

3。OSWorkflow并沒有很好的遵守OO的設(shè)計規(guī)則，尤其在它的參數(shù)傳遞上，非常的差！