讨论：什么是面对对象

[Panr]

题：关于“面对对象”理论
Panr 2004-01-02_16-00



／／／／／／／／／／／／／／／／／／
／／０前言
／／０.１来由
这段时间我一直在考虑架构的问题，经过一段时间的努力，CSDN 上的讨论过程如下
http://expert.csdn.net/Expert/TopicView1.asp?id=1988630
http://expert.csdn.net/Expert/TopicView1.asp?id=2211555
http://expert.csdn.net/Expert/TopicView1.asp?id=2224368
http://expert.csdn.net/Expert/TopicView1.asp?id=2464664

在试图用不同的方法描述以后，我决定把原帖分为两个主题：
1.软工中的信息流转，参考这个帖子
http://expert.csdn.net/Expert/TopicView1.asp?id=2509650

2.ＯＯ理论与主要模型类别（模型类别就是自动机）
“对象”就是数据实例，是一个状态上下文，它描述了一个实例当前处在什么状态
“类型”定义了对象特性，它能够根据当前状态和当前消息确定出对象的下一状态

欢迎在本帖子中讨论



／／０.２目录
０前言
　０.１来由
　０.２目录

１形象
　１.１概述
　１.２面向过程
　１.３基于对象
　１.４面向术语
　１.５面向过程向基于对象进化
　１.６基于对象向面向术语进化

２自动机
　２.１概述
　２.２特点的比较
　２.３面向过程的图灵机
　２.４基于对象的协作机
　２.５面向术语的智能机







／／／／／／／／／／／／／／／／／／
／／１形象
／／１.１概述
计算机程序的代码总是会被划分在多个模块中，根据划分模块不同，我们可以把程序归类为以下三类
面向过程的程序
基于对象的程序
面向术语的程序


／／１.２面向过程
典型的面向过程的例子是汽车的组装流水线。我们将建设几间厂房，一间厂房中布置了几条组装流水线，在一号厂房中有一条轿车组装线、一条面包车组装线；二号厂房有两条公交车组装线，...

现在我要组装一辆卡车时，就需要先确定厂房，然后找到卡车的组装线，再把所有的工件提供给组装线，最后我们就可以得到一辆完整的卡车了
每一条组装加工的流水线就是一个功能函数，通过对特定的工件的组装加工，我们获得处理的结果


／／１.３基于对象
典型的基于对象的例子是“绿色贝雷帽的战斗小组”。每组十二人，首先是组长和副组长，然后是担任作战任务的士官2人、担任维修和技术任务的士官2人、担任医疗任务的士官2人、配备重火器的士官和轻武器的士官各1人、担任通讯任务的士官2人

可以想象得出小组成员必然经过许多的“作战”“医疗”和“通讯”这些基本的训练，所有的人都能作战，会处理伤口，使用所携带的通讯器材....
那么为什么不能平衡体力消耗“今天你扛了重火器，明天就扛轻一点的医药箱”呢？

我指定这两位为作战兵，那两位为医疗兵，是因为我的士兵不在乎这点体力，我需要明确职责便于管理
如果没有指定医疗兵，医药箱就极有可能是轮流扛的，这样副组长将分心考虑药品有没有受潮，麻醉剂需要避光保存等杂务
现在组长知道有人受伤了，他只是需要喊一声医疗兵，然后问一下医疗兵伤员需要休息几个小时才能恢复战斗力

所以虽然在战斗小组中只有一样的特种队员，但是我还建立了七个抽象数据类型来说明
组长、作战兵、重火器兵、轻武器兵、通讯兵、维修兵、医疗兵


／／１.４面向术语
典型的面向术语的例子是“经济类犯罪”。法律都是以条款的形式的被规定的，所以法律条款中的术语是什么含义是很值得研究的。比如“人”这个术语，最初有人提出法律面前人人平等，然后经济马上扩展了“人”的外延，把政府机关、经济实体称为“法人”

经济法中有一种做法叫“合理避税”，比如用公司的固定资产乘上折旧率，把折旧费用作为生产的支出的一部分，那就可以减少一部分的税收了，这就是“合理避税”
假设少做某一笔帐可以少交了一千，电脑的折旧支出也可以少交了一千
那么你不做那笔帐也没报折旧支出，少交了一千税款并且犯了法；做那笔帐又上报折旧支出，你还是少交了一千的税款但是没犯法

法盲不值得被同情。文字游戏是有意义的，有些东西是值得推敲的，术语概念则需要被准确地理解和熟练地运用

-----杂谈
上面的例子是术语的运用，术语的理解来说有两个问题，行业术语过于口语化，术语随着时代（市场定位）发生变化
过于口语化的定义将经不起推敲，比如摄像监控中会有一个词叫“警情”，报警的发生叫做“警情来了”，后来我把警情分成了“报警信息”“警情录象”两个概念
-----


