《Delphi面向对象编程思想》 (0分)

my book<Delphi FAQ>
author leighsword
preface
click http://www.delphibbs.com/
finish

一看目录就不错，希望有机会拜度大作了。

看目录的确还不错，就怕象很多书一样，目录写的很棒，可是一看内容全都是。。

希望这是一本表里如一的书，那一定第一时间拜读

希望这本书可以写得很经典.

什么时候出不要紧,关键是要好.

是好书什么时候都有人买.

同意

我谈点看法，如有冒处之处，请刘艺先生海涵。
先肯定两点：
1.该书定位不错，面向中级程序员。因为高手不怎么看中文版，只对E文的原版书感兴趣(蔡
学镛语)。所以如果写中文版的书并面向高手一定不会有市场。不过我个人认为这本书更准
确地说应该是面向初级程序员。我对自己的定位是中级程序员，因为我不怎么看原版书(好难
懂，E文又特烂)，最多看看MSDN或Online-Help之类。面向对象这个概念，对于一个Delphi程
序员来说是必须掌握的基本技能，是中级Delphi程序员的必备要素之一。我对面向对象的理
解在Borland Pascal的时代就有着深刻的体会。在Delphi时代，面向对象又有了新的意义，
不论从语法上还是思维方法上都大有出入。
2.面向对象这个命题不错。大多数初级Delphi程序员缺的就是这一个。很多人用了一两年
Delphi都没有真正地理解面向对象的实质。你这本书刚好针对他。如果他真的读懂了你的书，
他会对你终生感激不尽。一个作者如果能够得到这样的肯定，应该是他一生的荣耀。这种荣
耀远比通过写书获得的名利珍贵。

但是，我还是要提几点意见。
1.说实话，读书学习是很痛苦的一件事，既费钱又费时间。所以我对“面向对象”这个命题
是否需要写洋洋洒洒500多页持怀疑态度。如果是一本手册式的书，再厚也无所谓，因为读者
不会一页一页地去读它，只在需要的时候查询某些章节。如何让读者既省钱又省时地学到知
识应该是一个作者不能忽略的问题。靠花费读者时间来宣扬自己思想的人从某种意义上讲是
很不道德的。我最欣赏某些图书中一段一段的点睛之笔，一两句话就能够让你幡然醒悟，真
如醍醐灌顶一般。
看过你的前言，说实话我对这种担心进一步加剧。不客气地说，有卖弄之嫌。传统文化与技
术不能说完全没有关系，但在此处纯属强拉在一起，对读者的理解毫无好处。正如楼上有位
大虾说的，本来还明白一两点，现在反而更糊涂了。我不知道你是希望读者先读懂《鬼谷子》
然后才来读你的书，还是让读者明白面向对象思想源自中国传统文化。毕竟技术著作和学术
著作是面向不同读者的。
全书的结构不能说有什么大的问题，但章节的内容部署不够合理。很多章节可以省略或者简
略，而另一些章节需要更细致地分析和阐述。
2.面向对象是有弊端的。最近读了蔡学镛的《Java夜未眠》，书中有一篇叫OOOO，这个词是
作者自己发明的，全拼是Obsessive-Object-Orientation Obliquity，解释是过度面向对象
偏颇症。我没有看过你的这本书，只能从目录上分析。我认为既然是集面向对象思想之大成
不能回避面向对象缺陷这样的问题，应该将面向对象的缺陷、风险、来龙去脉以及如何避免
向读者交代清楚。VCL体系并不是一点问题都没有，特别是Data Aware体系也存在很大的缺
陷，这些缺陷在写服务器程序的时候尤其明显。我不知道你的书是否已经交代得很清楚，我
的印象在你的思想中对Data Aware是持100%肯定态度的。你楼上有一个贴子将ClientDataSet
封装业务对象列为上策以便更好地利用Data Aware就是一个例证。我认为用ClientDataset封
装业务对象充其量只能算个中策。李维新书《Borland传奇》P113页有很详细的描述。
3.VMT是面向对象的根源。对于一本深入探究面向对象的书不应该回避这个命题。充分地利用
好VMT是一种很专业的技巧。从根本上理解OOP，不能不理解VMT。
4.实用性原则。在开发项目中出现最多的问题就是客户不断变化的需求，如何在接受OOP思想
后用OOP的方法适应这种现实更快地解决这样的实际问题。仅仅只提供一种思路而没有具体方
法可能会令读者失望。我认为本书应该引用一两个实例来阐述通过OOP灵活地应对项目中的需
求变化。

