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

To 速查手册:
"但是你说“china-pub 上的评论”，可别太当真喔。虽然那是出版商进行商业炒作和相互诋毁的大本营，但也不乏来自正直读者的客观评论。"
是想说，是是非非需要你自己判断，总不能买错了东西就骂人就打人。
china-pub 上有个人说（记不清原话了），他买我第一本书就上当，买第 二本书还上当，买第 三本书接着上当。为什么不总结经验？为什么总是上当？明知上当，为什么还要买我的书？
在这里我不想为自己的书争辩，但我希望读者能有自己的判断，相信自己的判断。这要有点头脑，有些是是非非并不难辨清。
鉴于这里和china-pub不同，都是搞技术人的，所以我多说几句。不当之处，请指正。

有沒有電子版的書能不能發一個給我﹐email : simonlai@dbd.com.cn﹐謝謝﹗

刘艺的书写得不错，不过我希望刘艺来这里可不要只为了给新书发广告啊，多多解答问题，提点新手。写书应该是水到渠成的事情，比如我认为李维写书就是在Delphi的论坛上被Delphi爱好者逼出来的。
大富翁可能有些人看不起各种面向初/中级读者的书籍，但实际上，除了技术能力之外，表达能力同样重要。况且，任何技术书籍的水平都达不到作者的真实水平，从一本书就推断作者的水平是不适合的。

感谢Traveller的支持，更感谢提出尖锐批评的读者。
我也觉得很多事情都是“逼出来的”，也希望自己的书能被逼得更好。
第一次将新书的信息发布在这里，就是为了让读者评判，了解大家的意见。
比如：张无忌和barton的意见就对我写下一本书很有启发。
写书不是为了show自己的水平，而是为了获得一种肯定，就是barton说的“一个作者如果能够得到这样的肯定，应该是他一生的荣耀。这种荣耀远比通过写书获得的名利珍贵。”
再次感谢所有关注这条帖子的朋友。

to:newdream
能否谈谈数据库的面向对象？
能否贴些相关的源代码例子？

To newdream:
>>数据库面向对象编程的关键时如何将数据集（表、查询等）变成程序中的对象。
>>这个过程类似：数据库表、查询－>数据存取对象－>业务对象－>界面对象
>>这样就把对数据记录的直接访问变成了对业务对象的数据成员的访问。
>>有2种途径：
>>下策：直接将数据表转化为对象，每个字段对应一个对象属性，数据集变成对象集。缺点：工作量大，无法在界面中使用数据感知控件。
>>上策：将数据表转化为数据集对象（TClientDataSet），通过数据集对象来实现RAD，建立业务对象和数据集对象的协作关系。只将少量业务逻辑复杂的运算，再由数据集对象转化为业务对象处理。优点：可以充分利用VCL组件，包括在界面中使用数据感知控件。
>>在本书中有这方面的讨论和示例程序。

不敢苟同.我认为恰恰相反.
要知道,面向对象里面,还有一个反射机制(reflect),以及动态创建机制.繁琐的属性设置可以交给程序来做.关键是如何用好这个机制.
创建数据集对象的做法其实不是很面向对象的.而且难以维护.
个人认为,程序中使用数据感知控件是没有必要的.

重在学习，重在交流。
期待ing

我买过《delphi6 企业级解决方案及应用剖析》,感觉不错，是我觉得书中确实有自己东西的好书之一。市面上很多书都是东拼西凑，作者能写出自己的东西并且有点深度的书确实不错。
支持，等书面市后去书店卖一本。
不过你的论坛上(刘艺和他的电子小组是什么的，书上说的那个)我上去过，但没见你上去回答过，所以就再也没去。不知什么原因。

大家不必为某本书争执不休，没有意义。人家能够把一本书写出来，你写不出来，就说明人
家水平比你高。不必在这么高雅的地方使泼。

有关面向对象这个课题，我可以说有着深刻的体会。关于面向对象的风险和缺陷，我上个贴
子没有交代清楚。蔡学镛的《Java夜未眠》中是这样写的，我愿意在这里贴出来给大家参考，
我认为在这方面刘艺的书中应该给读者一个交代。oop虽好，但不可滥用。
第一就是太多类别。每个类的重用率极低，造成内存浪费太多。必须适当地利用继承来写，
或把功能类似的数个类别浓缩成一个类别。(类本身占内存，类实例又占内存)
第二就是太多继承。继承固然可以提高重用率，但是也会使得对象体积变大许多，执行效率
也会变差。继承被误用的情况一直很严重。更糟的是，继承是一种静态的关联，使得程序的
弹性变差。
第三就是太多对象。太多对象也会造成内存浪费，很多对象是可以彼此共享的。
第四就是太多短命对象，这会造成构造和析构花的时间太多。对于系统效率有很不好的影响。
更多的时候可以使用Object Pool等方式来写。(Delphi中有很多这样的范例)
第五是太多可视组件。太多对象已经很不好了，如果这些对象是可视组件更是雪上加霜。可
视组件会耗费CPU大量的运算时间。