／／１.５面向过程向基于对象进化
为每条组装流水线配备一个“Line长”，为每个厂房配备一个“车间主任”
这样以后，就有了基于对象的形式，各个组件间通过团结协作达成共同的目标，我们在全局上将主要考虑如何协作的问题
为了进一步优化，我们可能需要不断重构组件


／／１.６基于对象向面向术语进化
把战斗小组的人数增加到1400，或者十万人，那么什么后勤保障系统、辅助管理系统都会建立起来
这样以后，许多的工作都不得不通过交流来完成，这种交流就是一种条款的方式，我们在全局上将主要考虑公正性和合理性的问题









／／／／／／／／／／／／／／／／／／
／／２自动机
／／２.１概述
自动机系统是研究信息处理工程的概念，是一台“能回答某个问题的机器”
一个自动机只能回答一个问题，而且对你提问的格式有很多的要求
通俗打个比方说明：
int AutomataAdd (int nA, int nB)
{
int nAnswer;
nAnswer = nA + nB;
return nAnswer;
};
这里的AutomataAdd 就是一个加法自动机（只能回答加法问题），你只能按“被加数”和“加数”的格式提问，然后AutomataAdd 将告诉你答案

自动机可以包括以下基本型：
“图灵机型”是面向过程的软件实现模式，前面的AutomataAdd 就是一个例子
“协作机型”是基于对象的软件实现模式
“智能机型”是面向术语的软件实现模式，是自动机的乌托邦，它将运用信息理论中的所有知识


／／２.２特点的比较
表２.２.１、运用类特点的比较
　　　　　　基本特征　　　　　　　运用软件
面向过程　实现功能的代码　　自动化
基于对象　便于管理的数据　　管理类软件
面向术语　具有智能的术语　　具有自动学习能力的软件

表２.２.２、实现类特点的比较
　　　　　研究主题　　工作途径　　　　　指导原则　　　　
面向过程　　算法　　逻辑推理的运用　实现功能　
基于对象　　构架　　架构的设计　　　满足客户所有需求　　　
面向术语　　知识　　术语的进化　　　术语的的语义合理性　



／／２.３面向过程的图灵机
设计图灵机的工作途径是：运用推理逻辑
图灵机是这种操作策略的结果：［无策略］
关键的问题是要找出从输入（问题）到输出（答案）的推理过程

推理过程其实是我们自己的分析推理的过程，是通过“分析推理的自动化（模拟解题过程）”来获得答案的自动机
这个推理过程在必须是无歧义地在有限次操作内完成，通过顺序点的概念我们将可以把“这个推理过程”和“程序运行时上下文”一一对应起来


／／２.４基于对象的协作机
设计协作机的工作途径是：架构的设计
协作机是这种操作策略的结果：先明确研究对象，再研究和设计对象间的协作关系
关键的问题是要找出业务数据，并规定业务数据间的交互协同等作用关系

业务数据就是我们的研究对象，“对象实例通过交互协作后，属性所处的状态”就是自动机相关问题的答案

-----杂谈
其实“先明确研究对象再展开研究”的做法在哲学上是错误的
正确的做法是：先观察现象，归纳属性，再决定是否要针对某几个属性组合出一个术语概念

“明确研究对象”这个过程肯定是工作的一部分
如果这个工作是由程序本身完成的，那将再不是单纯的协作机
-----


／／２.５面向术语的智能机
设计智能机的工作途径是：术语的进化
智能机是这种操作策略的结果：术语系统的迭代
协作机中“明确研究对象”的过程就是构造“低版本的术语系统”，这个过程只是认知过程的起点，而后我们还要在此基础上在不断地进化推演和实践，修改术语概念的定义，获得“高版本的术语系统”

智能机是协作机的扩展，它回答问题的模式就是协作机的模式
但是智能机中，数据实例具有什么属性是可以变化的，既然协作机是通过“属性所处的状态”回答问题的，原则上它具有更自由的答题能力
这就是术语的进化过程

[slimsymphony]

哲学+神经网络+rup+cmm
就是楼主的模型构成

[ozzzzzz]

Panr(光荣)
Cockburn和Coad不是考嘲讽人发家的，他们是实实在在的作了项目，搞了实实在在的理论，并且别人按照他们的理论实施取得了实实在在的效果才取得这样的称号的。而那些人则没有这样的资力也没有这样的能力，还总是被那么一个小圈子认为是方法学家和建模专家，所以才会有人说那才是真正的专家。你不要搞错意思，这些人都是真正的行业领袖，都是实践和理论都是有所建树的真正专家，也只有他们才可以无愧于专家的称号。他们的实践是那些躲在SEI象牙塔的人一辈子也赶不上的，他们的活跃也是那些循规蹈矩的家伙所不能比拟的。只有这样的人才是专家。

