其他

依賴注入(DI)是控制反轉(IoC)的一種方式。目前，在.NET和Java領域已經有相當多基於DI思想的對象容器，如：Spring，Unity等。本文試圖避免重複性地介紹DI基礎知識和DI容器的使用，而是希望深一層探討DI的本質和對象間關係，以達到合理設計避免濫用DI的目的。依賴注入 vs 建立對象有不少地方這樣描述：“依賴注入改變了使用對象前先建立的傳統方式，而是從外部注入依賴的對象”。這樣的描述其實似是而非，先來看一個例子：interface ICar{     void Run(); }

    windows2000工作管理員可以看到CPU的佔用率。    CPU是不能間斷啟動並執行，只要CPU上電就要運行指令，即使無事可做，也要執行NOP操作。所以windows的CPU佔用率低並不是指CPU目前無事可做，而是指CPU可以從目前狀態中騰出多少時間來做使用者的事情。    在多任務作業系統中的進程一般都實現了優先權演算法，搶佔式即時作業系統的高優先權進程能夠立即搶佔低優先權進程的CPU，而分時作業系統則一般等到當前進程的CPU時間片用完後再調度，但無論即時系統還是分時系統，高優先

網上關於此類的討論非常多，發現對於該問題的理解各有各的說法，而各個說法中又相去甚遠。通過瀏覽這些討論以及對《O'Reilly - UML 2.0 In A Nutshell (2007)》的參考，發表一下自己的看法類間關係有很多種，在大的類別上可以分為兩種：縱向關係、橫向關係。縱向關係就是繼承關係，它的概念非常明確，也成為OO的三個重要特徵之一，這裡不過多的討論。橫向關係較為微妙，按照UML的建議大體上可以分為四種：依賴    （Dependency） 關聯   

IoC (Inversion of Control)是什嗎？軟體設計大師已經作出了很多定義。這裡，我從組件開發的角度來談什麼是IoC-“IoC是一種設計模式，當系統由多個組件(Component)構成時，它能消除組件間的直接依賴關係，讓組件的開發更獨立，使用更靈活”。IoC是Framework的基本特徵，但IoC並不專屬於Framework設計範疇，它在需要消除組件依賴的地方都能發揮作用。下面舉一個開發執行個體：需要開發一個計算機組件，實現整數加法運算，計算過程將記錄log。針對上面的需求

Single Responsibility Principle defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to

物件導向分析和設計需要區分對象的值語義與引用語義。我的一塊錢和你的一塊錢相等，這是值語義；20歲的我和30歲的我是同一個人，這是引用語義。值對象包括2大特徵：內容和運算，比如：3這個整數在電腦內部用二進位11表示，可以參與+,-,*,/等運算；引用對象包括3大特徵：標識、狀態和行為，比如：person對象擁有不變的標識，並可通過行為改變狀態。值對象的同一性建立在內容的基礎上，而引用對象的同一性建立在標識的基礎上。 struct和class是OOP語言為分別表達值語義和引用語義所提供的文法機制。值

