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

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

軟件工程本質的三句話總結：

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


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


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


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

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

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

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

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

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

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

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

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

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

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