有电子版下载,告诉我一下

OOP，风险和缺陷又在哪里呢？barton所说的需求变化，答案应在软工模式中去寻找，oop仅是思考的方法和软工模式的前提。在C++或java程序员而言，oop应该不是一个真正有难度的问题，因为开发的方式强制我们，必须这样思考，必须更熟练更自然的以这种方式思考。
Delphi里面，OOP相形而言更复杂一些，正因为Rad的开发方式，是兼顾的困难。界面与业务逻辑的分离、业务逻辑和数据库的分离，前者应该容易解决，后者在Delphi里是个几乎无解的问题，诸如bold，小如instantobject、objectsight、depo等等，均是这些方面努力的结果，刘亿先生认为下策的东西。很长时间探索之后，感觉若使用Delphi的话，对象持久性框架，对象与关系数据库的映射，显得有些学究气。值得提到的是instantobject，在实现对象持久化框架之余，又令数据敏感控件能继续应用，可惜是小公司产品，不敢贸然的应用。
另外，关系数据库--对象映射，几乎不可避免的带来程序运行效率的问题。在无法舍弃Rad特性比如数据敏感控件之类的情形下，承认Vcl数据集封装的事实在这种学究气的OOP中，需要勇气。这或许是刘亿先生务实的地方。
不过，从我们公司的实践来看，对复杂系统，Rad是否真的能带来开发速度上的优势，委实不敢深信。早期蜘蛛网似的数据库、不断变化的需求，程序员在不同的按钮背后寻找事件代码，探寻一些变化将历经多次的整体漫游，这就是Rad。所以何不大胆的进一步设想，将
这些短期利益的Rad特性弃如敝履？
Delphi在目前真正的优势，我以为是在作为高效率的跨平台的原生代码开发工具，在.net平台推出之后，这一点更加明显，所谓rad，或者将来会有不同一些的理解。而那些与企业级开发背道而驰，伴随着系统的复杂性在自身更动的灵活、维护的困难方面愈发举步维艰的现实，更令我坚信Rad仅是业余爱好者或者被工期逼迫到走突无路的小项目的选择。
刘亿先生这本书，从选题而言，确实是国内第一本Delphi+oop的实务性专著，期待公司的小伙子们能很快看到
barton事实上在“界面、数据库、业务逻辑”三者中曾经花费很大精力，他的一些贴子看起来也深有启发，但这些零星的东西，是需要缘分才能有所感悟的，任何书籍或者都是一家之言，文法风格若有些不同，鬼谷子之类，呵呵，在我看来只是表达的变化，若于文字及
哲理全无修炼，恐怕也很难成为编程的大家。事实上，barton可以看出牵强，前提必是明白
了牵强的去处，又何必低估其他同仁的阅读能力？
很讨厌那种死气沉沉的催眠曲一般的行文风格。
另外：“参透Delphi”一书，阅读的兴趣似乎不足，可能仅于表达有关。

看这类书，我个人的看法是看有没有时间。我看了几篇刘先生在论坛披露的书中部分内容，
感觉有点尴尬，行文和定位绝对错位。但如果有时间，我提倡不论什么书都看，最后总能从
每一本书中得到点点滴滴，即便得不到有益的也可以得到和自己不相容的，只要基本概念不
要是错误的就行。反过来，如果没有时间，那，该干吗还干吗吧。

书何时正式出版,请发贴

第9章 深入浅出VCL（上） 432
9.1 Delphi对象的基础:VCL 432
9.1.1 VCL的层次结构 432
9.1.2 组件的继承关系 434
9.2 TObject：所有对象的根 435
9.3 TPersistent：持久对象 440
9.4 TComponent：组件对象 444
9.4.1 概述 444
9.4.2 属性 447
9.4.3 方法 451
9.4.4 组件的从属关系 453
9.5 TApplication：应用程序对象 455
9.5.1 概述 455
9.5.2 属性 456
9.5.3 方法 460
9.5.4 事件 461
------------------------------------------------------------
第10章 深入浅出VCL（下） 464
10.1 TThread：线程对象 464
10.1.1 概述 464
10.1.2 线程对象的封装和运行机制 464
10.1.3 使用线程对象 471
10.2 TStrings、TList、TCollection：列表与集合 481
10.2.1 TStrings与TStringList 481
10.2.2 TList 486
10.2.3 TCollection 487
10.3 TStream：流对象与流化存储技术 493
10.3.1 TStream类及其派生类。 493
10.3.2 TFileStream与TMemString 496
10.3.3 TCompressionStream和TDecompressionStream 497
10.4 VCL的可视化工作机制 501
10.4.1 TFiler类、TReader类和TWriter类 501
10.4.2 TStream和组件属性的存取 503
10.4.3 Object Inspector的工作原理 508


