其他

1.協助理解需求單元測試應該反映Use

下面的這段C#3.0代碼看似再普通不過：Stack stack = StackFactory.New(); stack.Push(1); stack.Push(2); stack.Push(3); Console.WriteLine(stack.Pop()); Console.WriteLine(stack.Pop());

如果把系統視為多維對象，那麼UML的類圖、順序圖表、狀態圖、使用案例圖等就是在不同的維度上對系統建立的視圖。這種視圖除了維度差別，在同一維度下還有層次（粒度）的差別，比如：package diagram是比class

在我們熟悉的OO語言中，可以通過private、protected、public等存取控制修飾符將資料和方法分為內部可見、子類可見、外部可見等不同存取層級。本文從一個較為特別的封裝相關例子出發，討論封裝、類型系統、契約式編程相關話題。我們先從例子開始：Code highlighting produced by Actipro CodeHighlighter

OOP三大特徵沒有抽象是因為抽象不是誰所特有。過程式(C語言)有過程抽象，函數式(Lisp)有函數抽象，邏輯式(Prolog)有邏輯抽象。從宏觀上，抽象的角度不同形成不同的編程範式。微觀上，抽象在程式設計中無處不在，C語言中的宏“#define N 10”是抽象；變數定義也是抽象。 說封裝、繼承和多態是OOP的三大特徵，是由於這幾類抽象是OOP在宏觀上的主要抽象方式，它們形成了OO範式。封裝體現的是資料抽象，繼承體現的是層級抽象，多態是多態抽象。

記得原來在.Net 1.X中編寫發送郵件的代碼是使用作業系統的CDO組件中的CDO.Message來來實現的，因為這個裡面可以實現SMTP伺服器認證等一序列的發送郵件的詳細功能，不過不管是什麼錯誤都會提示是CDO.Message對象無法訪問或其它的CDO.Message異常，而在.Net Framework 1.X的FCL(Framework Class

最近一個開放API項目中，需要以xml形式向第三方提供結果。由於是開放介面，需要同時提供xml schema(xsd)，所以不得不花了些時間學習xsd，然後手工編寫。後來發現原來.NET Framework提供了從class自動產生xsd檔案的工具: xsd.exe。對於不熟悉xsd的朋友，提供了一個編寫xsd的捷徑便是：先編寫class，編譯成dll/exe，然後通過xsd.exe產生對應的xsd檔案。下面簡單介紹xsd.exe的用法：(1) 開啟.net framework

這是我在Agile Tour 2010成都站上做的一個技術報告，主要介紹了TDD的3大要素：測試為先、迭代增量和重構。報告著重探討了進行TDD開發所需要理解的幾個問題：1.TDD為什麼提倡先寫測試案例？2.TDD中測試案例的本質是什嗎？3.如何寫好單元測試用例？4.迭代漸進式開發與瀑布式開發相位元點是什嗎？5.迭代漸進式開發所產生的軟體分層結構與傳統的3層機構分層結構有何區別？6.什麼叫單元，單元與原子的區別是什嗎？

Agile領域的名人Vodde在多個國家呆過，而且有個中國老婆。最近他做了一個關於中國人普遍性職業特點的報告：Some people pay too much attention for improving their title, they are more interested in being a manager than being an professional.（更關注升職，而不是提升專業能力）Be kind to the people, willing to try new

boost::bind在建構函式對象時，實參傳遞是採用傳值方式的，中間會經過若干次的拷貝構造。對於不允許拷貝構造或拷貝構造效能開銷較大的情形可以結合boost::ref增加一個wrapper層避免拷貝構造。下面是範例程式碼：#include <iostream>#include "boost/bind.hpp"#include "boost/ref.hpp"struct A{    A(int aValue) : m_value(aValue)    {      

今天在微博上看到幾位敏捷愛好者探討敏捷測試和品質保證問題，我忍不住也加入了討論：Z先生：我剛才看到一個大會演講稿，談到敏捷測試六大指導原則：1.僅靠測試人員不可能獲得高品質的軟體，品質是整個研發團隊的責任；2.

boost::mutex is not re-entrant, a thread can only lock it once, otherwise it’s dead-locked. The following code snippet demonstrates it:#include "boost/thread/mutex.hpp"#include <iostream>boost::mutex mtx;void bar(){   

資料是什嗎？ 程式員每天都在和資料打交道，但我們能否清晰地回答這樣一個問題呢：到底資料是什麼?毫不誇張地講，這個看似簡單的問題在理解OOP思想中處於至關重要的地位。我們先從整數的例子來探討資料的本質：整數..., -1,0, 1, 2,...的本質是什麼呢？首先，我們對資料的直觀認識來源於其符號表示"0",

1.對自己好點，因為一輩子不長；對身邊的人好點，因為下輩子不一定能夠遇見！2.對不起是一種真誠，沒關係是一種風度。如果你付出了真誠，卻得不到風度，那隻能說明對方的無知與粗俗！3. 如果你知道去哪﹐全世界都會為你讓路。 4.我喜歡你，很久了，等你，也很久了， 現在，我要離開，比很久很久還要久...... 5. 純，屬虛構 。亂，是佳人。6.一個人只有一個心臟，卻有兩個心房。一個住著快樂；一個住著悲傷。不要笑得太大聲，不然會吵醒旁邊的悲傷。7.世界上最遠的距離 不是樹與樹的距離 而是同根生長的樹枝 

原文：Specification by Example作者：Martin Flower  [Martin Fowler這篇文章點出了TDD的核心理念：Specification by Example，即測試案例(Test Case)是一種通過例子(Example)來表達需求的規範(Specification)形式。]I was attending a workshop at XP/Agile Universe in 2002 when the phrase 'Specification

最近CoolShell上的一篇《TDD並不是看上去的那麼美》引起了敏捷社區的高度關注和激勵辯論。今天，InfoQ甚至專門舉行了一個“虛擬座談會”《TDD有多美？》，幾位國內敏捷社區的名人專門就此問題展開了深入地討論。不論結果如何，這種探討和反思的精神還是非常值得讚賞的。事件實際上可以簡單地歸納為“一個有一定影響力的開發人員質疑TDD，一群敏捷社區名人對TDD進行解釋和辯護”。現在，就讓我堅定地站在CoolShell一邊，為對TDD的質疑和批判添磚加瓦吧！ 我們首先來看看TDD的核心理念是什麼。第

Singleton模式通常被認為是比較容易理解和運用的設計模式。目前，網上已經有相當多的資料講解Singleton的基礎知識，本文試圖避免重複性的介紹，而是嘗試從不同的角度更深入地探討Singleton。“保證對象有唯一的執行個體，並且提供一個全域訪問點”是Singleton模式比較常見的描述。不知您是否意識到，這個定義本身就散發著某種"bad

曾經疑惑，為什麼是object oriented，不是class oriented？最近從一些建模經驗中體會到，的確是object oriented！ object在自己的life cycle內，沒有什麼不可以變，但不管怎麼變，它還它。class則是人為賦予object的功能或特性的抽象描述。

基於HTTP協議的Web API是時下最為流行的一種分布式服務提供者式。無論是在大型互連網應用還是企業級架構中，我們都見到了越來越多的SOA或RESTful的Web API。為什麼Web

C++物件模型 話題從下面這段C++程式說起，你認為它可以順利執行嗎？//C++class A { public:     void Hello(const std::string& name) {         std::cout << "hello " << name;     } }; int main(int argc, char** argv) {     A* pa = NULL;