你现在又用了一个基于对象和面向对象的概念，不知道你是不是人面向对象就是面向术语？而我们一直讨论的都是程序本身的问题，而不是程序设计的问题。而现在的环境下程序就是程序，他们就是一堆数据和命令的组合。面向对象也好，面向过程也罢，以至于混沌的做法，都是要通过编译器成为一种相同的形式，并被操作系统装入内存。你不能认为使用cpp的编的就比c编的好，就更加面向对象。
神经网络现在的主要应用就是模式识别，所谓的统计就是统计其是不是和某个模式相对应。它自身无法判断优劣，它只能判断是不是合乎某些模式。如果你可以建立一个模式用来说明优劣，那样也只是一种受控的判断，还不能达到你的那种自动机的要求。

到你的实际例子看来你根本就不明白什么是建模和智能思考。“一看见雇员和雇主，就马上告诉自己他们有个公共的基类型叫做“人类”这种做法是错误的，即使真的需要建立一个“人类”的概念，也不是信息系统的需要，因为我们并不需要这些生物特性”这绝对是一种自然的反映，是一种分析问题的方法。其实我们在分析问题的时候，总是先建立起一个解析问题的模式模型，这就是一种类比。遇到雇员和雇主自然就会先想到人，这就是我们人类固有的分析问题的方法，如果这个也错了，那么我们就只能说明我们人类几千年的历史都错了，我们的进化都错了。而且更加危险的是你忽略了分析模型和设计模型的区别，一个在分析模型中存在的对象，未必就一定要存在于设计模型中；一个开始在分析模型中存在的对象，未必一定最后也存在于分析模型中。这是一个动态调整的过程，你又在犯瀑布的不回头的错误。
而你后面的分析更加危险。设计软件的时候必须以其实际的为中心，也就是其代码的实现为中心，就是你说的以“抽象数据为中心”。而分析则才是以领域中的概念为中心，也就是以你说的术语为中心。分析问题不能等同于解决问题，虽然他们结合紧密，但是还是有所不同。

[spidertan]

是不是应该把设计和实现两个阶段分开来讨论,我感觉两位是各持一词!

[libi]

唉，怎么又说到玄学上了。“以火炼金”仅是一个名称，指一种练内丹的方法，如果没有“令神返归身中”的说明，只说练时如身在宏炉，如万蚁噬身，那不就像黄蓉给欧阳锋背《九阴真经》一样，有什么用呢。当然不是一点用也没有，对于绝顶高手，可以从练功后的迹象揣摩出功法，但不是每个人都是欧阳锋呀。
诚然，你说的“智能机”是研究术语的，它必须“混淆”代码与数据（应该说是同等对待它们），这是实现“智能机”的必要条件。这并不难理解，速度和加速度在物理上是不同含义的两个物理量，在数学上则都是两个函数，在“智能机”角度看来，代码与数据是同等的，但你如何处理它们，关键是如何“抽象”出术语。
关于“雇员和雇主”的说法也是正确的。我们现在所说的“面向对象”的方法都是由人先分析和设计模型，然后让计算机去照着执行，这是一个从模型到数据的过程，我们必须先制定好模型，并且没有人为参与，模型不会改变，因此，我们为了让系统能更好的适应将来，通常做了过度的设计。而“智能机”则是一个从数据到模型的过程，它只需要一个初始化，之后就可以自己根据外界情况演化自身的模型，所以它初始化时是不需要“人”这个对象的，到后来系统“需要”时，再自动去抽象出“人”这个术语。
这样的东西当然是好东西，可是如何实现，这才是我关心的呀。o6z排斥你的观点，是因为他认为你所说的“智能机”不存在，如果你能坐下来谈谈如何实现的问题，也许大家才能讨论到一起来。

[ozzzzzz]

Panr(光荣)
我不觉得你是开玩笑，我觉得你还是不能明白SEI从来就不是一个学术和工程方面的权威。至少你可以看看图灵奖都是发给些什么人，他们的兴趣和SEI搞CMM的人的兴趣有什么不同。你可以看到面向对象社区的那些领袖都在搞什么，他们有几个对于SEI的过程有好感。

