这是李维先生和左轻候、OopsWare等在大富翁上真诚而精彩的讨论：
左兄 :
看看C/C++的書有好處, 但是把C/C++的Object Model Implementation
套在Object Pascal之上卻不一定正確(請注意我使用C/C++<--->Object Pascal
而不是Delphi, 因為你討論到語言, 因此不適用Delphi來統稱).
C++和OP在語言設計上有一些觀念的不同, 再加上Compiler實作的技巧不同, 因此要強把
C++如何Implement Class/Object Model放在OP之上是不妥的. 在討論和理解Object Model時
如果能夠清楚的把Conceptual Model和Implementation Model分開, 那麼就可以很容易的
知道書中在說什麼. 否則只會愈來愈糊塗.
我想說明一下左兄列出的一些書以及我的看法
>Inside The C++ Object Model
請注意書名. 這本書是講C++如何Implement它的Object Model.
由於牽涉到了Implementation的方法, 因此是特別屬於C++的. Object Model雖是共識,
但是C++和OP各有不同的Implementation方式, 因此要把C++的觀念放在OP之上不一定正確.
也因此會造成一些OP使用者的困惑.
>Effective/More Effective C++
Meyer的書已經有一段時間了,這是2本好書, 但是有一些技巧太過低階和繁瑣.
如果有研究C/C++ Compiler的話, 現代的C/C++ Compiler的Optimization早已實作了
書中許多的技術, 程式師不必再花太多無謂的時間來寫複雜的程式碼.
>C++ Standard Template Library
瞭解Generic Programming的好書. 但是Template本身有許多的爭議,
因此這是OP一直沒有加入的原因.
>Design Patterns
一本必備的好書, 但是讀者必須知道如何活用, 沒有實際的開發經驗, 光看過是沒有用的.
一個好的學習方法是看VCL/.NET/Java framework來學習人家如何使用.
Design Pattern已和Language無關,共不專屬C++
>Refactoring
好書,好觀念, 可以讓系統架構更良好, 健全. 和Language無關,共不專屬C++
至於MFC則不必了, 除非使用VC. MFC本就是一個設計不好的Framework, 如果仔細看MFC
的Source, 它使用了大量的Macro以及不正確的C++語法. 這是因為當初Microsoft在實作
MFC時決定只使用最少的Wrapper來封裝Win API,
再加上當時Microsoft的C/C++ Compiler對於C++的支援非常的落後,
許多C++的語法無法Compile,因此才大量使用Macro和Proprietory的方式來克服.
現在Delphi少的是一本論述Object Model, 再映射到OP的書, 最好再能夠比較和C++/Java/C#的異同.
只要讀者能夠瞭解這本書的內容, 不論到C++或是Java/C#, 就只要掌握語法即可, 很容易的.
再往深一層, 如果能夠討論如何對映到Component Mode, 如COM+, .NET Component, EJB/CORBA,
討論語言層和元件層的技術, 那麼就太完美了, 即使是C++/Java現在也尚未有這種書的出現
只是不知這本書出來之後能夠賣得了幾本.
猛禽兄 :
>个人认为对于Design Patterns之类，看看即可，没必要深入理解，除非你要写一个类似于VCL的东东，
這我有意見, Dsign Patterns對於許多的應用都很有幫助, 包括了Framework和寫應用系統.
如果你有寫過EJB和真正的大型COM+系統, 那麼Design Patterns絕對有實質的幫助.
我想未來Delphi.NET的Framework也應該會採用許多的Design Patterns.
此外在Design Patterns中有一些非常適合使用在Framework, 但是有一些也非常適合使用在
應用程式之中. 例如Facade, Factory和Value Object等的Pattern. 只是我很少看到有Delphi
的程式師使用這些技巧. 不過在和我工作的工程師中我都會要求他們要看看Design Patterns一書,
即使一開始開不懂也無所謂, 因為有一些東西是刺激思想用的, 有了經驗之後就有可能會用.
至少可以增加Coding的功力.
===================================================================
OopsWare兄:
>没有必要去讨论什么谁可以virtual谁不能virtual，这也只不
>过是一个人为规定的语法格式，你为什么不去讨论C的i++和Delphi的Inc(i)那个效率更
>高或Delphi为什么没有i++
virtual等是語言的Spec.和設計的思想, i++和Inc(i)是Compiler實作的技巧, 基本上是不一樣的東西.
不過語言的Spec.和設計結構也會大大影響執行效率,
因此在學習語言時一定要先瞭解這個語言的設計觀念才能學好它, 語言的語法是次之的東西,
瞭解C++和Object Pascal的Object Model絕對比知道i++和Inc(i)那一個有效率更重要,
因為正確的使用Object Model省下的時間比i++/Inc(i)多了數千倍.
最後我可以告訴你C++的i++和Object Pascal的Inc(i)編譯的Assembly Code是一樣的,
目前C++和OP在Compiler效率差別的地方是在比較複雜的程式碼, 例如inline, loop unfolding等
不過由於Object Pascal的語法較嚴謹和Anders的天份, 因此Object Pascal可以產生Tight Code,
因此執行效率也很好.
>写书的人没几个不是为了钱的。随便那一本C++的书看看，知道他的语法不就够了，
>再有钱有时间也不至于拿这么多“垃圾”来消磨生命
我不能同意這句話, 如果你稱這些名/好書是“垃圾”,
那麼我只能說你可能沒有真正的瞭解這些書的含意, 寫書的人如果把寶貴的知識和人分享
那麼當然應該獲得合理的報酬, 你願意幫你老板/公司免費工作和Coding嗎?
to gliGordon:
首先欢迎您加入DFW。并虚心接受你的指教。
我们考虑这个问题的出发点不同，你的讨论出自技术，我更多的参照了现实的表面现象。
贴上面的帖子时我已经想到了会被人骂，贴出来既收到了论坛中富翁的指责。
>因此在學習語言時一定要先瞭解這個語言的設計觀念才能學好它, 語言的語法是次之的東西,
讲现实些，您学习C语言时先学的语法还是“語言的設計觀念”(我也清楚他的重要性)。
在你没有掌握任何一种语言之前何谈“語言的設計觀念”，还不是学会一种语言后再学
另一种语言而自己得出的一些理解。书是好东西，但应有个读法，不知对“尽信书->乱读书
->怀疑书->理解书->不看书”这样的理解有何评价。
>瞭解C++和Object Pascal的Object Model絕對比知道i++和Inc(i)那一個有效率更重要
i++和Inc(i) 可以考虑为我贴出的一个不恰当的例子。
>我不能同意這句話, 如果你稱這些名/好書是“垃圾”,
我为自己贴出上面的话深表歉意！ 仅对目前的计算机图书市场不满。
Hi OopsWare :
討論技術而已, 說不上指教, 只有互相切磋, 增長見聞.
>讲现实些，您学习C语言时先学的语法还是“語言的設計觀念”(我也清楚他的重要性)。
>在你没有掌握任何一种语言之前何谈“語言的設計觀念”，还不是学会一种语言后再学
>另一种语言而自己得出的一些理解。
不, 如果你還記得Programming Language這一門課你就會知道瞭解語言設計哲學的重要.
你提到C語言. 坦白的說那是我的第1階段, 在那個時候我學語言的方式就和你說的一樣,
是從語法開始, 所以有一段時間也是矇矇懂懂, 專學一些奇怪的語法, 和人比對語法的熟悉度.
但是受了Programming Language的教導之後就不是如此了. 開始學會了欣賞和剖析語言
到了這個階段套句武俠小說的說法"才感覺突飛猛進, 內功日漸精純", 哈哈.
不過在工作的生涯中看了大部分的人把P.L.寶貴的知識忘得一乾二淨, 真是可惜.
舉個例如, Bruce Eckel的Thinking系列為什麼是好書, 就是因為他的書名注重"Thinking"
是教你瞭解這個語言的觀念和設計, 不是著重在說明所有C++/Java的語法.
我個人覺得在看Thinking系列時作者是比較從P.L.的觀點闡述的.
>书是好东西，但应有个读法，不知对“尽信书->乱读书
>->怀疑书->理解书->不看书”这样的理解有何评价。
不, ,至少你可以從篩選書籍開始做起. 有一點東西不看書我覺得是不學瞭解的,
例如Spec類, 不看規範和書如何得知? 另外一種書比較偏向實作經驗類,
那麼就可以謙選擇是否要看, 因為經驗是隨人/系統而異, 也許你的經驗已經比作者還豐富了.
不過我個人覺得只要經過篩選步驟, 那麼開卷終是有益的.
例如我看一些書時覺得作者的想法不好或是不正確, 不過我也會想
"嘿, 他(指作者)為什麼會有這樣的想法? 這可真有趣",
我會試著找到正確或是更好的方式, 這就是收獲, 如果沒有看到可能永遠不會觸發後續的動作.
>总体来说，能被人指责一番是件好事。至少不会被“大侠”的头衔冲浑头脑。我亦平凡。
嗯, 我也是Coding人, 有的知道, 有的不知道, 所以才會需要會大家討論, 彼此進步.
你說的"我亦平凡"真是好話, 我想這是適用於大部分的人, 包括我在內.
to gliGordon:
>如果你還記得Programming Language這一門課你就會知道瞭解語言設計哲學的重要.
把“語言設計”和“哲學”放在一起，也就摆明这是一个争论不出结果的问题。
我学习OO更多的来源于Online Help、Example，和长期的经验积累。而决非一本书。
好多学计算机的人都在寻找你讲的这种“武林秘笈”，信不信你若报上书名，就马上
有人去买....读书是一种途径，而理解是多方面的，写书的人谈他的思路，要看读书
的人怎样理解，我相信这其中有好多天赋和勤奋的因素。有些人具有这样的直觉，
很快能够了解作者的用意，而有人就只能看看热闹。这种“直觉”应该就是你提到
的“Thinking”，但说到如何养成，抱着速成的心态读多少书也徒劳。
软件发展的速度太快，C++不过是其中的一段时期，难讲会被什么取代。停在原地
追根问底的啃某个细节，似乎是学生时代做的事，再者便是专门研究。
Hi OopsWare :
>把“語言設計”和“哲學”放在一起，也就摆明这是一个争论不出结果的问题。
每一種語言的設計者在設計一個語言時都有他們想法和目標, 這些就是語言背後的思想和哲學
所以有人設計了Procedual Language, 有人設計了Stack Language, 有人發明了Functional Language等等
我們沒有討論那一種語言較好, 而是討論瞭解了語言的思想和特色之後, 我認為會學得快一點, 更好一點.
>我学习OO更多的来源于Online Help、Example，和长期的经验积累。而决非一本书。
這也是一種學習的方式, 很好, 可是也不可否認一些甚至是一本好書對人們的重要性,
>我相信这其中有好多天赋和勤奋的因素。有些人具有这样的直觉，
>很快能够了解作者的用意，而有人就只能看看热闹。这种“直觉”应该就是你提到
>的“Thinking”，但说到如何养成，抱着速成的心态读多少书也徒劳。
沒錯, 同一本書, 不同的人看會有不同的感覺.
> 软件发展的速度太快，C++不过是其中的一段时期，难讲会被什么取代。停在原地
>追根问底的啃某个细节，似乎是学生时代做的事，再者便是专门研究。
如果你要寫一個大型系統, 或是一個Framework, 那麼你必須對使用的工具/語言瞭若指掌,
否則一定問題百出. 對於關鍵系統的觀念更應該徹底瞭解, 软件发展的速度雖快,
但是脫不出一些重要觀念的變化. 真正瞭解C++/Object Pascal的語言思想和Object Model之後,
並沒有浪費你的投資, 因為你可以更快的掌握到其他技術和語言
gliGordon兄：
你是来自港台那边的吧？
大富翁也经常看到繁体字，但印象中还没有见过这等见识的高手出现
你的贴子让我很吃惊，并不仅仅是因为贴子的内容
我和一些朋友正在讨论这个问题，你简直就象看到了我们的讨论一样
连最后那句
“只是不知這本書出來之後能夠賣得了幾本”
也一模一样
能否留下你的Email或其它的联系方式？
或者给我来信也可以：qinghou@163.com
有一个朋友圈子欢迎你加入
左兄 :
>你是来自港台那边的吧？
>大富翁也经常看到繁体字，但印象中还没有见过这等见识的高手出现
是的, 我在台灣, 看來下次我得先用Word把繁體轉為簡體再發言.
來這兒逛逛已有一年多了, 一直沒有浮出水面, 這次看到左兄的信一時手癢寫了一些東西,
佔了版面, 真是不好意思.
>你的贴子让我很吃惊，并不仅仅是因为贴子的内容
>我和一些朋友正在讨论这个问题，你简直就象看到了我们的讨论一样
>连最后那句
>“只是不知這本書出來之後能夠賣得了幾本”
>也一模一样
哈哈, 說不定我本就是你的朋友之一啊.
>能否留下你的Email或其它的联系方式？
>或者给我来信也可以：qinghou@163.com
>有一个朋友圈子欢迎你加入
有這樣的圈子真好, 大家互相討論功力會日益精進的.
