致物件導向技術初學者的一封公開信
alistair cockburn 著（1996 年2 月），袁峰 譯
介紹 首先我要解釋一下為什麼會寫這封公開信。這似乎已經成了一種習慣，但這個步驟還是需要的。過去6 年中， 我曾經無數次地在飯店、酒吧、旅店大廳等各種地方以同一種方式度過愉快而漫長的夜晚：和同樣追求真理、光明和智慧型的夥伴一起**物件導向的真諦。現在，我已經可以回答很多當年我遇到的問題。這些同樣的問題也在困擾著我的一位新同事，在一家飯店裡，我花了整整乙個晚上和他討論這些問題。結果第二天，他的同事又來問這些問題，並建議把我們的談話內容記錄下來，這樣他可以拿去給他的同事看。考慮到還有很多和他的同事一樣詢問這些同樣問題的人，我決定寫下這篇文章。
主要的問題是：
z 為什麼只要稍有一點不是嚴格或純物件導向的做法、說法，oo 專家就大驚小怪的？use case 並不是物件導向的，為什麼還這麼流行？而且，oo 建模似乎和資料建模非常相似？
z 資料建模（data model）得到的模型和物件模型的結構部分會不會很像？流程建模（process model）和物件模型的行為部分呢？
z 業務結構建模中為什麼要用use case 和場景（scenario）?
oo 的新手們反覆問這些問題，但實際上，只有在日常工作中堅持應用物件導向的思維進行工作，積累一定的經驗，才能得到滿意的答案。為什麼只要稍有一點不是嚴格或純物件導向的做法、說法，oo 專家就大驚小怪的？use case 並不是物件導向的，為什麼還這麼流行？而且，oo 建模似乎和資料建模非常相似？
我想分三步來回答這個問題。
首先，我舉我和bob（著名的oo 專家）一起工作的例子， 當我們討論oo 的時候，彼此都有乙個共識，知道對方擁有物件導向工作的豐富經驗並且是這項技術的堅定支持者。而且，對諸如物件識別（object identity）、多型、資料和行為的封裝、例項職責、繼承等物件技術都是手到擒來。因此，當我說：「明天對程式表單進行資料建模吧」，bob 不會產生我要會因為關係表而放棄物件這樣的誤解，他知道我指的是在物件模型中體現出來的結構化特性進行建模。他知道我會說些什麼，因此我使用或誤用這些術語不會造成什麼誤解。但作為乙個物件技術的初學者，如果bob 發現你把資料和行為完全分離開了， 並且沒有使用（ 或者說忽視了）物件識別或者多型等技術， 這時候， 如果你說「 資料建模」，bob 會像一堵牆一樣逼近你，直到你明白該怎樣改變。這樣工作幾個月，你會發現，你的模型（以及建模）中漸漸有了物件識別、多型、資料和行為的繫結，這時候再用「 資料建模」這個詞就不是那麼危險了， 但bob 還可能會擔心你走回到老路上。換句話說， 他對你還不夠信任， 因此，你不得不很小心地使用這些術語。
就算乙個物件模型可以分為「結構」和「行為」特性，我們也不會使用「物件建模」和「流程建模」 這種術語，以免引起混淆。事實上，為物件模型的「結構」特性建模可以看成是資料建模的特殊形式，只不過建模的物件不再是表，而是需要捕獲的資訊的結構。我們將它稱為「 概念資料模型」，而不是邏輯資料模型或物理資料模型。第二步，讓我們考慮兩個oo 使用者一起討論的情況。如果其中乙個傢伙說到「流程建模」這樣的詞，肯定會讓他的拍檔琢磨半天：這傢伙是說用標準資料流圖作流程建模嗎？如果這樣的話，以後oo 實現的時候不是相當麻煩了嗎？他是不是指模型的行為特性？是不是說在乙個物件內部對流程進行建模？（如果這樣的話，那會很有意思，因為很少有人這麼做的。） 通過這個例子我們可以看到，這種談話中使用「 流程建模」 這種意圖不明的詞實在是太危險了，很容易就將交流變得非常困難。
最後來說use case 和場景的問題，它們都是獲取需求的主要手段，和實現技術無關。其好處是可以為設計時的討論提供內容和範圍。它們不是「物件導向」的，這是事實，它們類似於功能分解，這也是事實，而且這一點嚇壞了很多人，但這些都無所謂。重要的是它們為設計提供了內容，在用來描述內部設計時，它們表現了系統的行為。flow chart 、互動圖、petri 網、資料流圖、use case 都可以用來描述系統的行為特性， 但各自用途不同，各有優劣。關鍵是要知道：物件不僅有資料，也有行為， 認識到這一點， 就可以大膽地去考慮怎樣可以更好地捕捉、描述物件內部和物件之間的行為。
資料建模（data model ）得到的模型和物件模型的結構部分會不會很像？流程建模（process model） 和物件模型的行為部分呢？根據我的經驗，資料建模人員可以分為兩種－一種是為儲存的資料建模，而另一種是為系統或組織中的資訊建模。這兩者截然不同。前者討論和思考所用的概念通常都很具體，比如說資料表。他們的模型和oo 建模者的模型大相徑庭，而且他們並不願意看到這些技術之間的相似性。在資料建模社群中，只有討論邏輯資料模型或物理資料模型才不會受到攻擊後者得到的是概念資料模型。根據我的經驗，他們得到的模型和那些有經驗的oo 建模者得到的模型非常相似。他們的工作更加類似於業務人員，而不是邏輯資料建模人員，這種說法可能會有助於理解概念資料模型和邏輯資料模型的區別。
似乎有一套學問可以幫助人們比oo 建模人員更快地得到結果。我多次發現這樣的事實：oo 建模人員花了三四次迭代才得到的模型，實際上和（概念）資料建模人員乙個迴圈得到的模型是一樣的。這個發現使我對資料建模人員充滿了敬佩。事實上，在進行物件設計的時候，我有時就直接去把資料建模人員的產品拷貝過來看看， 從中來看我最後得到的模型大概會是什麼樣的。
我曾經召開過資料建模人員和物件建模人員之間的會議。採取的方法是「 乙個聽眾的crc 會議（crc sessions for an audience）。四個經驗豐富的oo 設計師坐在長桌一端，業務專家沿著長桌坐下，他們負責回答問題並糾正對業務的誤解。接著是資料建模人員，長桌的另一頭是其它有關人員。總的來說，屋裡大概是十幾個人，但談話主要是在四個oo 設計師之間進行。
討論大概乙個小時之後，oo 設計師可以得到物件設計的一部分。這時候，諮詢資料建模人員，這個模型和他們已經得到的模型本質上是不是一樣的。他們說，「是的」，重複這個過程兩次以上，每次都詢問資料建模人員同樣的問題，除了使用的符號技術是不同的，例如：他們沒有用繼承，但在同樣的地方有同樣的佔位符，在本質上，這個模型和他們的模型沒有什麼不同的。接著，我們分成幾個小組，每個小組包括乙個業務專家、乙個資料建模專家和乙個oo 專家，很快就剩下的設計達成一致，找出技術上一些小的不同之處，並且進行排序。一般情況都是這樣的：要麼資料建模人員考慮得更加合理，要麼oo 建模人員考慮得更加合理，小組要做的是在他們的設計之間進行協調。
從上面的這些經驗可以看到，使用crc 進行oo 建模得到的模型和概念資料建模得到的結果非常相似。另外，根據經驗，基於邏輯（儲存的資訊）的關係建模和oo 建模是不同的。大多數情況下，區別是由於技術的不同導致的，例如，在oo 模型中可以自由地使用繼承和多對多的關係。由於技術上的差異，兩種建模人員之間不能很好地交流，這是最大的困難。
資料建模部分的問題就說這麼多吧。
寫給 Linux 初學者的一封信
這篇文章是寫給 linux 初學者的，我會分享一些作為初學者應該知道的一些東西，這些內容都是本人從事 linux 開發工作多年的心得體會，相信會對初學者有所幫助。如果你是 linux 老鳥，那可能就不需要再往下看了 作為從事 it 工作的同學，對 linux 系統一定不陌生。如今我們在各種領域都能看...
致UChome站長們的一封公開信
致uchome站長們的一封公開信 乙個人的力量是不夠的，這是我乙個人在做 的時候深刻感覺到的。在我昨天登陸uchome論壇的時候，看到眾多各自 占山為王 的站長，不禁滋生了乙個念頭 假如我把uchome的站長們整合了，把 一千個人做成一千個uchome 變成一千個人做乙個uchome 是不是那樣能把...
乙個初學者的辛酸路程 物件導向 7
輪物件的重要性 物件導向程式設計 oop程式設計，模板和實際的物件來建立各種模型 class類 就是模板 先寫乙個模板的原因是，後面會建立多個人，只是想傳幾個引數來建立多個人。這樣大多數功能就不需要重寫了。類，就是對類擁有相同屬性的物件的抽象，藍圖，原型。每個物件可以有不同的屬性。手把手教你寫乙個簡...