看了大家写了这么多，有褒有贬，无非在说明这本书好；或者说这本书有些地方没有讲清楚，有些勘误。其实我看过刘先生的《delphi6 企业级解决方案及应用剖析》，的确有他本人的功底，至少我写不出来，也说不清这么多的道理。
其实呢我想说的是“三人行，必有我师”。虽然我没有拜读刘先生的新作，但是我相信肯定有我们值得深思和鉴戒的地方，所以对本书我也是抱着一定的期望的。但是，我想大家也有议论的权利，就连很多世界名著也有不同的意见，更何况我们不是那些学文科出生的人呢？当然我相信刘先生也会非常欢迎我们与他进行交流，毕竟有沟通才会有进步，有交流才能有发展，在坐的肯定没有一个是故步自封和闭门造车的吧！
我看了本书的目录，可以想象出前几章是一些OO概念性的东西，但是后几章可能就是刘先生对与Delphi进行OO编程的经验之谈了，我想对我们这些低手应该是很有帮助的了。
所以我决定，只要我在书店看到了本书，我就买，只是希望不要太贵了，呵呵

to barton:
“大家不必为某本书争执不休，没有意义。人家能够把一本书写出来，你写不出来，就说明人家水平比你高。不必在这么高雅的地方使泼。”
----无话可说
“有关面向对象这个课题...”
----很有价值，但是恐怕刘艺解决不了。 当然，不排除他可能会提上几句[]

To newdream:
>>数据库面向对象编程的关键时如何将数据集（表、查询等）变成程序中的对象。
>>这个过程类似：数据库表、查询－>数据存取对象－>业务对象－>界面对象
>>这样就把对数据记录的直接访问变成了对业务对象的数据成员的访问。
>>有2种途径：
>>下策：直接将数据表转化为对象，每个字段对应一个对象属性，数据集变成对象集。缺点：工作量大，无法在界面中使用数据感知控件。
>>上策：将数据表转化为数据集对象（TClientDataSet），通过数据集对象来实现RAD，建立业务对象和数据集对象的协作关系。只将少量业务逻辑复杂的运算，再由数据集对象转化为业务对象处理。优点：可以充分利用VCL组件，包括在界面中使用数据感知控件。
>>在本书中有这方面的讨论和示例程序。

我对你所提的这个上策非常感兴趣，实际上我一直也在尝试这样来做，但是对能用于多大规模和复杂度的工程现在心里没底，不知道有没有用这种方式取得成功的中等及以上规模的工程实例。另外，实际中我感觉需要在数据敏感控件的体系内进行一定的扩充，比如派生业务字段类型，派生与其对应的感知控件，派生自定义的Action，否则实施起来总会感觉有些别扭，而且存在代码冗余。
另外，关于这种方案不知道会有哪些缺点。

http://www.delphibbs.com/delphibbs/dispq.asp?lid=1752693
这是我对数据感知控件的分析，我认为数据感知控件实际上正是观察者模式在Delphi中的应用。它在应用的缺点主要是传统的数据集造成的，而ClientDataSet才是与他相配的理想数据集。