““遇到雇员和雇主自然就会先想到人”
这是值得进一步推敲的，直觉的确是很高级的思维方式，但是直觉很多时候都是错误／不准确的
雇员所代表的只是劳动力，比如在机器人技术进步以后，某些岗位上的雇员就被机器人代替了，这丝毫不影响信息系统的结构了过程。甚至应该说：把“人雇员”换成“机器人雇员”才是客户的目标
机器人是人么？”
这一段很有问题。人思维的方式是这样的，先假设一个结论，然后验证它，运行它（就如同你现在作的一样）。而不是先观察，然后综合，再结论。这是人思维的一种不变的定式，它让我们有限的思维计算能力可以保持关注在最重要的方面。它不是一种高级的思维方式，而是一种低级的基础的思维方式。所谓的神经网络的模式判断也是如此，它首先对于模式作评估，然后把实际的数据和模式作对比，知道找到最近似的模式。而不是如你所想象的那样，从统计中去搜集提纯模式。从一个长期的发展的角度来看，思维是不断的证明假设的过程，而不是一种不断提纯的过程。虽然假设是一种提纯，但是首先必须先假设才可以会去提纯。而假设则有各种策略，依靠原来已经证明的对象产生新的假设是一种最优的策略。而分析和解决问题的过程（也就是分析需求和设计程序的过程）必须符合人类的思维习惯。雇员和雇主这个问题就是一种先假设后证明再调整的过程，当雇主认为可以使用机器代替人的时候，分析者就会调整他的分析模型，也就是他最初的人类的模型。但是你不可能再最初就把模型一步到位的调整好，这还是一种瀑布的静态的思维方式。这似乎在你已经成为一种固有的思维习惯，总是想一步一次的永远解决一个问题，总算想一个模型应该可以解决一切问题，总是幻想超级武器的存在。你的一系列的帖子都再不断的重复这个东西。

关于面向对象还是面向术语的问题对于我来说自从我掌握了面向对象的技术，我就开始了面向术语的编程。但是我的面向术语和你的不同，我是关注于问题域的概念来建立architecture，但是以问题域中的对象来建立程序。我的面向术语是一种高层的，高抽象的，与程序实现和运行的结构无关，而只与程序的建造结构的元型有关一些实践。我不认为我可以单独的去实施面向术语的开发，我也不认为面向术语是一个比面向对象更高级的做法，它只是在一个更抽象的层次上弥补了面向对象的不足。可以这样说，面向术语给我提供了一个假设来源的库。而面向对象则是证实这些假设和管理这些假设的方法，面向术语是极端的依赖面向对象的一个附着物，以至于可以认为是一种寄生者，或者干脆就是面向对象的一个组成。你不可能单独的去实施面向术语，它必须有面向对象的基础才可以存活。
我们的分歧还在于，我不能同意以业务概念来建立组件从而构成一个architecture，以为业务概念是抽象的且多变的，不能满足于architecture对于稳定性的要求。这又是一次你显现你静态和瀑布思维方式的一个点，你总是想把变化固定下来。这也就是为什么会有architecture和framework的原因，可以说architecture是基础组织，framework是建立在它至上的骨架，程序是以framework为中心的生物体。
而问题进一步的发展你就犯了一个常识的错误，你不知不觉的走向了形式化语言的道路。任何人的交流都是问题，任何时候的交流都是问题，任何组织的交流也都是问题。即使使用相同的词汇系统，共同的认识方法，一样会有交流问题。因为人们要传递的不可能只是一些数学上的概念，而还有很多情感和经历以及感觉的东西。人往往是不能知道自己真正在表达什么，他们只是模糊的感觉到一定的东西，而如果过早的把这些东西具体化，则会使他的思维造成阻滞，且成本巨大。这也就是为什么文字虽然更加清晰和明确，但是商业谈判大多数在重要的场合还是不断的被认为是首先应该使用的手段。关于这方面的东西，你可以看一看Cockburn的《敏捷软件开发》，这本说很好的介绍了交流的问题。有了这本书你就可以不向我一样去请教心理学者讨论交流问题了，这里所带来的信息已经足够我们这些软件工程研究者用的了。说句题外话，看侯捷先生的http://www.csdn.net/news/newstopic/14/14619.shtml我深有感触。现在的书真的是太多了，如果当初我们能有这么多的书，我们可以减少多少失败啊。

其实关于术语你还没有考虑到一个方面，就是行话。这个东西不能是术语所能概况的，术语还是一个明确的概念，而行话则更多的是共同经验和类似经历的体现。比如我说你无知无畏，你就能明白我是在说我欣赏你的探索精神，这就是因为我们以前的共同经验，这就是我们两个人的行话。而如果我把无知无畏使用在另外的人，则一定是会有麻烦，因为我和别人没有建立这样的行话系统。而交流的效率就是体现在行话系统的建立，更多的使用行话会更加有效率，也更加不容易出现误解。因为行话代表了众多的背景和相关约束，它是我们交流的最佳词汇系统。但是行话的建立必须在共同的经验的基础上，而不可能建立在一个字典的基础上。这是因为行话所代表的背景和约束会随着经验的增加而不断的变化，从而带来行话自身的变化。所以团队的建设和交流的持续性才是最根本的，而依赖一个共同的词汇体系只是一种辅助的有益手段。但是共同词汇系统也有其弱点，首先词汇如果不是形式化的，则必然有外延的模糊性，也就是二义性。而如果是形式化的，则必定带来含义的匮乏，也就是你必须使用太多的词汇才可以说明一个简单的东西。

