James Rumbaugh写的《面向对象的建模与设计》一书中，提到过三种建模格式：对象建模、动态建模、功能建模。对象模型确定了发生的客体，动态模型确定什么时候发生，功能模型则指明发生了什么。
在动态建模中，一个很重要的概念就是事件与状态。
状态是对象属性值和链的一种抽象。状态指明了对象对输入事件的相应。它不仅是描述事物动态特征的变量。更确切的说，状态有持续性，常常与连续的活动有关。用你书里的例子也能说明这个问题：
“车门关闭”不是一个动态动作，而是一个持续特征。我们日常生活中也会说“车门保持关闭的状态”。事件则不同，它表示的是时刻，是一个刹那的动作。
事件和状态是孪生的。一个事件分开两种状态：车门开着――>>“关车门”――>>车门关着
而一个状态也分开两个事件：摘电话听筒――>>“待机”――>>拨号（或者挂机）
重要的是，状态是和某种情况下对象的值有关的。所以，我们在BCB中，可以用property定义属性。
抛砖啦！
150 个解决方案
#1
捧场
#2
不错,不错
#3
捧场
#4
蹭分 :D
#5
学习
#6
听说Lewolf去chinabcb做斑竹！
我打个马夹占个位子！
呵呵
我打个马夹占个位子！
呵呵
#7
是不是听我说的?
#8
捧场
#9
怎么没有其他高手发表一下自己的心得了，给我们这些后进学习学习：）
#10
作品在哪里？
-----------------------------------
什么时候有时间、有朋友一起去踢球呢？
-----------------------------------
什么时候有时间、有朋友一起去踢球呢？
#11
虚心学习哦
#12
学习+捧场
#13
lewolf的大作我也看了，对于他书中的提法没有意见，并且认为作合很有创新，不过对作者最后的例子程序倒是有一点想法：
lewolf最后的那个矢量绘图软件，我认为设计方法上有一点问题，对于矢量图形我认为应该自己重新设计自己的类，而不应该从TShape继承，我认为这有点投机的意思。
lewolf最后的那个矢量绘图软件，我认为设计方法上有一点问题，对于矢量图形我认为应该自己重新设计自己的类，而不应该从TShape继承，我认为这有点投机的意思。
#14
蹭分
#15
我接砖头:)
#16
学习～～
#17
学习中，接分快乐！
#18
to TR@SOE () ：
你的书什么时候出来？
你的书什么时候出来？
#19
学习，看看
#20
学习.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
期待着lewolf的出现..呵呵.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
期待着lewolf的出现..呵呵.
#21
学习
#22
To Aweay:
我觉得书中的这个例子不是为了矢量图形而做。而是为了这种面向状态编程
况且这样的矢量图形根本起不到矢量作用.作者也就用了一两天的时间做它而已。
我觉得书中的这个例子不是为了矢量图形而做。而是为了这种面向状态编程
况且这样的矢量图形根本起不到矢量作用.作者也就用了一两天的时间做它而已。
#23
打错字了。他好像是说一两个小时做这例子而已。
#24
例子本身只能用来辅佐说明思想。
#25
版主说的对。
这例子.甚至本书不是为了编写矢量软件而写的。
版主您的性欲怎么也这么低啊？
这例子.甚至本书不是为了编写矢量软件而写的。
版主您的性欲怎么也这么低啊？
#26
TR的信誉是该涨涨了，要不总有人问
@_@
@_@
#27
前几天LeWolf帮我解决了一个问题,我想谢谢他
#28
^_^,中心人物怎么没有来?>
to meCAD TR@SOE 是为了特别所以才....
明天给他涨涨,...
to meCAD TR@SOE 是为了特别所以才....
明天给他涨涨,...
#29
呵呵,我也来接分,同时想请高手顺便到下面看看,帮帮忙解决这个问题
http://expert.csdn.net/Expert/topic/1885/1885390.xml?temp=.2522547
因为这里好象高手比较多
http://expert.csdn.net/Expert/topic/1885/1885390.xml?temp=.2522547
因为这里好象高手比较多
#30
不好意思
抢劫了。
抢劫了。
#31
怎么还没来？？
#32
吵概念第一,做点东西给大家看看先?!
#33
友情up，呵呵
#34
where?
#35
最难得的,书完全免费:)
#36
To chnlog(飞鱼)
我不敢苟同你的说法。我反对无止境的讨论概念，但是对概念不深入了解，绝对不能先去做东西！
我不敢苟同你的说法。我反对无止境的讨论概念，但是对概念不深入了解，绝对不能先去做东西！
#37
我已经去叫他了，应该会了的。
#38
谢谢大家的支持，今天一直没有来，所以...
我是觉得其实状态本身是在客观世界存在的物质之外，经过更深抽象而出来的概念，比如对象中的一般成员（我是指按照经典的C++或者是面向对象理论建立的成员）可能更适合和现实中的客观事物对应，“车”，那么车的车门，这是本身存在的，大小，形状都是客观的，人们的抽象只是为其取了一个名字，而车门关这个状态也是客观存在的，并不会因为人们没有认识到而不存在，但是，这个状态是在上一个抽象结果上更深一步的抽象，因为他不是一个客观世界的物质，只有具有思想和思维意识之后才可能对其产生认识。因此状态是在对象的基础上的，而且必然是对象的更高一级抽象，不能利用建议简单的静态结构描述一个车的运行状况。
从物理学的角度，不应该认为状态必须是持续的，可以有瞬间状态、也有一些是连续状态，一些是离散状态，而在计算机中似乎更适合出来离散状态，持续状态和非持续状态之间的关系，我认为就是如同数学中函数和函数的导数之间的关系，这个在书中第三章介绍过，我觉得这样整个面向对象的理论才更趋于完美，就象数学家喜欢追求完美的表达一样，如果将事件（在BCB中就是一种特殊的属性Property）看作是另一个相关属性或者属性表达的状态的改变，那么VCL的机构体系将变得非常完美，因为“离散的函数只需要取其一阶导数和函数本身就可以进行比较接近的研究”，而上面也提到过，计算机更适合于离散状态的处理，对于联系状态，只能通过转换变为离散的状态，才可能使用计算机处理，比如在车的速度上我们很自然的使用if(Speed>0) 或者if(Speed!=0)等表示。
将事件看成是属性的导数是完全可以站得住脚，这也并不是一个巧合，向Edit中的OnChanged，分明就是Edit中Text发生改变的时候触发的事件，这个改变过程不管是键盘击键，还是输入法传递、还是粘贴剪切板而得到的，终归对Edit对象产生的影响只有一个，就是Text随之改变，因此Edit->Text的改变OnChaned和Edit->Text显然就是一种函数和导数的关系。
还有就是OnClick，我在书中多次提到不能将VCL中的事件和Windows消息混为一滩，这是两个不同层次的概念，事件必须是基于对象的，而消息则不是针对对象的，OnClick在所有的VCL控件（不是指组件）中都存在，但是其行为含义是不一样，最常见的就是鼠标的点击会产生，但也可能是由于键盘的操作而产生的，比如前天还是昨天有个朋友在基础版问一个RadioGroup的OnClick事件，其实正式对事件没有正确理解而造成的，如果按照面向状态中的理论去理解，一般的看到一个控件根据我们对控件（对象）行为的分析，就不难得出会在什么情况下触发这个OnClick事件。
TDrawing中为了简明扼要，使用了TShape，但是以我个人的观点使用TControl作为基类是最合适的，可以简单的分析一个图形对象，它的基本行为就是TControl中定义的大部分行为，如果你要重新定义一个完全属于自己的类库，那当然没有错，很多优秀的软件都会是这样，但并不一定有必要“除非你是从事图形方面软件开发多年的专家，否则不要试图自己重新设计一套基本图形类库”我却是是这样认为的，因为我就是这样的情况，可以在很短的时间作出这个例子，并不高效，也并不优秀，但却非常具有高效性，这也正式C++和面向对象带来的好处。
打字实在太累了，欢迎大家发表意见。
我是觉得其实状态本身是在客观世界存在的物质之外，经过更深抽象而出来的概念，比如对象中的一般成员（我是指按照经典的C++或者是面向对象理论建立的成员）可能更适合和现实中的客观事物对应，“车”，那么车的车门，这是本身存在的，大小，形状都是客观的，人们的抽象只是为其取了一个名字，而车门关这个状态也是客观存在的，并不会因为人们没有认识到而不存在，但是，这个状态是在上一个抽象结果上更深一步的抽象，因为他不是一个客观世界的物质，只有具有思想和思维意识之后才可能对其产生认识。因此状态是在对象的基础上的，而且必然是对象的更高一级抽象，不能利用建议简单的静态结构描述一个车的运行状况。
从物理学的角度，不应该认为状态必须是持续的，可以有瞬间状态、也有一些是连续状态，一些是离散状态，而在计算机中似乎更适合出来离散状态，持续状态和非持续状态之间的关系，我认为就是如同数学中函数和函数的导数之间的关系，这个在书中第三章介绍过，我觉得这样整个面向对象的理论才更趋于完美，就象数学家喜欢追求完美的表达一样，如果将事件（在BCB中就是一种特殊的属性Property）看作是另一个相关属性或者属性表达的状态的改变，那么VCL的机构体系将变得非常完美，因为“离散的函数只需要取其一阶导数和函数本身就可以进行比较接近的研究”，而上面也提到过，计算机更适合于离散状态的处理，对于联系状态，只能通过转换变为离散的状态，才可能使用计算机处理，比如在车的速度上我们很自然的使用if(Speed>0) 或者if(Speed!=0)等表示。
将事件看成是属性的导数是完全可以站得住脚，这也并不是一个巧合，向Edit中的OnChanged，分明就是Edit中Text发生改变的时候触发的事件，这个改变过程不管是键盘击键，还是输入法传递、还是粘贴剪切板而得到的，终归对Edit对象产生的影响只有一个，就是Text随之改变，因此Edit->Text的改变OnChaned和Edit->Text显然就是一种函数和导数的关系。
还有就是OnClick，我在书中多次提到不能将VCL中的事件和Windows消息混为一滩，这是两个不同层次的概念，事件必须是基于对象的，而消息则不是针对对象的，OnClick在所有的VCL控件（不是指组件）中都存在，但是其行为含义是不一样，最常见的就是鼠标的点击会产生，但也可能是由于键盘的操作而产生的，比如前天还是昨天有个朋友在基础版问一个RadioGroup的OnClick事件，其实正式对事件没有正确理解而造成的，如果按照面向状态中的理论去理解，一般的看到一个控件根据我们对控件（对象）行为的分析，就不难得出会在什么情况下触发这个OnClick事件。
TDrawing中为了简明扼要，使用了TShape，但是以我个人的观点使用TControl作为基类是最合适的，可以简单的分析一个图形对象，它的基本行为就是TControl中定义的大部分行为，如果你要重新定义一个完全属于自己的类库，那当然没有错，很多优秀的软件都会是这样，但并不一定有必要“除非你是从事图形方面软件开发多年的专家，否则不要试图自己重新设计一套基本图形类库”我却是是这样认为的，因为我就是这样的情况，可以在很短的时间作出这个例子，并不高效，也并不优秀，但却非常具有高效性，这也正式C++和面向对象带来的好处。
打字实在太累了，欢迎大家发表意见。
#39
不错，很有创意。受教了。
#40
学习
#41
再up
#42
学习......
#43
Lewolf，我还有一个问题，在面向对象的程序设计中是把数据，方法封装在“车子”里，如果按照你的理论那么车子->速度=n，那么是不是车子就应该自动运动，但是还有一些还有一些方法不能简单用状态描述，比如车子需要repare()？
#44
看来被我们的大佬点名的人,定是有来头的人啊!!!
好记住你,收藏你,有问题直接找你...
大佬:你的INTER BASE的是何时面世啊
好记住你,收藏你,有问题直接找你...
大佬:你的INTER BASE的是何时面世啊
#45
To: Aweay(BCB绝对实力派)
你说的很对，车子->速度，如果是一个成员的话，就不是一个普通的成员，因为速度这个东西在现实世界中找不到的（我指的是你不可能用手指指出来说：“这就是速度”），如果令“车子->速度=n”而车子还停止没有动的话，显然对象是错误的行为，或者说不够完整的，只有状态和记录状态的数据完全一致的时候，这个记录的数据才可能具有现实的意义，否则没有任何价值，当然在程序设计中这种情况是存在的，那只能说，设计的思想或者方法存在着瑕疵。
实际上使用C++ Builder就已经使用了状态的这种特征，就如同书中的HelloWord。
对于如同Repare等方法，却是存在的，因为这个在现实中也是存在的，现实中“车子->速度=n”这个操作显然还有很多“内部的工作”比如调整变速箱，调整供油量等，问题是这些细节对于操作员来讲是否一定需要关心，显然答案是有些需要，有些不需要。如果Repare不需要公开给“车子对象”的使用者，那么就可以通过封装使其藏在对象的内部，对外我们提供的是相关性最小的属性和方法，这一点在C++ Builde的帮助中也有描述。
有一个组件的例子，TTable，C++ Builder中描述可以用于桌面数据库和基于SQL多层机构，很多人以为TTable操作Sql Server比TQuery效率要低，其实不然，我作过简单的测试，并不是这样的，TTable对Sql数据库操作的时候实际上在内部还是使用Sql语言，诸如使用Filter，Master/Detail等以及IndexNames等的时候，你需要作的是直接为他们赋值，这就相当于“车子->速度=n”，而TTable实际上要作很多的工作，你使用TQuery的时候要作的一些工作都是TTable在内部完成的，相当于你说的Repare的工作。
当然状态并不是所有，而且大多数时候并不一定需要这样作，就如同面向对象的设计中仍然遵循着三种基本结构，那你是说面向对象是某些过程或者说是结构化设计的替代者还是发展者，其实他们永远是共存的。对象是和状态紧密联系在一起的，而状态必须是对象的进一步抽象，没有车门的概念自然就没有车门是否关的状态。
你说的很对，车子->速度，如果是一个成员的话，就不是一个普通的成员，因为速度这个东西在现实世界中找不到的（我指的是你不可能用手指指出来说：“这就是速度”），如果令“车子->速度=n”而车子还停止没有动的话，显然对象是错误的行为，或者说不够完整的，只有状态和记录状态的数据完全一致的时候，这个记录的数据才可能具有现实的意义，否则没有任何价值，当然在程序设计中这种情况是存在的，那只能说，设计的思想或者方法存在着瑕疵。
实际上使用C++ Builder就已经使用了状态的这种特征，就如同书中的HelloWord。
对于如同Repare等方法，却是存在的，因为这个在现实中也是存在的，现实中“车子->速度=n”这个操作显然还有很多“内部的工作”比如调整变速箱，调整供油量等，问题是这些细节对于操作员来讲是否一定需要关心，显然答案是有些需要，有些不需要。如果Repare不需要公开给“车子对象”的使用者，那么就可以通过封装使其藏在对象的内部，对外我们提供的是相关性最小的属性和方法，这一点在C++ Builde的帮助中也有描述。
有一个组件的例子，TTable，C++ Builder中描述可以用于桌面数据库和基于SQL多层机构，很多人以为TTable操作Sql Server比TQuery效率要低，其实不然，我作过简单的测试，并不是这样的，TTable对Sql数据库操作的时候实际上在内部还是使用Sql语言，诸如使用Filter，Master/Detail等以及IndexNames等的时候，你需要作的是直接为他们赋值，这就相当于“车子->速度=n”，而TTable实际上要作很多的工作，你使用TQuery的时候要作的一些工作都是TTable在内部完成的，相当于你说的Repare的工作。
当然状态并不是所有，而且大多数时候并不一定需要这样作，就如同面向对象的设计中仍然遵循着三种基本结构，那你是说面向对象是某些过程或者说是结构化设计的替代者还是发展者，其实他们永远是共存的。对象是和状态紧密联系在一起的，而状态必须是对象的进一步抽象，没有车门的概念自然就没有车门是否关的状态。
#46
书 在那里
免费的吗
我要
免费的吗
我要
#47
信誉分 我也想要加啊!!! 如何帮我加加啊
#48
原来如此，i know....
lewolf的书在www.chinabcb.com下载，他也是那里的斑竹。
lewolf的书在www.chinabcb.com下载，他也是那里的斑竹。
#49
大家可以多去那里一起交流。
#50
速度: 为何物啦 是运动对象的属性而已拉
#1
捧场
#2
不错,不错
#3
捧场
#4
蹭分 :D
#5
学习
#6
听说Lewolf去chinabcb做斑竹！
我打个马夹占个位子！
呵呵
我打个马夹占个位子！
呵呵
#7
是不是听我说的?
#8
捧场
#9
怎么没有其他高手发表一下自己的心得了，给我们这些后进学习学习：）
#10
作品在哪里？
-----------------------------------
什么时候有时间、有朋友一起去踢球呢？
-----------------------------------
什么时候有时间、有朋友一起去踢球呢？
#11
虚心学习哦
#12
学习+捧场
#13
lewolf的大作我也看了，对于他书中的提法没有意见，并且认为作合很有创新，不过对作者最后的例子程序倒是有一点想法：
lewolf最后的那个矢量绘图软件，我认为设计方法上有一点问题，对于矢量图形我认为应该自己重新设计自己的类，而不应该从TShape继承，我认为这有点投机的意思。
lewolf最后的那个矢量绘图软件，我认为设计方法上有一点问题，对于矢量图形我认为应该自己重新设计自己的类，而不应该从TShape继承，我认为这有点投机的意思。
#14
蹭分
#15
我接砖头:)
#16
学习～～
#17
学习中，接分快乐！
#18
to TR@SOE () ：
你的书什么时候出来？
你的书什么时候出来？
#19
学习，看看
#20
学习.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
期待着lewolf的出现..呵呵.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
期待着lewolf的出现..呵呵.
#21
学习
#22
To Aweay:
我觉得书中的这个例子不是为了矢量图形而做。而是为了这种面向状态编程
况且这样的矢量图形根本起不到矢量作用.作者也就用了一两天的时间做它而已。
我觉得书中的这个例子不是为了矢量图形而做。而是为了这种面向状态编程
况且这样的矢量图形根本起不到矢量作用.作者也就用了一两天的时间做它而已。
#23
打错字了。他好像是说一两个小时做这例子而已。
#24
例子本身只能用来辅佐说明思想。
#25
版主说的对。
这例子.甚至本书不是为了编写矢量软件而写的。
版主您的性欲怎么也这么低啊？
这例子.甚至本书不是为了编写矢量软件而写的。
版主您的性欲怎么也这么低啊？
#26
TR的信誉是该涨涨了，要不总有人问
@_@
@_@
#27
前几天LeWolf帮我解决了一个问题,我想谢谢他
#28
^_^,中心人物怎么没有来?>
to meCAD TR@SOE 是为了特别所以才....
明天给他涨涨,...
to meCAD TR@SOE 是为了特别所以才....
明天给他涨涨,...
#29
呵呵,我也来接分,同时想请高手顺便到下面看看,帮帮忙解决这个问题
http://expert.csdn.net/Expert/topic/1885/1885390.xml?temp=.2522547
因为这里好象高手比较多
http://expert.csdn.net/Expert/topic/1885/1885390.xml?temp=.2522547
因为这里好象高手比较多
#30
不好意思
抢劫了。
抢劫了。
#31
怎么还没来？？
#32
吵概念第一,做点东西给大家看看先?!
#33
友情up，呵呵
#34
where?
#35
最难得的,书完全免费:)
#36
To chnlog(飞鱼)
我不敢苟同你的说法。我反对无止境的讨论概念，但是对概念不深入了解，绝对不能先去做东西！
我不敢苟同你的说法。我反对无止境的讨论概念，但是对概念不深入了解，绝对不能先去做东西！
#37
我已经去叫他了，应该会了的。
#38
谢谢大家的支持，今天一直没有来，所以...
我是觉得其实状态本身是在客观世界存在的物质之外，经过更深抽象而出来的概念，比如对象中的一般成员（我是指按照经典的C++或者是面向对象理论建立的成员）可能更适合和现实中的客观事物对应，“车”，那么车的车门，这是本身存在的，大小，形状都是客观的，人们的抽象只是为其取了一个名字，而车门关这个状态也是客观存在的，并不会因为人们没有认识到而不存在，但是，这个状态是在上一个抽象结果上更深一步的抽象，因为他不是一个客观世界的物质，只有具有思想和思维意识之后才可能对其产生认识。因此状态是在对象的基础上的，而且必然是对象的更高一级抽象，不能利用建议简单的静态结构描述一个车的运行状况。
从物理学的角度，不应该认为状态必须是持续的，可以有瞬间状态、也有一些是连续状态，一些是离散状态，而在计算机中似乎更适合出来离散状态，持续状态和非持续状态之间的关系，我认为就是如同数学中函数和函数的导数之间的关系，这个在书中第三章介绍过，我觉得这样整个面向对象的理论才更趋于完美，就象数学家喜欢追求完美的表达一样，如果将事件（在BCB中就是一种特殊的属性Property）看作是另一个相关属性或者属性表达的状态的改变，那么VCL的机构体系将变得非常完美，因为“离散的函数只需要取其一阶导数和函数本身就可以进行比较接近的研究”，而上面也提到过，计算机更适合于离散状态的处理，对于联系状态，只能通过转换变为离散的状态，才可能使用计算机处理，比如在车的速度上我们很自然的使用if(Speed>0) 或者if(Speed!=0)等表示。
将事件看成是属性的导数是完全可以站得住脚，这也并不是一个巧合，向Edit中的OnChanged，分明就是Edit中Text发生改变的时候触发的事件，这个改变过程不管是键盘击键，还是输入法传递、还是粘贴剪切板而得到的，终归对Edit对象产生的影响只有一个，就是Text随之改变，因此Edit->Text的改变OnChaned和Edit->Text显然就是一种函数和导数的关系。
还有就是OnClick，我在书中多次提到不能将VCL中的事件和Windows消息混为一滩，这是两个不同层次的概念，事件必须是基于对象的，而消息则不是针对对象的，OnClick在所有的VCL控件（不是指组件）中都存在，但是其行为含义是不一样，最常见的就是鼠标的点击会产生，但也可能是由于键盘的操作而产生的，比如前天还是昨天有个朋友在基础版问一个RadioGroup的OnClick事件，其实正式对事件没有正确理解而造成的，如果按照面向状态中的理论去理解，一般的看到一个控件根据我们对控件（对象）行为的分析，就不难得出会在什么情况下触发这个OnClick事件。
TDrawing中为了简明扼要，使用了TShape，但是以我个人的观点使用TControl作为基类是最合适的，可以简单的分析一个图形对象，它的基本行为就是TControl中定义的大部分行为，如果你要重新定义一个完全属于自己的类库，那当然没有错，很多优秀的软件都会是这样，但并不一定有必要“除非你是从事图形方面软件开发多年的专家，否则不要试图自己重新设计一套基本图形类库”我却是是这样认为的，因为我就是这样的情况，可以在很短的时间作出这个例子，并不高效，也并不优秀，但却非常具有高效性，这也正式C++和面向对象带来的好处。
打字实在太累了，欢迎大家发表意见。
我是觉得其实状态本身是在客观世界存在的物质之外，经过更深抽象而出来的概念，比如对象中的一般成员（我是指按照经典的C++或者是面向对象理论建立的成员）可能更适合和现实中的客观事物对应，“车”，那么车的车门，这是本身存在的，大小，形状都是客观的，人们的抽象只是为其取了一个名字，而车门关这个状态也是客观存在的，并不会因为人们没有认识到而不存在，但是，这个状态是在上一个抽象结果上更深一步的抽象，因为他不是一个客观世界的物质，只有具有思想和思维意识之后才可能对其产生认识。因此状态是在对象的基础上的，而且必然是对象的更高一级抽象，不能利用建议简单的静态结构描述一个车的运行状况。
从物理学的角度，不应该认为状态必须是持续的，可以有瞬间状态、也有一些是连续状态，一些是离散状态，而在计算机中似乎更适合出来离散状态，持续状态和非持续状态之间的关系，我认为就是如同数学中函数和函数的导数之间的关系，这个在书中第三章介绍过，我觉得这样整个面向对象的理论才更趋于完美，就象数学家喜欢追求完美的表达一样，如果将事件（在BCB中就是一种特殊的属性Property）看作是另一个相关属性或者属性表达的状态的改变，那么VCL的机构体系将变得非常完美，因为“离散的函数只需要取其一阶导数和函数本身就可以进行比较接近的研究”，而上面也提到过，计算机更适合于离散状态的处理，对于联系状态，只能通过转换变为离散的状态，才可能使用计算机处理，比如在车的速度上我们很自然的使用if(Speed>0) 或者if(Speed!=0)等表示。
将事件看成是属性的导数是完全可以站得住脚，这也并不是一个巧合，向Edit中的OnChanged，分明就是Edit中Text发生改变的时候触发的事件，这个改变过程不管是键盘击键，还是输入法传递、还是粘贴剪切板而得到的，终归对Edit对象产生的影响只有一个，就是Text随之改变，因此Edit->Text的改变OnChaned和Edit->Text显然就是一种函数和导数的关系。
还有就是OnClick，我在书中多次提到不能将VCL中的事件和Windows消息混为一滩，这是两个不同层次的概念，事件必须是基于对象的，而消息则不是针对对象的，OnClick在所有的VCL控件（不是指组件）中都存在，但是其行为含义是不一样，最常见的就是鼠标的点击会产生，但也可能是由于键盘的操作而产生的，比如前天还是昨天有个朋友在基础版问一个RadioGroup的OnClick事件，其实正式对事件没有正确理解而造成的，如果按照面向状态中的理论去理解，一般的看到一个控件根据我们对控件（对象）行为的分析，就不难得出会在什么情况下触发这个OnClick事件。
TDrawing中为了简明扼要，使用了TShape，但是以我个人的观点使用TControl作为基类是最合适的，可以简单的分析一个图形对象，它的基本行为就是TControl中定义的大部分行为，如果你要重新定义一个完全属于自己的类库，那当然没有错，很多优秀的软件都会是这样，但并不一定有必要“除非你是从事图形方面软件开发多年的专家，否则不要试图自己重新设计一套基本图形类库”我却是是这样认为的，因为我就是这样的情况，可以在很短的时间作出这个例子，并不高效，也并不优秀，但却非常具有高效性，这也正式C++和面向对象带来的好处。
打字实在太累了，欢迎大家发表意见。
#39
不错，很有创意。受教了。
#40
学习
#41
再up
#42
学习......
#43
Lewolf，我还有一个问题，在面向对象的程序设计中是把数据，方法封装在“车子”里，如果按照你的理论那么车子->速度=n，那么是不是车子就应该自动运动，但是还有一些还有一些方法不能简单用状态描述，比如车子需要repare()？
#44
看来被我们的大佬点名的人,定是有来头的人啊!!!
好记住你,收藏你,有问题直接找你...
大佬:你的INTER BASE的是何时面世啊
好记住你,收藏你,有问题直接找你...
大佬:你的INTER BASE的是何时面世啊
#45
To: Aweay(BCB绝对实力派)
你说的很对，车子->速度，如果是一个成员的话，就不是一个普通的成员，因为速度这个东西在现实世界中找不到的（我指的是你不可能用手指指出来说：“这就是速度”），如果令“车子->速度=n”而车子还停止没有动的话，显然对象是错误的行为，或者说不够完整的，只有状态和记录状态的数据完全一致的时候，这个记录的数据才可能具有现实的意义，否则没有任何价值，当然在程序设计中这种情况是存在的，那只能说，设计的思想或者方法存在着瑕疵。
实际上使用C++ Builder就已经使用了状态的这种特征，就如同书中的HelloWord。
对于如同Repare等方法，却是存在的，因为这个在现实中也是存在的，现实中“车子->速度=n”这个操作显然还有很多“内部的工作”比如调整变速箱，调整供油量等，问题是这些细节对于操作员来讲是否一定需要关心，显然答案是有些需要，有些不需要。如果Repare不需要公开给“车子对象”的使用者，那么就可以通过封装使其藏在对象的内部，对外我们提供的是相关性最小的属性和方法，这一点在C++ Builde的帮助中也有描述。
有一个组件的例子，TTable，C++ Builder中描述可以用于桌面数据库和基于SQL多层机构，很多人以为TTable操作Sql Server比TQuery效率要低，其实不然，我作过简单的测试，并不是这样的，TTable对Sql数据库操作的时候实际上在内部还是使用Sql语言，诸如使用Filter，Master/Detail等以及IndexNames等的时候，你需要作的是直接为他们赋值，这就相当于“车子->速度=n”，而TTable实际上要作很多的工作，你使用TQuery的时候要作的一些工作都是TTable在内部完成的，相当于你说的Repare的工作。
当然状态并不是所有，而且大多数时候并不一定需要这样作，就如同面向对象的设计中仍然遵循着三种基本结构，那你是说面向对象是某些过程或者说是结构化设计的替代者还是发展者，其实他们永远是共存的。对象是和状态紧密联系在一起的，而状态必须是对象的进一步抽象，没有车门的概念自然就没有车门是否关的状态。
你说的很对，车子->速度，如果是一个成员的话，就不是一个普通的成员，因为速度这个东西在现实世界中找不到的（我指的是你不可能用手指指出来说：“这就是速度”），如果令“车子->速度=n”而车子还停止没有动的话，显然对象是错误的行为，或者说不够完整的，只有状态和记录状态的数据完全一致的时候，这个记录的数据才可能具有现实的意义，否则没有任何价值，当然在程序设计中这种情况是存在的，那只能说，设计的思想或者方法存在着瑕疵。
实际上使用C++ Builder就已经使用了状态的这种特征，就如同书中的HelloWord。
对于如同Repare等方法，却是存在的，因为这个在现实中也是存在的，现实中“车子->速度=n”这个操作显然还有很多“内部的工作”比如调整变速箱，调整供油量等，问题是这些细节对于操作员来讲是否一定需要关心，显然答案是有些需要，有些不需要。如果Repare不需要公开给“车子对象”的使用者，那么就可以通过封装使其藏在对象的内部，对外我们提供的是相关性最小的属性和方法，这一点在C++ Builde的帮助中也有描述。
有一个组件的例子，TTable，C++ Builder中描述可以用于桌面数据库和基于SQL多层机构，很多人以为TTable操作Sql Server比TQuery效率要低，其实不然，我作过简单的测试，并不是这样的，TTable对Sql数据库操作的时候实际上在内部还是使用Sql语言，诸如使用Filter，Master/Detail等以及IndexNames等的时候，你需要作的是直接为他们赋值，这就相当于“车子->速度=n”，而TTable实际上要作很多的工作，你使用TQuery的时候要作的一些工作都是TTable在内部完成的，相当于你说的Repare的工作。
当然状态并不是所有，而且大多数时候并不一定需要这样作，就如同面向对象的设计中仍然遵循着三种基本结构，那你是说面向对象是某些过程或者说是结构化设计的替代者还是发展者，其实他们永远是共存的。对象是和状态紧密联系在一起的，而状态必须是对象的进一步抽象，没有车门的概念自然就没有车门是否关的状态。
#46
书 在那里
免费的吗
我要
免费的吗
我要
#47
信誉分 我也想要加啊!!! 如何帮我加加啊
#48
原来如此，i know....
lewolf的书在www.chinabcb.com下载，他也是那里的斑竹。
lewolf的书在www.chinabcb.com下载，他也是那里的斑竹。
#49
大家可以多去那里一起交流。
#50
速度: 为何物啦 是运动对象的属性而已拉