To barton:
“oop虽好，但不可滥用。”，我很赞成这种提法。
下面是我的一些解决方法,书中有交代的地方用*标出。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
第一就是太多类别。每个类的重用率极低，造成内存浪费太多。必须适当地利用继承
来写，或把功能类似的数个类别浓缩成一个类别。(类本身占内存，类实例又占内存)
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
解决方法：
1.动态完成对象或组件的创建和释放，把握好时机。*
2.使用创建型设计模式。比如：利用抽象工厂(abstract factory)模式将类的创建延迟到子类；利用建造(builder)模式把对象的创建动态委派给另一个对象。


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
第二就是太多继承。继承固然可以提高重用率，但是也会使得对象体积变大许多，执行效率也会变差。继承被误用的情况一直很严重。更糟的是，继承是一种静态的关联，使得程序的弹性变差。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
解决方法：
1.少使用继承，一般将继承控制在3代以内。*
2.考虑使用合成代替继承，类的合成关系又分成聚合（Aggregation）关系和组合（Composition）关系两种。*
3.如果使用继承，对于基类用接口或抽象类代替具体类，变静态的关联为动态关联。*


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
第三就是太多对象。太多对象也会造成内存浪费，很多对象是可以彼此共享的。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
解决方法：
太多对象是因为不考虑对象的生命期，在程序加载时就将所有的对象创建了，实际上有些对象生命期很短，有些对象不常用到或根本用不到，有些对象重复创建。
解决方法是，
1.只在需要时创建对象（Just－In—Time）。*
2.了解和管理好对象的生命期。依赖（Dependency）关系和合作（Association）关系是着眼于对象间互相作用的一种关系，在设计时可以将对象划分依赖关系和合作关系分别管理。*
3.对于共享对象，使用单例（singleton）模式创建。


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
第四就是太多短命对象，这会造成构造和析构花的时间太多。对于系统效率有很不好的影响。更多的时候可以使用Object Pool等方式来写。(Delphi中有很多这样的范例)
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
解决方法：
1.划分持续性对象和临时对象，分别管理对象生命期。*
2.划分对象间的依赖关系和合作关系，分别管理对象生命期。*
3.构建对象管理类，通过注册来管理常用对象。
4.使用对象集（对象容器）。*


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
第五是太多可视组件。太多对象已经很不好了，如果这些对象是可视组件更是雪上加霜。可视组件会耗费CPU大量的运算时间。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
解决方法：
1.通过写代码动态创建VCL组件，而不是直接拖放。*
2.动态管理VCL组件生命期。*比如：
TempTable := TClientDataSet.Create(nil);
try
with TempTable do
begin
LoadFromFile('StateData');
open;

...
Edit;
FieldByName('Done').AsBoolean := True;
Post;
SaveToFile('StateData');
end;
finally
TempTable.Free;
end;
而不是：
TempTable := TClientDataSet.Create(form1);
这样会将VCL组件生命期交给属主对象管理（如：form1）。属主对象管理VCL组件机制是导致组件耗费CPU大量的运算时间的根源之一。*（书中“组件对象生命期管理的误区”一节有详细介绍）


(注：*：表示《Delphi面向对象编程思想》中有这方面的内容。)

To Traveller:
"它在应用的缺点主要是传统的数据集造成的，而ClientDataSet才是与他相配的理想数据集。"--你说到点子上了。我最喜欢用的就是ClientDataSet。不过ADO.net中的DataSet更好，为什么Borland的好东西总是被微软拿去发扬光大？ADO.net中的DataSet中明显有ClientDataSet的痕迹。如果Delphi.net上市，我就改用ADO.net的DataSet了。
准确地讲，元数据和对象之间的Map要比单纯的数据集和对象之间的Map要更高一筹。这是上策。
最后强调一点，数据敏感控件的使用只限于客户端的GUI。

很好，我相信这本书会受到大家欢迎，特别对希望尽快接受oop思想的程序员们。

建议作者效仿think in...系列的作者,公布电子版,供大家学习评论,然后根据大家的意见修改书稿,再出书.我觉得这样不但不会影响销量,相反,会促进销量,促进作者知名度.

我不清楚其他工程中客户端的GUI控制花费了多少开销，但是在我最近从事的工作中，GUI的控制代码至少花费了开发时间的70%以上，而且贡献了大量的BUG，这些在我看来主要是不使用数据感知控件的结果（受限于BDE连接数，所以一直没有使用），这显然是不正常的。
我也看了ADO.NET的Dataset，设计确实和ClientDataSet如出一辙，而且比ClientDataSet做的还要好。微软最高明的地方大概就是了解每一项技术的价值并且舍得投入吧。
而O-R Mapping在Delphi中其实可以通过写一个Class builder工具来根据数据库结构生成相应的访问代码。不过现在在Delphi领域还没有看到比较通用的O-R Mapping技术，不知道其他富翁有没有这方面的了解。

我觉得公布电子版主要还看出版社啦，从个人来讲，出了电子版，哪怕就是和纸版一样的电子书我也会买一份纸版的。真正的好书是值得随身携带和翻阅的，电子版没有这种优势。

大家要明辨事非啊！不好明说，看书就明白了！

d5 d6企业级的失望...