[Panr]

是有人问对这个问题如何建模，所以我才多说说。不是想把人蒙晕，呵呵

我也不认为使用已知技术可以实现“智能机”，这一点我和o6z是一样的，哈哈
关键是看到“智能机”和“协作机”之间的差别，这种差别是有实际作用的，从这里我们也可以发现很多人（其中不乏专家教授）过分地夸大了面对对象的实际作用

[Panr]

===== ozzzzzz(希望敏捷) at 04-01-09 13:59:00
我是关注于问题域的概念来建立architecture，但是以问题域中的对象来建立程序。我的面向术语是一种高层的，高抽象的，与程序实现和运行的结构无关
=====
“建立问题域”这个过程是讨论的的共识，还是个人的修养
我认为如果是个人修养的话不需要做学术讨论，也许有人更喜欢数学式的思考，数学形式化的正确性和完备性是一种共认的艺术



我现在去看看侯捷先生的东东吧

[Panr]

“社会养不起专业作家，是社会的耻辱。如果问题出在出版界，那就是出版界的耻辱。”
严重同意此句

也许接触广度太小的缘故，我的确认为SEI是软工方面的权威，可能有一点偏差的，好吧，先记下了，以后注意
过去的软工书的出版情况是不怎么样，高端市场的选题过于集中肯定是存在的，我也今后软工/系统分析类也将会成为高端市场的热点的
希望市场上能多接触好书，希望多接触一些高手的观点吧^_^



-----
忽然想到另外一个问题，“我的面向术语是一种高层的，高抽象的”，为什么反对“形式化”呢，这不是有一些“向着抽象化的方向跨出了第一步，就躺在这一进步上沾沾自喜不思上进了”，抽象化的极限要求就是“形式化”


“往往是不能知道自己真正在表达什么，他们只是模糊的感觉到一定的东西，而如果过早的把这些东西具体化，则会使他的思维造成阻滞”
同意的，这和你后面所说的“行话”应该是同一种问题，所以我不会“让客户先给出业务术语的定义，然后一条一条辩驳其可行性”（也是因为太伤面子了，虽然我觉得这才是最高效的做法），于是我不得不选择“通过反馈改进定义”
既然我选择了“通过反馈改进定义”以后，交流的代价就突显出来了

“面向术语”的进步之处在于项目内的参与者可以使用无歧义词汇交流，任何人不能（也不再需要）修改别人的措辞，而“修改别人的措辞”总意味着附加自己的想法
在客户提出一个想法后这个想法可以把原文转达和登记，而且所有的项目组成员都能理解，就是“面向术语”的最大进步


-----
就像炼丹中，我还是先建立“还元”一个业务术语，为它定义为对“本尊对象”的一个包装，包含两个属性‘操作强度和返神量之间的关系’、‘还气量和返神量之间的关系’。我不会过多关心“迫使‘神’返归到本尊的身体内”这个语义
这显然是个初级定义，然后道士试用过软件以后可以提改进意见的，比如道士可能提出增加一个“时辰”属性

抽象数据类型也是可以进化的，对吧

[ozzzzzz]

