首先聲明，本人業(yè)余編程愛好者，把編程當作玩，不在IT界謀生，工作和生活圈子中也無人懂編程，好在有互聯(lián)網(wǎng)，學了點皮毛，胡言幾句，請大家拍磚。

版權(quán)聲明：本博客文章如非特別注明，均為原創(chuàng)，作者保留所有權(quán)利！歡迎轉(zhuǎn)載，轉(zhuǎn)載請注明作者左洸和出處http://www.blogjava.net/myqiao

軟件工程本質(zhì)的三句話總結(jié)：

第一句：軟件工程的終極目標是復用。
第二句：復用永遠要面對的問題是變化。
第三句：依賴是導致變化難以控制的主要原因。


關于第一句話，不想多做解釋，當然，軟件工程中還有成本控制、開發(fā)周期控制、文檔管理等等，這些工作最終都要通過復用來解決。


關于第二句話，學過哲學的都知道絕對運動和相對靜止，所以變化是絕對的、是永恒的、是無法避免的、是不可預測的。對于變化，只能想辦法控制它，利用它，不要讓它造成破壞，但是不要想著能消滅它。


關于第三句，造成變化的原因很多，但是依賴導致的變化是最難以控制的，也是最具破壞性的。這里舉個簡單的例子來說明：

某個項目的某個源文件中有如下一行代碼：

String PATH="D:\AppServ\www\test";

這行代碼中，我們用一個字符串把 Test 項目的路徑寫死在源代碼中，以后我們只要用到項目路徑，就引用這個字符串。這樣，所有引用到這個字符串的地方都對它發(fā)生了依賴關系。這里：用一個字符串是為了簡化說明問題，實際中，他有可能是個類，有可能是數(shù)據(jù)庫連接配置，有可能是模塊等等。

這時候，變化來了，項目被上傳到 Linux 服務器上，Windows 的路徑格式無法識別了；數(shù)據(jù)庫也從SqlServer 變成了 MySQL，怎么辦？因為一切都寫死了，唯一的辦法就是打開源文件，一處一處查找，一處一處修改。

于是，一些廠家提供了功能強大的應用程序服務器，大家都按照統(tǒng)一約定的協(xié)議，像JNDI之類的東西，把所有有可能變化的因素都配置到服務器里，哪怕他是一個簡單的數(shù)據(jù)庫連接字符串，或者是一個復雜的對象實例。等需要使用的時候再通過協(xié)議中約定好的接口來訪問。如果發(fā)生了變化，只需要修改配置，而不需要更改源代碼，這樣就最大限度的削弱了依賴，控制了變化。

這種重型的解決方案對于大型的、穩(wěn)定的企業(yè)級應用是安全可靠的，但是應用服務器配置的修改維護很麻煩，權(quán)限也是個問題，如果你是一個虛擬主機上的個人站長，由于需求變動比較頻繁，三天兩頭要更改J2EE容器配置，估計你的主機服務商不會給你這個權(quán)限吧。用核武器對付游擊隊，似乎太過火了。

大牛們對這種情況看不過眼，于是Spring等輕量級解決方案出現(xiàn)了，所有配置都寫道XML文件里面，給了你最大的靈活性和權(quán)限。當然，依賴并沒有消除，但是反過來了，原來我想要什么需要自己去找，如果發(fā)生了變化，可能就找不到，或者找回來錯誤的結(jié)果；現(xiàn)在我想要什么，工廠會自動給我送過來，發(fā)生什么變化我不管。當然，工廠是按照配置文件的描述來生產(chǎn)產(chǎn)品的，發(fā)生變化只需要修改配置文件，最大限度的減少了破壞性和侵入性。而且，權(quán)限都在你自己手里，配置起來很方便。

版權(quán)聲明：本博客文章如非特別注明，均為原創(chuàng)，作者保留所有權(quán)利！歡迎轉(zhuǎn)載，轉(zhuǎn)載請注明作者左洸和出處http://www.blogjava.net/myqiao

寫這篇文章是因為為了更好的理解思想，昨天用 PHP 寫了個簡單的實現(xiàn)發(fā)到博客里（文章在這里），卻被拍磚說是“為了實現(xiàn)而實現(xiàn)”，可能因為我用的是PHP語言，沒有Java高貴吧，所以被人瞧不上眼。但是個人覺得，控制反轉(zhuǎn)、依賴注入是一種思想，并沒有和那種語言綁定。

Spring 框架對我這樣的業(yè)余玩家來說依然太重型了，只是大概了解了一下，對于一個玩票性質(zhì)的 PHP 個人站點來說，自己做一個簡單的實現(xiàn)有何不可呢？