oo直接翻譯過來就是「物件導向」，它作為一種程式設計思想可以說是劃時代的進化。雖說可能不是傳說中的「銀彈」（解決軟體太複雜的萬能靈丹），但是卻能使掙扎在「焦油坑」中，那些絕望而無助的受難者猛然間看到希望。寫《人月神話》的時候oo、持久化等概念便會自上而下的體會到。到那時，我們或許會因為與前輩在思想上產生共鳴而會心一笑。
光說不練假把式，這裡拿乙個例子來結尾。大學oo教材有個電梯建模的習題，需求簡單明瞭，就拿這個舉例吧。
現 實生活中，坐電梯無非就是涉及到以下一些內容：電梯、人、樓層、訊號燈、上、下、開門、關門……軟體建模就是一種「思想實踐」，這些內容都是在我們腦子 裡，並不是要造出實體。所以，可以根據上面獲得一些零散的資訊，抽象的歸納客觀事物的對映。比如，什麼是電梯？電梯是能上能下將人送到預定的樓層。好了， 有了這個簡單的定義（不一定要求很準確，只要在可容忍的範圍就行，而這個範圍是系統願景確定的），我們大致歸納出電梯的屬性有：樓層、訊號燈、電梯門這 些。這個電梯類具有的行為可以有：上、下、停、開門、關門。這裡為什麼不把樓層和人單獨歸納出乙個類來？因為人其實是電梯的使用者，而樓層在坐電梯這個客 觀事件中只是乙個數字，並沒有什麼行為。
但是，坐電梯這個事件，光有個電梯似乎還是不行的。因為，還要符合將人送至他想到達的樓層的願望。這就涉 及到人在哪個樓層，他是上還是下，他要上或者下到幾樓。這裡我們找不到客觀實物來對映到軟體模型，不像電梯類是客觀現實中存在的實物。那麼，這裡我們就要 抽象歸納出客觀世界中看不見，摸不著的東西來。回到現實中來看，例如電梯在1樓，5樓有人要下，那麼電梯就上到5樓，停下來，人進去。電梯根據人的指令， 下到他想到的樓層。如果電梯在1樓上到5樓途中，2樓有人要上，電梯就會在2樓停下來。再如果，2樓的人要去10樓，電梯就不會在上的途中停在5樓，而是 上到10樓後停下來，再下到5樓停下來。這樣我們就可以發現——電梯只管上和下，至於在**停，則是根據人發出的指令。而這些指令其實就是一串數字，一串 要求電梯在**停的數字，而且是隨時可能變化的。比如，剛才說的那種情況，停車數字是1（電梯開始停的樓層）、2、10、5、1（5樓要下的樓層）。這 樣，我們就可以抽象出乙個類，乙個客觀現實中看不到，摸不著的類——電梯停佇列類。這個類屬性有最高層、最底層、需要停的樓層，行為有新增需要停的樓層， 移除需要停的樓層。
下面是對應的類圖。
從這個例子中可以看出，電梯類很容易找到。但是電梯停佇列則是我們對現實世界中的業務流程進行歸納、抽象得出來的。所以，我認為，軟體建模的重心，其實是在對業務流程的抽象上。
上 述整個過程符合人們日常慣性思維，現實和模型對映起來很自然。可以將這個過程看成是乙個「建立世界」的過程，是一件很愉悅的過程，最起碼我是非常喜歡這種 「建造」軟體模型的過程，這種抽象抽象再抽象的過程。這個例子需求簡單明瞭，我們很容易就收集到了足夠的素材來歸納、抽象。如果是在乙個陌生的領域建立軟 件模形，抽象素材從**來，怎樣抽象？我們就要探索需求，而探索需求過程不僅限於
oo，但是
oo的思維方式卻能更好的和問題域中的專家溝通，更好的理解需求。
設計模式之美筆記 抽象類，介面
設計模式之美 8 設計模式之美 9 目錄 面試中常見的問題 抽象類的特點 介面的特點 抽象類存在的意義 介面存在的意義 抽象類和介面的應用場景的區別？如何用抽象類和普通類來模擬介面？基於介面而非實現程式設計的原因？有必要每個類都定義介面嗎？介面和抽象類的區別是什麼？什麼時候用介面？什麼時候用抽象類？...
設計模式之美 介面和抽象類的區別
抽象類 抽象類不能被例項化，只能被繼承 不能new 抽象類可以包含屬性和方法，方法可以包含實現，也可以不包含實現 abstract方法 子類繼承抽象類必須實現所有的抽象方法 抽象類也是類，跟子類的關係是is a 繼承本身並不要求父類是抽象類，但是抽象類編譯的時候會要求子類強制實現抽象方法。介面介面不...
SGlab之創立錄
sg lab，顧名思義，sim game lab是也。sim game，其實就是simulation game，翻譯成中文就是 企業級 模擬遊戲，是serious game 嚴肅遊戲 的一種。實際上就是一種以遊戲的形式模擬現實商務流程，從而為使用者提供諸如培訓 體驗 宣傳等服務的一類計算機軟體或者系...