Panr(光荣)
其实我已经提出了一个新的概念，行话在交流中的核心地位。
为什么我会否认你对于面向术语的观点呢？其实很简单，在我看来面向术语和面向对象根本就是同一个问题。我们在观察问题的时候，总是会有一个具体到抽象的过程，也就是从对象到术语的过程。如果我们只是停留在对象的范围内，我们也不会真正的理解问题。但是术语是极端依赖对象的，就好像概念极端依赖其实在一样。我们并不是因为有了概念才去选择对象，而是因为有了对象采取总结概念。所谓面向对象的分析方法就是一种从具体的对象中提纯概念的方法，而我们要作的是围绕概念组织对象。但是概念必须是建立在现有对象的基础上，而不是建立在未知的对象的基础上。稳定是一种动态的稳定，而不是恒定的静态。你不可能实现一种真正的基于术语的方法，使术语围绕术语的方法组织抽象的抽象。过于追求抽象的层次会让你的抽象过于细碎而不易于理解和掌握，而且寻找他们之间的联系也会更加复杂和困难。我们使用一种方法和工具是为了我们更好的更容易的工作而不是相反。
而你会发现我的行话的概念是和你的术语的概念那么不同，你的术语属于一个人，而我的行话属于两个人共同的经验。请仔细体会这个地方的不同，就会发现为什么我会强调交流的成本依赖于交流者之间共同经验的多少。交流是一个双向的活动，不能只考虑听和被听单方面的权利。你应该把交流放在一个环境中，而不是一个抽象的理想状态中。而你对于术语的理解也很有问题，“任何人不能（也不再需要）修改别人的措辞”其实就是说任何人也不能修改自己的措词，也等于任何人都不可能理解别人和自己的措词。我们要传递的信息，不可能是100％要传递的信息，这是受我们语言和环境以及时间的影响。而我们传递信息的方式也很受接受信息的一方的影响，他如果不能修改我们的措词，他就不可能把我们的信息转化为他的词汇系统中的信息，你也就不可能得到他的反馈。而反馈也是一种传递的信息，我们也可能理解他的信息。而我们对于任何事物的认识都是来自外界的信息，由于你不能修改外界的信息而只能全部的接受，则你就不能把这些信息条理化和个性化，不能让它成为自己的一种体验，所以你也不可能理解外界。而信息必然会随着时间个失真，于是你也不可能真的理解自己的信息。越是你就和信息产生了不可调和的分离，信息也就成为漂流在你意识之外的一些碎片（当然这个时候你也就不可能有意识了）。
而形式化语言为什么不能在多少环境下不可能比自然语言更加有利于信息的传递，其实已经是一个有答案的问题，我只是提示几点。首先人所要传递的信息，不可能被人全部的理解和把握。信息还有多样性，不可能会存在一种形式化方法可以表达所有类型的信息。形式化的方法都是极度依赖数学符号的方法，其和人类的思维习惯和表达方式差距太远，不利于掌握。形式化方法高度具体，表达抽象的概念会很困难（喜欢、好奇这些情感都不可能被形式化的方式传递）。而最重要的是软件开发还是一种工程，不可能因为一个项目产生一个形式化的语言，然后在另外的工程再去使用另外的形式化语言，这是成本的问题。实际上从这么多年来形式化语言的发展你也可以看到为什么总是一种停滞的状态看到其发展的乏力。特别是现有的Z.B等语言一样不可能真正的无二意的表达，更因为大多数时候人类更喜欢使用二意的方法表达自己的信息。所谓话里有话，回味无穷。

[Chuanyan]

如果应用"术语",当道士提出增加一个“时辰”属性之后,抽象数据类型进化了,那么,它对使用面向对象的实现过程有怎么样的帮助呢?它比应用"面对对象"做出来的需求有什么优越性呢?

假如是为某间业务高速发展的公司做营业系统,这个系统下要求一个权限结构:省->市->区.某
个营业员可能只有某省里面某市中某一个区的操作权限,但对应这个区的这个省这个市的权限就不能为NO了.为了实现这权限就要把权限的粒度细分到区上.
那么一个拥有全国权限的人就是一个拥有所有区的权限的人.那么后台的程序就要实现 Select * from AAA where 权限 in (A区,B区,C区,D区,.....).但是事实上这完全可以直接Hardcode Select * from AAA 就行了.但是就怕会出现一种情况:"拥有除了北京以外的全国权限"....
在这个公司高速发展之下,他又提出了在区之下增加点,即:省->市->区->点.继续使用原来的那一套程序结构,发现varchar2(4000)的字段不够用了......想整改一下结构,无奈这个公司已经应用这个很久了,于是,大量的Hardcode来了......

我没兴趣去研究形式化语言的问题.本身CODE就是形式化的,任何需求都是为最终变成形式化的CODE服务的.做需求的不去Make sure一些事情的话,这些事情就得由CODER去做.

是否可以应用一些高层次理论去使实现更方便?使用"术语"可以把一些在实现阶段才能MAKE SURE的东西提升到需求阶段来MAKE SURE吗?哪怕是能让人了解到哪些地方HARDCODE比较爽一点也好.我需要的是可以提高生产力的东西.

[FrameSniper]

很少来这个版块，学习学习，先找个切入点

[Panr]

ozzzzzz(希望敏捷)：
我没有搞错意思，嘻嘻，我只是开玩笑啦

“遇到雇员和雇主自然就会先想到人”
这是值得进一步推敲的，直觉的确是很高级的思维方式，但是直觉很多时候都是错误／不准确的
雇员所代表的只是劳动力，比如在机器人技术进步以后，某些岗位上的雇员就被机器人代替了，这丝毫不影响信息系统的结构了过程。甚至应该说：把“人雇员”换成“机器人雇员”才是客户的目标
机器人是人么？