單一職責原則(Single Responsibility Principle, SRP)是Bob大叔提倡的S.O.L.I.D五大設計原則中的第一個。其中，職責(Responsibility)被表述為“變化的原因”(reason to

上一節我們通過兩個例子初步體會了REST狀態表述轉移的味道，但應該指出這兩個例子還僅僅是簡單的資源擷取。REST是以資源為核心的，沒有服務的概念，這的確讓人懷疑REST能否像ORB或SOA一樣支援複雜的應用？在回答這個問題之前，讓我們先暫時離開REST，把眼光轉向基於關聯式資料庫的3層構架。通常商務邏輯層對外提供若干的功能介面（中定義的IOrderService），對內通過資料訪問層訪問資料庫。我們知道，關聯式資料庫只定義了CRUD(Create, Read, Update,

前段時間有不少朋友發文討論TDD引起了比較熱烈的反響。我學習和實踐TDD有近一年時間了，也希望把自己對TDD的理解拿出來討論分享。本文講討論TDD的精髓和盲區，並希望引導TDD的初學者正確認識“TDD可以驅動得出更好的設計”這一著名論斷。TDD的精髓提到TDD，最先浮現在我們腦海中的多半是這幅經典的迭代流程圖：

介紹.Net的System.Net.Sockets.TcpClient和 System.Net.Sockets.Socket都沒有直接為Connect/BeginConnect提供逾時控制機制。因此，當伺服器未處於監聽狀態，或者發生網路故障時，用戶端串連請求會被迫等待很長一段時間，直到拋出異常。預設的等待時間長達20~30s。.Net

WaitHandle用於實現對共用資源的獨佔訪問，AutoResetEvent和ManualResetEvent都繼承自它。WaitHandle.WaitOne方法將阻塞當前線程，直到WaitHandle收到訊號。但有時候，我們需要非阻塞的方式測試WaitHandle狀態，翻閱MSDN發現WaitOne有多個重載版本，其中public virtual bool WaitOne(int

人們常常看著照片回憶起從前，清晰地感覺到童年，青年，中年，老年一路走來的各種變化。從這種變化中，我們可以抽象出3個關鍵詞：對象、時間和狀態。對象擁有狀態和標識，在標識不變的情況下，狀態隨時間發展演變。這代表了一種動態世界觀：時間本身並不屬於世界，世界是在時間維度上不斷演變的狀態。在這種世界觀的指導下，通過電腦程式類比現實世界問題時，我們用電腦中的對象狀態表示世界的狀態，用電腦中對象的狀態的變化表示世界狀態的變化和時間進程。與上面動態世界觀不同，另一種世界觀認為世界本質上是靜止的。怎麼理解呢？比如

    授之魚，不如授之漁。我共用100個根據自己審美眼光製作的Skin還不如教大家怎麼自己動手做呢～～畢竟大家審美眼光不一樣，在加上我本人又是色盲實在作不出什麼好外觀來。    工欲善其事必先利其器。首先得先教教大家怎麼用先進武器，要不然用“查看源檔案&抓圖”的方法做一個Skin恐怕要一整天。    首先出場的是微軟的IEDevToolBar，這是一個免費的轉為Web開發人員製作的IE外掛程式，做部落格Skin時用到的主要功能有：   

概述.NET基於委託的APM(Asynchronous Programming Model)模式通過BeginInvoke, EndInvoke,

原文：Test or spec? Test and spec? Test from spec! [作者簡介：Bertrand Meyer是Eiffel語言的創造者，他在著作《Object Oriented Software Construction》中提出的Design by Contract思想被視為與封裝、繼承和多態同樣重要的OOP思想。目前，Design by Contract已經以Code Contract的形式正式進入.NET 4.0。]  Which came first? As

 前幾天，我在北京參加了Lean軟體開發方法先驅Mary Poppendieck的“Lean Workshop”（精益工作坊）專場演講。如果說從形式上看，Scrum表現為一個個的迭代（Iteration），那麼Lean則表現為價值流（Value Stream）。Lean方法特彆強調了消除浪費，保證價值流快速順暢地流動。這個觀念不難被接受，但第一次接觸Lean開發的我對Mary提到的“進行中的工作是一種浪費”（Work in Process is

REST(Representational State Transfer)是HTTP協議的作者Roy Fielding博士在其博士論文中提出的一種互連網應用構架風格。與以遠程對象為核心的ORB和以服務為核心的SOA相比，以資源為核心的REST讓我們從嶄新的視角審視互連網應用。REST為互連網應用量身定做的簡潔模型、與HTTP協議的完美結合、構架的高伸縮性，為互連網應用構架設計和異構系統整合設計帶來了一股清新的空氣。本文希望與大家分享REST風格構架設計的體會，錯誤不足之處歡迎批評指正。

今天在dudu的《部落格園FAQ》上看到了部落格積分演算法規則。因為同樣是搞互連網的，平時工作也涉及到使用者積分演算法的設計，所以特把此問題拿出來分析探討。初衷只是純學術的研究探討，並不構成對部落格園積分機制的意見建議。 我們先來看看現行規則，用公式表示為：-------------------------------------------------------------------BlogScore = BeRead + 10 * BeComment + 50 *

經曆了一個3層構建的.NET企業級開發項目以後，對比J2EE的開發經驗（有自己的，也有交流獲得的），感覺.NET在3層構架裡面缺了點兒什麼東西。簡單說來，是缺乏業務層的應用規範（EJB）和應用伺服器（JBoss，WebLogic）。因此，在我們的.NET項目中，業務層是Plain Object封裝成的Windows Service。這裡，實際上有兩個對比：a. 應用規範 Plain Object - EJB；b. 應用伺服器 Windows Service - JBoss, WebLogic

單元測試本身並不嚴格限制過程式還是OOP，白盒還是黑盒，因而測試案例的寫法具有很大的隨意性。一些程式員對於C++/Java/C#等OO文法特性津津樂道，但卻沒有掌握OOP的基本思想。怎麼知道呢？就從編寫的單元測試用例就能看出來。單元測試用例的編寫可以直接反映一個程式員是否真正理解了什麼是過程式編程，什麼是OOP。我甚至覺得，如果在面試中要考察面試者對OOP的掌握程度，考察編寫單元測試是一種最好的方法。所以，本文打算介紹單元測試中狀態驗證和行為驗證兩種不同的方式，並分析其背後的過程式思想和OOP思