==> 在 william@cis_nctu (何陋居主) 的文章中提到:
> ==> 在 yuanchang.bbs@cszone.cc.ntu.edu.tw (小璋璋) 的文章中提到:
> > 所以要學好C++，從入門到真正能不覺得
> > 窒礙難行地寫出具有OO精神的程式，我估計這時間不會太短，
> > 其中或許還參考過各家門派的書籍，與C++某些語法搏鬥
> > 過不少地時間。換算下來，值得嗎？ 如果肯思考這問題，
> > 你就會認為，不是每個人都需要C++的，即使多數人喊出來
> > 的看法是，C++才是貴族。
> 對新手來說, 學好傳統的結構化設計方法, 也是要花相當時間,
> 才能有所謂「真正能不覺得窒礙難行地寫出具有結構化精神的程式」的表現。
> 好的洞察力、好的書籍、好的良師益友, 能降低門檻、催化進步。
> OO 亦如是。
不過在職場上,許多主事者並不在乎你是用什麼設計方法來開發軟體,他只要能交差就好.
因而往往扼殺許多有志學習OO的技術人員.我這樣說並不是反對學習OO,而是依據我的
經驗,以往在職場上要堅持用自己想用的技術來開發軟體,對於人微言輕的年輕技術人員來說
那是需要很大的勇氣,毅力與決心.另外我必須說明,千萬不要有想在幾個用內就想學好
的想法.我常常看到許多專案,專案成員都沒有運用OO技術的經驗,就很勇敢的要在幾個
月內用OOA/D/P來建構完成,這樣的下場通常是慘不忍睹.
> 固然「不是每個人都需要C++的」, 或者更進一步講「不是每個人都需要 OO 的」,
> 不過, OO 已侵略性地進佔越來越多的傳統領域,
根據我初步的整理就在這兩年(1998、1999)，許多以OO
為基礎的資訊技術領域都有突破，例如：
系統分析/設計
分岐的OOA/D符號語言逐漸統合─UML(Unified Modeling Lanuage) 1.2/1.3、OPEN。
程式語言
Java語言的更新(Java 1.2/2.0)、ISO/ANSI C++標準的制定。
作業系統
系統核心走向物件導向化─Windows 2000
資料庫
許多原為關連式的資料庫系統逐漸整合物件技術─
Oracle 8.0、IBM Universal Server、Informix Universal Server、
Microsoft SQL Server 7.0
傳輸協定
逐漸普及與強化oo支援─ORPC(DCOM)、IIOP(CORBA)、JRMP(JAVA RMI)。
分散式物件模型
更新的標準─CORBA 3.0、COM+、Enterprise Javabean(EJB)
主從架構
朝向以分散式物件為基礎的多層式主從架構
> 所以, 能夠在你所在領域還沒變天之前就先領略（領略 ≠ 使用）, 總是比較好的。
> 等到一夕變天再去緊張得抱佛腳, 是很悲哀的事；
> 尤其是到了你已不太能也不太想去適應新變局的年齡或人生階段。
> > 至於有些人整天OOP喊不停，大家要注意到的是，他所從事
> > 的工作，以程式設計者來說，我是完全把語言當成一種工具
> > 看待。但是一個教育者會比較傾像學術氣息，至於實用
> > 方面，則擺在較後面的層次。
> There is no silver bullet.
> 所以學術人士致力於探勘探索各種潛在的可能解, 並致力於發掘出各解的極限。
> 學術界探討的東西, 往往要幾年過後才會在實務界看到大用。
OOA/D就是一個最好的例子.從1960年代在瑞典萌芽至今也有三十多年的歷史,不過
在實務界被廣泛使用那是在最近這幾年.前幾年如果有人說OO技術比較傾向學術,
我需不甚贊同但也不太能找出有力的論點來辯駁.但是現在?我可以很大聲的說,
OO技術已經是軟體開發技術的主流了!就以我去年去美國參加開發工具的研討會
為例,UML/OOAD/Distributed Object等相關議題非常普遍,甚至許多與OO議題
不甚相關的講座也會穿插UML等等圖例.難道我們還要自絕於世界潮流之外,不學
,不用,不聽,來進入二十一世紀嗎?
> > 又許多人腦海中的觀念是：學會「程式設計」，就可以寫出
> > 心中想要的程式，在還沒有經驗的時候，我也是這樣
> > 的想法。當你費盡九牛二虎之力才學會某一種語言，
> > 最可悲的事情就是派不上用場，你不知道要寫些什麼，
> > 而學習過程中那些狂熱的心態，只能淪為經驗值的獲取。
> > 事實上不論一個人語言功力多強，並沒有辦法幫助他
> > 獲取更好的IDEA來實作，不是嗎？
> 這倒是。
> 不過, 過於偏重「程式語言」層面的功力, 也是錯誤的。
> 沒有與之搭配的形而上思維, 等於是無頭蒼蠅亂飛亂竄。
> 九牛二虎的付出, 若是付出錯了方向, 也別想得到九牛二虎的經驗值。
> 最近受人之託, 要去工ｘ院 N 減一組講幾天的 OO 引介課。
> 不過, 由於對象是與 mobile computing、MAC protocol、embedded system 工作
> 相關的工程師, 且多半是 EE 出身的, 就很煞費思量...
> 總不能舉一堆由 CS 及 information system 類比過去的東東做為切入角度吧
> （如：資料結構、ADT、E-R model、結構化系統分析／設計／程式設計...）
> 如果聽眾是 CS 背景的話, 這種切入方向就很適合。
> 所以, 大概會偏重 UML 的 dynamic 層面來講, 少講些 static 的層面。
> 與經理談了一下, 大概把自己的預期心態調整了一下。
> 不必要求講完之後, 聽眾能真正領略多少（畢竟要這些在本職上不太用得到 OO 的人
> 且背景知識與訓練上根本不太 CS 的人一下子就領略得了 OO, 是項苛求）；
> 只要有某些理念傳達過了, 讓他們在未來有適當情境時, 能夠有些 inspiration 作用,
> 能夠有些 guideline 作用, 就夠了。
這一點我有一些不同的意見,雖然有些時候傳達OO理念要因人制宜,不得不作某些精簡.
但是千萬不要讓他們有像"OO就是這樣而已"的感覺.尤其我認為不能為了幫助理解而只
隨便用一些不著邊際的範例(例如前些日子就有人用歷史故事來闡述OOA/D),
而忽略了OO技術面的原理與嚴肅性.因為台下的聽眾可能有一些非工程師的管理人員,
他們如果有了不實的似懂非懂觀念,反而更會造成往後推動OO技術的困擾.況且軟體開
發到目前為止,不論用OO或結構化技術,它的失敗率仍高居不下(保守估計也有七成以上).
所以我認為有必要強調軟體工程面的嚴肅性.因此我認為最起碼要搭配一個完整用OO
技術開發的實例並以此來剖析OO技術實行的要件與可能面臨的問題才能使台下的聽眾
有較實際的感受.也才能夠以更務實的態度來面對OO技術所帶來的調適問題.
> > 我認為真正做學問的態度，是在很自然的狀態下學習，
> > 或許也為了一個小小的目標，而且不必刻意去背，
> > 只要能再需要知識派上用場的時候，能夠快速索引到需要的資料即可。
> 有些東西是可以等到要用時才去「快速檢索」,
> 但有些東西可不是所謂的「等到要用時才去『快速檢索』」即可成事；
> 否則一些 open book 的考試, 怎麼反而更讓準備考試的人心驚膽跳？
> 有些東西, 重點是「心法的養成」。
我想"心法的養成"應該是指要熟習"核心技術"與捉住OO的精神.比如說要學C++,如果只會
程式迴圈,Call API,依然照以往的直覺來寫程式,那麼"快速檢索"像MSDN或書籍所得到
可能只是囫圇吞棗與閉著眼睛Copy&Paste,寫出來的軟體久而久之就好金庸筆下的"吸星
大法",一開頭雖然好像很不錯,可是久而久之,吞得愈多則反噬的力道愈大,最後系統就連
大羅金仙也難救.
但是如果你捉住OO的精神,熟習C++的OOP,STL等核心技術,雖然在寫實用程式時免不了要
查閱像MSDN之類的技術資料,可是你的"主架構"穩固,就好像自行修練的"內力"深厚,這樣
才能經得起考驗.
--
唯有真情才是可貴的
--
* Origin: ★ 交通大學資訊科學系 BBS ★ <bbs.cis.nctu.edu.tw: 140.113.23.3>