“人面向对象就是面向术语？”
这个问题提得太好了，其实这才是我们的根本分歧所在。我所想表达的观点包括：
１.在一个关于应用性软件的软件工程中，理想化的的情况是，以业务概念为基本组件进行需求分析和软件设计等操作
２.在当前的软件工业的现状中，不是所有的业务概念都直接被体现在软件设计（注意是我是说软件设计而不是源代码的组织，软件设计是的目标是同时满足所有需求）中的，业务概念是通过抽象数据类型的形式出现在软件设计中

对于第１点，虽然“面向术语”这样的措辞有些非议，我看了您的讨论，认为我们之间在应用性软件的具体操作上没有什么不同的，您看我这样说对么
第２点上我们的做法则完全不同

我们只有在学习了汽车解刨结构以后才能理解汽车的故障，才会修理汽车。如果我只是告诉你“汽车启动不了”，你是无法开始动手维修的。这种情况是由于两者涉及的术语系统是略微不同的
使用中的术语包括，车门、点火、方向盘、油门刹车...
设计中的术语包括，发动机、传动轴、底盘、车体、防盗系统...

同样我认为软件过程中最大的问题也是来自于交流障碍，“面向术语”的进步之处在于项目内的参与者可以使用无歧义词汇交流，任何人不能（也不再需要）修改别人的措辞，而“修改别人的措辞”总意味着附加自己的想法
在客户提出一个想法后这个想法可以把原文转达和登记，而且所有的项目组成员都能理解，就是“面向术语”的最大进步

如果“面向对象”中的“所有的／任意的业务概念”并不可能贯穿于整个软件工程（我指的是设计环节），那么我们就不应该把“所有的／任意的业务概念”作为项目组内的通用词汇，需要对业务概念进行筛选（或转化为其它形式）
而我的总论是：现阶段，只有“抽象数据类型”可以作为通用词汇







Chuanyan(负资产过年)：
既然你这样提问炼金的问题，我也拿它举个例子吧
在不考虑修辞的前提下，我们可以发现“还元”即使一个术语
在术语的阶段中，“还元”就是指“迫使‘神’返归到本尊的身体内”的操作，不需要更多说明
在抽象数据类型的阶段中，它表现为许多的属性的集合。包括了“操作强度和返神量之间的关系”、“还气量和返神量之间的关系”（此时的“还元”是对“本尊对象”的一个包装，在指定了本尊对象后“还元”类就可以准确地给出上述两种关系）


---
“面对对象”中的对象是“术语概念”这个观点不是我的观点，是“面对对象”理论中公认的观点，我不是提出
我的不同之处在于：提出了三个阶段的划分。比如o6z提出的“是不是人面向对象就是面向术语？”这种提法就是很中肯的


“列举大量而又详细的实例来说明”？
是个好建议！恐怕这几天我是办不到的，因为明天我就要请假回老家，年后才回
这几天肯定还会来看看，但是可能抽不出多少时间写回帖了:)



多谢大家的关注

[Panr]

以业务概念为中心，还是以业务数据为中心？
再看以业务数据为中心，毫无疑问，在整理业务数据的过程中必然先处理业务概念，但是，贯穿整个软件过程的文档的组织线索只会一个－－还是业务数据

所以，“人面向对象”不“面向术语”

[Panr]

发现大家对“形式化”的非议颇多，我也来谈谈我的想法：
我认为学科知识的发展包含四个阶段，经验、分析、建模、统一。分别对应于感性认识、定性认识、定量认识、完备认识

数学的特点在于准确性和完备性，当一门学科理论开始运用数学的时候，它是已经开始了“建模”的阶段，为到达最后的“统一”阶段做好了准备，然后，数学又护送学科理论进入到最后的统一阶段
当开始运用数学的时候，就是学科理论开始升华的时候，当数学运用到极致的时候，就是学科理论获得永生的时候！所以，我们说数学是最美丽的

认识的准确性和完备性就是数学之美


你还是没有把“设计程序”中的设计和程序区别对待，没有把那个“操作”和“操作的对象”区分开来
动词和动词的宾语肯定是两个不同的东西，对这个宾语的描述也可以用准确性和完备性的标准；对于动词我们则是要求越方便越好
我所说的形式化是软件的形式化而不是设计的自动化，是软件自动机的数学化而不是交际语言的形式化，数学是美，形式语言是酷，真正能让人感动的是美丽，自己随便摆出个造型扮酷只能吸引眼球而不是吸引心灵


> 学校中的学科的设置上常常
> 把自动机而和形式语言放在一起
> 应该说形式语言是自动机的一种扩展
> 自动机的数学化是语言形式化的一个子类型



ozzzzzz(希望敏捷)：
“我的行话属于两个人共同的经验。”“大多数时候人类更喜欢使用二意的方法表达自己的信息”
有理，应该为这两句话鼓掌！的确，参与者间的默契是有效交流的前提
那我把“任何人不能（也不再需要）修改别人的措辞”改成“其它人不能（也不再需要）修改别人的措辞”吧，我这样提法是因为，有些话‘从客户的嘴里说出来’还是‘从程序员的嘴里说出来’我要附加上去的理解是完全不一样的

