在去野三坡的途中，和linc談**車的架構來，感覺其擴充套件性特別好。車廂可以載人，可以載媒，可以載貨，可以載坦克，可以載飛機，火車頭可以有乙個，也可以有多個，可以在兩頭，可以在中間。
回來以此為題，大家一起討論一下設計。
一直認為，設計如哲學一樣，大道同源。其道理一定可以應用到各個領域。因此火車也需要設計，因此軟體也需要設計。
那好，我們開始設計吧。
這時候，你想到了什麼？火車的擴充套件性？
是的，至少我們討論的時候，第乙個想到的就是這個。因此我們開始考慮應該提供乙個基類，來描述什麼樣的是車廂，所有滿足此條件的車廂就可以掛接到火車上了。
有什麼呢？輪子、前後接軌。底盤。還有人提到是不是應該有電源介面。也是有一定道理的。正當我們大聲討論還有哪些特性的時候，linc終於忍不住要發話了。後來證明，他早就如鯁在喉，不吐不快了！
linc講到，我們的設計不要一下子深入到細節。有道理！大凡設計，大概有兩種基本方法，自上而下和自下而上。一般在架構的時候，我們都採用自上而下的方法來統攬全域性，而到細部設計的時候，我們採用自下而上的方式保證不遺漏細節。
顯然，linc同學的想法已經不是一天了，他迅速地在紙上描述出自己的構想。
考慮火車由什麼組成：火車頭和n個車廂。於是linc同學認為，火車的能力和是有各車廂的能力體現的。那麼抽象乙個此行為的車廂，整個火車都是這個車廂的派生類（呵呵，想法比較大膽啊）。火車車廂再按照功能分類。有動力車廂、載人車廂、載貨車廂等等。對於火車來說，你不要關心其組成細節，它有幾個火車頭？幾節車廂？你都不需要知道。只告訴你火車能做甚麼。linc稱這就是組合模式（composite）
後來，我們曾經就什麼是組合模式，大大爭論了一番。最後發現我原來對組合模式的理解是片面的。這是後話。
設計如果就到這，就不能體現什麼是設計了。至少我是這麼認為的。我提出了另乙個想法（其實我之前沒有好好考慮過，但是聽了linc後就有了這些想法，這也許就是集體的力量吧，或者說是：頭腦風暴？）。
我們其實還是在考慮火車的結構，不管是細節還是架構！我想設計應該從更高點看問題：火車是什麼？火車對「外」提供哪些功能？火車要能走軌道，能進站，出站，能緊急剎車，能倒車掉頭，火車能懸浮？火車能充電？等等。
物件導向設計中，最開始都是先要找到物件，然後再看其結構及其完成功能所需要的架構。
經過這些討論，我們慢慢地對火車有了逐漸清晰的理解。我們的討論看似比較隨意，但稍微留心，其實可以發現我們討論乙個完整的設計的時候的思路。
1、物件導向分析：找出物件，及外界對物件的要求（功能）
2、物件導向設計：架構出組織結構，及實現思路
3、面向介面設計：區域性設計、優化。
我們平常最容易一開始陷入的就是第3個，典型的自下而上方式。上面提的這個思路當然不是絕對好，只是可以幫助我們進行理順思路。有句話說的好，過分關注細節，會讓我們因為沒考慮到而放棄，而關注高層，會讓我們因為考慮了而放棄。
咱們很多人不能夠有機會參與完整的專案設計，但是，只要我們把乙個小問題詳細完整地進行考慮，思路是一樣的。多做這方面的討論，能給我們帶來很多意想不到的收穫。
從畢業設計看技術創造過程 原創
從畢業設計看技術創造過程 摘要 科學技術是第一生產力 這一思想已被人類社會的文明史見證。在當今的世界裡，科技已在全球範圍內受到重視。大規模的科技隊伍與科技資金被投入於科學實驗與生產實踐。一方面 科技在推動生產力發展中的作用越來越高。另一方面科技轉換為生產力的速度越來越快。本文章旨在通過本人的畢業設計...
回看儲存過程
週六週日寫了些查詢的視窗，感覺沒什麼新奇的東西，都是一堆select，後來寫的到了註冊，上下機等，在乙個方法裡面，包括了多個增刪改查的過程。可能上乙個訪問資料庫的過程返回的結果又是下乙個訪問資料庫讀取資料的引數。也就是說，這些對資料庫的增刪改查是乙個連貫的動作，比方。註冊乙個學生的時候。涉及到註冊金...
看設計模式有感
一 小菜 菜 嗎?最近一直在看大話設計模組,一本故事專業書.給我的乙個很大的感覺就是小菜不菜 書中把那個總是提出問題,設計的東西總是有缺點的同學叫做小菜.但是看的多了,有心裡感覺到.小菜不菜.比如剛開始的第乙個程式,讓寫乙個電腦程式.小菜很快的就寫完了,最然說是基本上都是一鍋粥.但是主要的作用還是都...