周一一不小心又把右側腕關節給摔傷了，因此這周可能寫不了**了。我就琢磨著構思一片文章，不能把腦袋也停下來。恰好周一早上一位朋友大清早的通過qq群給我打招呼，於是我就抓住了機會。想從他那裡偷點東西用在我的文章上。雖然我又回到了剛練習打字的時代，乙個鍵乙個鍵的戳，但是我們聊的還是很high。聊天的內容有很多，大部分是他在問，我在答。儘管我的答案不能令他滿意，但是我還是比較開心的。本來我覺的我們的聊天記錄貼上來可能就是一篇文章，可是由於我的聊天習慣，我手賤把聊天記錄刪除了，因此我寫下了這篇文章，盡量的去回憶我們的聊天記錄。想了很久，我們聊的最多的就是物件建立的幾種方式，下面我先來回憶一下我理解的建立物件的幾種方式。
定義：定義乙個建立物件的介面，但由子類決定要例項化的類是那乙個。工廠方法讓類把例項化推遲到子類。在工廠方法模式中，核心的工廠類將不再負責產品的建立，而是將建立的工作交給子類去完成。它僅僅負責給出介面，不負責具體實現。因此可以輕易的引入新產品。
在沒有引入控制反轉這個概念之前，當a物件需要b物件的時候，a物件必須主動去例項化b物件或者獲取b物件的引用，控制權在a物件自己的手上。在使用了ioc之後，當a物件需要b物件的時候,ioc容器會主動注入乙個b物件給a使用，a是被動接受b物件。在a獲取b的過程中，獲取b物件的方式被反轉了。由主動獲取變為被動接受，這就是控制反轉。經過查詢資料得知，依賴注入這個概念是martin fowler提出的。他提出ioc控制反轉指的是獲取物件的過程被反轉了，獲取物件的過程由自身主動管理變為ioc容器主動注入。於是他提出依賴注入這個概念。所謂依賴注入，就是ioc容器在執行期間動態的將某種依賴關係注入到物件之中。所以，依賴注入和控制反轉是從不同的角度的描述的同一件事情，就是指通過引入ioc容器，利用依賴關係注入的方式，實現具有依賴關係的物件之間的解耦。一開始我並不知道這個模式，我是在構思如何包裹我的ioc容器的時候發現這個模式的。當時我想的是如果我想換乙個ioc容器，只需要改乙個配製就可以完成ioc容器的切換，摸索中知道了這個模式。這個模式想要解決的問題就是解耦合服務提供者給使用者，使用者無需直接訪問具體的服務提供者類。
程式的侵入性：從目的角度來看：工廠模式的目的是將例項化推遲到子類，而ioc是為了實現具有依賴關係的物件之間的解耦。因此當我們遇到 new service(new repository(new unitofwork()) )這種情況的時候，肯定選擇ioc，因為無論是什麼工廠都是不容易解決這個多層依賴關係的。1.呼叫第三方的api
2.方法引數接受第三方api
3.實現了第三方介面
4.繼承了第三方基類
從物件生命週期角度來看：工廠是無法管理建立物件的生命週期的。對於工作單元來說，每個請求必須在同乙個工作單元內，不然是無法保證事務的一致性的。
從單元測試的角度看：ioc可以使依賴物件相互獨立，可維護性好。每乙個物件都可以單獨進行單元測試，只要保證自身無誤就好。
從程式的侵入性角度來看：明顯服務定位器違反了第一條，並且使得程式和servicelocator增加了耦合，而ioc並沒有違反。
綜上所述，朋友鼓勵我多用依賴注入，不用封裝ioc容器。i could go on,but i think i've made my point!
難得認真思考一次 最近感受的現狀
很久沒有上來談技術上的事情了，原因第一是自己懶了，第二個也是累了。在新的工作環境當中，需要奮力拼搏。剩下來的時間也沒有多少可用於跟蹤最新的技術，就像今年的teched，票都拿到了人也去了，可是第一天上午連開場都沒有聽完就被召喚回去了。煩心的事情也很多，包括生活上的各種雜事，即使難得忙裡偷閒，也不再想...
建立物件的幾種方式
原文章 var person new object person.name kevin person.age 31 alert person.name alert person name alert person.name alert person 5 返回帶有屬性和方法的person物件 func...
建立物件的幾種方式
var person new object person.name lisi person.age 21 person.family lida lier wangwu person.say function var person 以上兩種方法在使用同一介面建立多個物件時，會產生大量重複 為了解決此問...