另外，为什么不把“行话”作为备选的“业务术语”呢？


Chuanyan(负资产过年)：
“除了北京以外...”
这已经不是系统分析的范畴了，建议你看看自动机中关于“问题的提问的形式”（应该是这个词）的讨论





我要回家去过年了^_^
在这里祝福每一个看帖人猴年活蹦乱跳，新春纳福，来年吉祥，喜事不断，笑口常开...

[Chuanyan]

系统分析究竟为了什么？唉……
可以回家真好，我还要干到年初一……

[ozzzzzz]

Panr(光荣)
我非常好的把设计程序和程序作了区分，所以我强调程序是形式化的，但是设计还是不能完全形式化的。而程序的形式化也要求你不可能去面向术语，这样程序就不能做到清晰而无二意。实际上你混淆了programming和program的界限了。
我们所要面对的不是一个静态环境，我们所产生的学科也不是都最后能形式化的表达。音乐、哲学、社会学、写作、绘画、建筑等等非纯理论性的东西都不可能到达统一的认识，也不可能被形式化解决。这些工作的主题是人，人是非线性的，不可捉摸的，不能形式化的。这些你也是同意的。
但是你说的程序的形式化其实已经成为了一种程序和设计的形式化。你强调返回的句柄不仅要可以概念其状态，还可以可以改变其类型。这显然是说你要程序实现设计的一些功能，由运行时决定一些设计时的问题。而后面你更加显示了你是在说设计形式化的问题，你说术语的无二意，不可修改，这些都只能是针对设计时的。而更加明确的是你一再强调智能机，实际上智能机肯定不是一个单纯的程序，它是一个设计程序的程序，即有程序的属性也有设计的属性。
这个问题其实很不是很重要，重要的是你不能理解为什么行话不能成为备选的业务术语。其实我上次已经解释过了，但是现在再次强调一下。行话是建立在共同的经验和经历基础上的，它代表的不是单纯的概念，还有非常多的背景和遐想。而且行话会随着对于行话的使用而增加更多的经验和经历，其内涵会更加丰富。我们使用行话可以很好的表达我们要说明的问题，关键就是我们要有共同或者相近的经验和经历。还是那个例子，我不断的说你无知无畏，但是你知道我不是在骂你，而是在欣赏你的探索精神，因为这些是我们已经达成共识的一个你我的行话。但是如果我把无知无畏用到别人头上，他们势必就认为我是在骂人。而行话要成为术语，则必然对其内核和外延作出严格的界定，这显然是把行话这个活的概念给僵死了。而如果术语和行话同时是一个词汇的属性，那么识别到底是行话和术语就会更加困难。
为什么我多次强调稳定的团队重要，就是因为稳定的团队已经有了一个成熟的行话系统，在这个系统中交流二义性和效率都很好的得到了解决。而交流可以促进行话的产生和成熟，所有交流也可以通过行话变得更加容易。术语肯定来源于行话，但是它只能是行话中很小的一个部分，或者说是行话中失去活动性的部分。

[JCC0128]

顶

[奔跑吧猴哥]

为什么么程序员难找老婆？
那是因为没有学好“面向对象”！！！
搞对象的时候当然要面对面交流（面向对象），背对着对象怎么搞得好？

[w_rose]

是的是的，搞对象的时候一定要面对面交流！

已经这么清楚地研究软件的对象和其运动机制了，基本的形式化已经是基本的语言，融入人的神经里面了。其实最基本的东西是最不应该被轻易当作神灵的东西。这样，我们还能保留有充分交流的自由空间（除非神灵确实存在）。

就好像我们的语言，如果说研究我们的社会问题的结果得到：我们必须改变我们的母语，那么一定很令人震惊。一方面，过去很多其实已经研究的很充足，今天怎么又认为大家都不知道了他的内涵了呢？其实，对于原本简单的东西，应该直接说出：像要改进到什么样子来，也就是直接说出结果来，口号是没有人相信的。

语言的问题、人工智能的问题、哲学的问题，不是仅凭口号就能成为“未来科学”的，它已经被反反复复提及好多年了。

[w_rose]

另一方面，如果程序员都能成为一位逻辑专家（不是指数理逻辑，是指比较自然的一阶逻辑等），并且能够自己开发一个逻辑基本形式解决软件设计和编程问题的系统，那么对于一切编程技术领域：OO、结构化、信息系统、编译等等，都是有好处的。但是并不是说它应该取代现在的设计技术。人设计的机器可以杀死所有的人，但是人的设计天分没有什么机器能够代替。