網路雋語集
[
價值 |
心態 |
順序
]
發信人: david , 信區: oop
標 題: Re: 【主廚推薦 侯捷菜單】
時 間: 1999年 1月22日 周五 13時55分20秒 CST
小弟斗膽推薦一下,不過至於書評則不敢
1. "Design Patterns: Elements of Reusable Object-Oriented Software",
Gamma, Addison-Wesley, 1995
Pattern書籍中的經典,
我大約看了二至三遍 (其中第二章略掉), 自己也有一至二年的應用經驗,
當你第一次接觸到pattern時, 就好像你在大一或大二時接觸到data structure,
覺得他實在很震驚, 很powerful.
你會很難想像OO原來是可以這樣用的. 從前在聽別人說OO可以reuse,
可以很有彈性來擴充, 可是在自己寫程式時, 總是少了這份感覺,
覺得別人說的是一回事, 自己的code又是一回事.
會感覺到有 reuse 有擴充性, 只有在用到繼承時才會有感覺.
可是呢, 在我的程式中幾乎出現不了會有繼承的情形發生. :( .....
當我看完這一本書之後才完全對OO改觀. 漸漸開始感受到OO的魅力,
此時也進入我對pattern第一個時期, 這時候我在做project,
會拼命想用pattern到我的程式中. 可是這時我自己卻不知道我這樣做是錯的,
因為事實上我並沒有想清楚自己要解決的問題本質是什麼?
它的運作行為是什麼? 要採用何種解決方案是最佳的?
勉強著使用pattern的下場自然是效果不彰.
這種情況就好像許多人常看到某一項新的技術或是新的產品推出時,
就想趕快使用, 趕快加到自己的程式中,
而沒有考慮到是否適用,及對其掌握度是否足夠, 因此下場是可以想像的.
之後便漸漸地開始修正自己,要先真正了解問題為何, 自己要提出什麼解法,
然後才來看是否有pattern正好滿足我的需求. 以上大概是我的使用pattern心路歷程.
2. "Analysis Patterns: Reusable Object Models",
Fowler, Addison-Wesley
這一本書基本上我建議初學者完全先不要看,
若是沒看過design pattern的最好也不要先看.
為什麼呢?因為它抽象化的程度比design pattern還要高,
並且它所探討的部分你需要具備要某個領域的專業知識,
否則你是不容易理解的.
舉個例來說吧. 他第二章在談人力組織, 如果你對人力組織沒有概念,
你可能會不知道通常在談這問題時, 是會以職務為主軸,
也就是你當初在成立一個專案或部門時, 你需要事先的規劃及評估,
需要有多少業務經理, 多少行政人員、業務員、程式設計師、分析師、測試人員等等,
都是以職務為中心來考量. 定出這些職務之後,
日後在考慮要請人來擔任這職務的問題, 因此會有職務存在卻沒有人來擔任的情形.
因此若在沒有這領域的情況下, 你可能以人為中心來考量, 來了一個人之後,
再安排它的職務,所以在你的object model中便會以員工為出發點來model,
跟以職務為出發點來model自然是差很多的. 所以我建議當你有一些領域知識,
或是你想建立一些領域的再用元件, 這時候再來嘗試去看這本書會較容易接受的.
否則在你只有coding 的knowledge, 來看具有領域知識並且抽象化層次高的object
model, 你會叫苦連天的
3. "AntiPatterns: Refactoring Software, Architectures, and Projects in
Crisis", Brown,Wiley,1998.
pattern的另類巨著, 把pattern推到一個不同的世界.
通常我們在談pattern時會說遇到某種情況下的問題時,
我們可以套用某種pattern的解法來解決.
而antipattern則是告訴你若是某種狀況發生時, 你大概就完蛋了,
你可能會有許多麻煩發生,
這時候它會提出一些解決方法告訴你如何挽救.這書我不太熟悉不敢有太多著墨,
只知這書在 OOPSLA98 時評價不錯, 若有先進閱讀過請分享一下心得
4. Pattern-Oriented Software Architecture: A System of Patterns,
Buschmann, Wiley.
當你看完第一本時, 這一本的意境就不太高了, 這本書我個人只列為optional.
它介紹了一些 architectural pattern, design pattern, 及 idoms,
不過大多可由第一本變化衍生而出.
5. Pattern Languages of Program Design 1/2/3, Addison Wesley
一些pattern文章收集的書籍, 裡面有一些當時或現在不錯的paper,
你可以欣賞不同的漂亮解法,是屬於pattern進階篇的參考書籍
以上大概是屬於pattern類的好書,若有不足或不正確之處請多指教
柯仁傑
發信人: capita.bbs@bbs.tku.edu.tw (小明), 信區: oop
標 題: Re: 這本書值得一看
發信站: 淡江大學 BBS (Wed Oct 7 10:31:28 1998)
《 在 dyliu@ms1.hinet.net (四眼的王蟲) 的大作中提到: 》
:
: 不過 design patterns 這本書的確是想學 OOP 的人
: 都應該看的經典 (我是看過啦)
:
: 四眼的王蟲
不只是應該看，更重要的是最好認真去想，
每天叨叨唸唸把每一個 pattern 的可能應用都想清楚，
它不只是讓讀者可以對 OOP 有更進一步的認識，
而且更可能是進入另一個程式設計世界的大門。
我覺得要看懂這本書的個別 pattern 很容易，
但把 pattern 的觀念掌握好才是更重要的事。
design pattern / pattern language 是差不多 1993 或 1994 年
開始流行的吧，那時國外的專業期刊上都是這個題目，
看過這本書後，最好也多去圖書館查一查那些討論，
那時很多人都看不懂那些討論，看過這本書之後再去讀，
應該會看到比較多的東西。
只要好好搞懂任何一個 pattern，就可以建構絕大多數的系統，
能夠純熟運用二、三個 pattern，更可以將程式的延展性發揮到最大。
前一陣子不是有人在提 connector 嗎? 就像那樣，
能夠運用單一而純粹的 pattern 來建構各種系統，
會比平常用各種方式建構系統還要來得更強而有力。
一些流行過的東西，像 n-tier, c/s, vm 等等，也不過就是如此。
每一個 pattern 都是一個世界，這本書可說是個新世界的地圖集了。
不管最近流行什麼程式架構，你都將能快速地掌握要點，
讓你能對這些新東西感到不屑或是馬上變成某某技術的專家。
很多人看過這本書，但懂得 pattern 精義的人則少之又少。
多半是看過，喔，很了不起，整理得很好，學到不少東西，
卻再也沒有其他啟發了。
當一個人有能力只用一個 pattern 就寫出程式，我覺得，
那就是真正成為程式設計高手的開始，這時程式設計才有所謂的藝術可言，
在此之前的全部，不過是學學數學、玩玩技術、搞搞工程和用用管理。
當然，大多數人都還在玩玩技術的階段，是唸不下也唸不通這種書的。
搞不好變成「下士聞道，大笑之」那就有些可悲了。
--
※ 來源:•蛋捲廣場 bbs.tku.edu.tw•[FROM: 163.13.93.101]
發信人: kojenchieh.bbs@bbs.csie.nctu.edu.tw (david), 信區: CompBook
標 題: Re: [書訊] 物件導向設計模式 Design Patterns
發信站: 交大資工鳳凰城資訊站 (Tue May 15 08:38:38 2001)
※ 引述《william.bbs@bbs.cis.nctu.edu.tw (何陋居主)》之銘言：
> ==> 在 AlanTsui.bbs@bbs.kimo.com.tw (AlanTsui) 的文章中提到:
> > 這本書真的那麼好嗎 ?
>
> 見仁見智。
>
> 不過, 這本 1995 年的書, 居然還能在 Bookpool 的
> "Software Development" 排行榜上名列第一
> (見 http://www.bookpool.com/.x/a5h8wqmxp6/ss/L?su=sdv),
> 居然還能在這幾個月內先後有了簡體繁體中譯本出版
> (簡體版書訊見 http://www.jjhou.com/jiang-design-patterns.htm),
> 應該有它的道理。
我記得amazon上是經過80~90人以上還有4顆星半評價, 是本天王級巨作
> > 我到過 amazon.com
> > 好像是 1995 年出版的吧
> > 如果用在 Java 上, 會否有點過時 ?
一點都不會, 如何你真的懂得pattern的精髓. 這該怎麼說呢.
當我第一次看到這本書時, 他給我的感覺就好像我第一次學
資料結構一樣, 原來程式是要這樣設計的才會又漂亮又快. 同理
你可能學OO很久了, 常常聽到OO有多好用, 可以reuse, 設計時
可以多有彈性及擴充性, 可以當你在用的時候常常會有諸多懷疑.
這本書這是在教你, 在設計階段時, 遭遇到一些問題你要如何設計
才會具備有那些好處, 也讓你看到原來OO是要那樣設計那樣model的.
尤其是那些拿OO來做功能式拆解的人, 更是會震撼
原來以object為主的設計方式是完全不同的
柯仁傑
發信人: "david" , 信區: oop
標 題: Re: RunPC此期的design pattern
發信站: III InterNetNews News System (Sun Mar 7 11:09:25 1999)
kylin <QueenLin.bbs@cis.nctu.edu.tw> 次寫入到主題...
> ==> 在 "david" <davidko@iii.org.tw> 的文章中提到:
> > kylin兄：
> > 我忘了你的email, 因此在板上問個問題
> > 你覺得RunPC此期的design pattern寫得如何?
[略]
> 事實上, 在我看到您的post時, 我尚未收到雜誌, 不過我特地跑了
> 一趟書局, 去瀏覽這篇文章。有些失望。就一位未接觸過Pattern這
> 個主題的讀者來說, 我覺得會像是霧裡看花, 霧非霧, 花非花。不過,
> 看樣子這是一系列的文章, 不曉得後續會不會讓讀者更明白 Pattern
> 為何物? 從何而來? 為何而來? 又將何往? ......。
我的感覺和你有些相像, 在這篇文章中對於pattern是什麼東西
並沒有交代清楚, 因為我想絕大多數的讀者對於什麼是pattern並不了解,
不知道它是什麼東西? 定義究竟為何? 因此當他帶出singleton時, 我想大家
可能會有個疑問? 為什麼singleton是一種pattern? 這種這麼簡單的東西為何
算是一種pattern? 不知道看過此篇的讀者是否有此感想?
不過他在講解singleton的例子時算蠻順暢易懂, 讓讀者能很了解如何
實作singleton. 但是這一點我有點意見, 因為我怕讀者會誤解一個重要的觀念:
design pattern重點是在於他pattern所帶來觀念, 而例子只是輔助而已.
你必須要真正領悟這些觀念. 在你設計系統時, 才能真正使用到這些pattern.
因為根據我學習以及教同仁的的經驗, 在一開始學習pattern時很不容易入門,
常常搞不清楚他是什麼? 為何要這樣設計? 通常是看了例子才有初步的了解.
但是重要的是在看完例子後, 要回頭用力思考他所要表達的涵意是什麼?
適用時機是什麼? 此pattern的優缺點是什麼? 這樣你才是真正學會一個pattern.
此外他也沒交代為何一個pattern要這樣來描述? 也就是分成 目的、動機、
結構、及範例等部分, 不知道的人還以為他很有條理, 事實上在design pattern
一書中規範了一個pattern要如何來描述, 書中分成了下面幾個部分:
(這裡只是我憑記憶所寫,可能不是很正確及完善, 請大家多指教)
1. Intent: 這pattern企圖所要解決的問題
2. Motivation: 用個小例子來帶出為何有這個pattern以及問題的解決手法
3. applicability: 這pattern適用的時機
4. structure: 這pattern的object model或示意圖
5. participant: 描述第四部分圖中各成員所負責的工作
6. collaborations: 描述第四部分圖中成員之間互動的關係
7. consequences: 總結這pattern的優缺點
8. implementation: 介紹實作時因不同狀況可採用的手法
9. sample code: 用個範例來讓讀者了解
10. known uses: 目前已有哪些已知的產品、工具或研究在使用這pattern
11. related pattern: 和這pattern相關的有哪些pattern
我想如果他能就這幾部分多加描述, 我想會引起更多人有興趣去看
這本書. 因為你真的不容易看到, 有人對一個問題的解法有這麼深入的探討,
當初我看到作者說要分成這麼多部分來介紹一個pattern時,我真的是十分震驚,
他真的能把一項技術做這麼深入的剖析嗎? 這樣的作者真的是不多見.
國內可能只有侯先生是屬於這類型的, 國外雖然比較多, 但是在你自己
有興趣的領域內, 可能還是數的出來的.
最後這個意見可能是比較不容易的, 就是希望他能否介紹一些他使用
的經驗? 或是應用時是否有新的變形應用出現? 或是有特別痛苦或要小心
的地方要注意? 不過這是我個人的希望而已, 我想是有點難做到,
因為要在一篇介紹性或入門的文章中要談這麼多, 可能大多的讀者會受不了的.
但很不容易的, 畢竟火先生已跨出第一步, 希望往後他能再進一步深入介紹
更多的好東西給讀者們, 以上是我個人小小感言, 歡迎指教.
發信人：William Yeh
標題：Design Patterns
日期：05/15/2001 : 22:07:32
發信站：Programmer 深度論壇
信區：OOA / OOD / OOP
※ 引述《ycj》於 05/15/2001 17:31:40 發表之銘言：
>
> 其實Adapter與Strategy也很難分, 雖然一個是Structural Pattern,
> 一個是Behavioral Pattern, 尤其在設計程式時選擇實作的方式時.
> 例如, 假設某一問題需要提供二種以上的方法來解決.
> 我們可以先定義好一個Abstract Class 或interface,
> 然後用subclassing或implement interface的方法來提供Concrete Solutions,
> 這是Strategy的方式. 我們也可以先寫好某一種implementation,
> 新的方法用Adapter方式來Fit in.
> GoF雖然用不同的Diagrams來表示Adapter與Strategy,
> 可是老是覺得骨子裡它們很像.
GoF 在談到 Adapter 和 Bridge 的異同時就有提到：
Bridge 通常是在設計之初就已規畫切分好兩族各自演化的介面,
Adapter 則通常是等某一族成品出來了之後, 才來設法串接、轉換兩族介面。
Adapter 和 Strategy 亦可做如是觀。
GoF pp.22-23 就講到：
An object-oriented program's run-time structure often
bears little resemblance to its code structure.
code won't reveal everything about how a system will work.
The system's run-time structure must be imposed more by
the designer than the language.
同樣的道理, pattern 的「長相」未必代表它真正的行為；
應該要更深入看它的內涵。
對於 design patterns, 不要以參考答案的 class diagram 結構視之,
應著眼於 motivation（動機）、applicability（時機）及 consequence（效果）。
換句話說, 以任何 pattern 該點明的三大要素：
problem、context、solution 來看,
你應該更著眼於 problem 及 context。
發信人：柯仁傑
標題： 討論Strategy樣式
日期： 06/21/2001 : 10:24:48
發信站：Programmer 深度論壇
信區： OOA / OOD / OOP
※ 引述《BrianChang》於 06/19/2001 18:56:35 發表之銘言：
>
> 我最近得了 Design Pattern 憂鬱症，我的症狀如下…
>
> 1. Design Pattern 有看沒有懂。
> 2. 不知道如何利用 Design Pattern 在軟體設計中。
其實很多人在看Design Pattern時都把它想成是程式設計, 而沒想成它是
告訴你如何model問題. 所以當你沒養成利用model來解決問題時, 大概很
難利用程式設計當中 (我想你的軟體設計應該是傾向程式設計吧)
因此要能真的體會design pattern的精神, 個人認為是養成model的習慣,
這樣你才知道遇到什麼狀況你會model不下去,或是model的奇怪, 這時再
回去翻翻design pattern 你就會很快感受到他的原意是什麼
還有一點就是不要勉強使用design pattern, 因為你若無法確認問題是什麼
只覺得這個pattern不錯還有點適合就拿來用, 日後你會發現那將會是一場
夢靨.
記得要確切了解每個pattern的intent,Applicability, Structure, Collaborations,
Consequences, Implementation, 至於Sample Code不是那麼重要, 不過由於
初學的關係, 往往讀者是挑軟的看, 因此先看懂sample code, 前面在講些什麼
卻沒有認真看, 這樣反而失去design pattern的本意
柯仁傑
發信人：William Yeh
標題：Design Patterns
日期：05/10/2001 : 02:03:19
發信站：Programmer 深度論壇
信區：OOA / OOD / OOP
※ 引述《ycj》於 03/28/2001 18:38:25 發表之銘言：
>
> 最近在研讀 Design Patterns (GoF) 這本書, 23個 Patterns 才讀到一半, 就開始有點
> 混亂了, 老是把 Strategy, Decorator, Adapter, Factory..etc 攪在一起, 不知各位
> 先進有沒有什麼經驗分享一下.
這四個 pattern 差異很大呀, 是什麼地方「攪在一起」了呢?
其中, Strategy 和 Decorator 的異同, 書裡應該講得很清楚了。
每個人的背景及取向不同, 所以很難有個萬靈丹。
不過大方向或許都差不多：不必強求一次就全都弄懂。
除了我在此書的「導讀」部份所補充的建議閱讀順序之外,
再講一下我的經驗好了。
以我而言, 第三章前四個 creational patterns 最容易「攪在一起」,
其次則是 iterator 和 visitor。
回想起來, 我翻譯此書的大概順序是：序 → 附錄 A∼C → 第六章 →
第一章 → 第三章 → 第二章 → 第四章 → 第五章 → 索引。
現在覺得, 這麼難的第三章應該要晚一點再碰... :q
（君不見原著第三章的引言部份佔了四頁,
硬是比第四第五章輕描淡寫的兩頁來得多嗎？呵）
不過好處是：最難的已經先克服了, 其他的就沒什麼了。呵。
如果野心不大, 對於 creational patterns,
可只先學 factory method 及 singleton。