我是新手，目前对这两章的内容很感兴趣

刘艺的书很好！序言写的尤其好，一般很厚，水分很足...
我买了它的《企业级...》，简直是谋财害命（浪费钱、浪费时间）！
大家看看china-pub 上的评论就知道了。
另外，我发现它的打手不少[!]

to comAcom:
你说我的书“水分很足”“谋财害命”，我没有意见。读者有批评作者的权力，何况对一本书的看法本来就是“仁者见仁，智者见智”的事。我平时上街买东西还经常后悔买错呢。
但是你说“china-pub 上的评论”，可别太当真喔。虽然那是出版商进行商业炒作和相互诋毁的大本营，但也不乏来自正直读者的客观评论。比如：xiaocuo_zrf就是其中很有主见的一位。
所以，我想最重要的是自己的判断。

请各位大师把一些好书列举一下
让我们也好去买什么样的书。

to 刘艺先生:
我没有看到乔林的<参透delphi>一书,但从目录上来看,好象前几章的内容几乎一样
你能谈谈你的这本书和<参透delphi>的异同之处吗

To barton：
非常感谢你花那么多时间来关注这本新书，并洋洋洒洒写了那么多宝贵的意见和建议。
首先你的判断是正确的。这不是一本写给高手的书。准确的讲，这本书也不是写给已经掌握OOP的Delphi程序员的。他们即使要在OOP方面有所提高，也无需看这么厚的书，因为可能很多内容已经了解。
不过你的情况正代表了这样一种需求：有一定OOP基础，希望对OOP底层动态机制（如：VMT）有深入了解，并偏重于OOD和解决实际问题。这部分知识涉及到面向对象的其他方面，如：设计模式、系统架构、软件重用、面向对象的数据库等。我想，在我的后继作品中会有这方面的内容。
的确，读者层的细化和作者的写作兴趣本身难免会有分歧，所以一方面一本书的读者面不能强求，另一方面还需要有更多像你这样热心的读者给与支持，多提宝贵意见和建议。
关于“Data Aware体系”的讨论，你说：“特别是Data Aware体系也存在很大的缺
陷，这些缺陷在写服务器程序的时候尤其明显。我不知道你的书是否已经交代得很清楚，我
的印象在你的思想中对Data Aware是持100%肯定态度的。”。我认为这要从几个角度去看。
如果你是一个小项目，用面向对象的方法设计，并不排斥Data Aware。因为无论是数据集对象还是数据呈现对象（Data Aware），都是对象，为什么不能OOP呢？他们可以很好地与业务对象协作，提高生产率。这就是Delphi不是C++，也不是VB的原因！
当然，如果是大型系统，是产品线，为了更高级别上的抽象、重用和效率，花时间实现自己的数据库到对象的Map框架很有必要。实际上写服务器程序不会考虑太多的GUI，也是可以避免Data Aware的。
在这本书中没有讨论数据库到对象的Map框架，并不是代表“对Data Aware是持100%肯定态度”。因为这毕竟是一本写给不太了解OOP的Delphi程序员的中级读物。目的是让他们在RAD的自我陶醉中也知道OOP的重要。
有时间我们另外讨论数据库面向对象的问题好吗，可以看出来你在这方面有很多经验。

To wjh_wy:
千万不要迷信“大师”的话。知道“小马过河”的寓言吗，自己去书店找，找你有兴趣读的书。千万不要买自己根本就读不进去的经典，书是用来读的，不是用来show的。

刘大师：能不能发份给我。我很想学习学习，谢谢！
我的E-mail: hegaoge@163.com

"但是你说“china-pub 上的评论”，可别太当真喔。虽然那是出版商进行商业炒作和相互诋毁的大本营，但也不乏来自正直读者的客观评论。"
---到底想说什么？

重在学习，重在交流。
期待什么时候可以下载呀！
或者.......