构架思考--我们为什么需要构架

walkcamel 2003-08-23 10:55:17
在一个典型的系统的开发过程中,首先是客户提出需求,设计人员根据需求进行分析和设计,程序员根据设计进行编程,最后是系统的测试和系统的分发。在整个软件过程中,参与到系统的角色各不相同,各种角色之间的关系是既合作又敌对的。系统的客户总希望花更少的前,获取更多的功能。开发公司则相反。开发人员讨厌无停止的改动,客户则认为开发出来的东西总是不满足自己的要求。在开发的过程总需要一个能够折中体现参与到系统的不同角色的不同要求。一套详细的设计说明?如果时间和金钱上允许的话,也许可以这么做,而且客户也许会没有耐心和你讨论关于函数接口的问题。或者是什么都不做,加快时间把系统做出来再讨论。实践证明了此路不通。我们需要的模糊和过分的详细之间找到一个平衡点。我们把它称之为构架。构架体现了不同风险承担者的要求的综合,借助于构架,设计师就可以分析众多风险承担者所提出的各种要求的优先级别,并且将这些要求转化为系统的各个特性,针对这些的特性,系统要在结构上做一些的妥协。
在上面我们提到系统特性,在《软件系统和软件构架》中也提到两个概念,原则(principle)和质量属性(Quality attributes)。这三个是相互关联的概念,
我个人认为系统特性是质量属性的具体的体现。软件的质量属性是指软件的性能,安全性,可用性,功能性和使用性等。系统的具体的某个需求大多数可以归纳为某个种
类的质量属性。在SEI的Architecture Tradeoff Analysis (ATA)中就讨论了如何将系统的需求归纳整理为不同的质量属性。原则在某种程度上等同于质量属性,比如说某套系统的开发过程中的技术原则是要能实现互操作性,在质量属性中也有类似的概念。基本上来说原则更为工程化一些,也就是在不同的系统中,你可以制定不同的原则。而质量属性相对更为抽象一些。在SEI方面的软件构架文章中,我们常看到的是质量属性,而在IEEE 1470-2000以及TOGAF8中,都是用原则(principle)来表示。无论是质量属性还是原则,都是作为评审软件构架的标准。在以后的文章中,我们就统一采用质量属性这个称呼。
由于构架综合体现了不同的风险承当者的要求,不同的风险承当的所关心的问题肯定是不一样的,所以在进行构架描述的时候,我们需要从多角度的来进行描述。就象建筑设计中一样,把所有的东西,比如外观设计,受力设计,水电设计等都放到一起肯定是不可行的,但这些分开的设计也不是都毫不相干的,它们之间既相对的独立,又相互联系,形成对一座建筑的完整的描述,不同的参与人员只关心他们要关系的时间,如结构工程师关注受力设计,水电工程师关注水电设计,建筑设计师负责整体统筹规划。在软件构架设计中也是一样,通过多个相对的独立又相互联系的视图来对构家架进行一个完整的描述,关于构架描述的权威性论述是IEEE 1470-2000,在SEI的《软件构架实践》中用软件结构来表示类似于构架视图的概念。"Architectureal blueprints- the 4+1 view model of
software architecture"提出了一个被广为使用的构架描述的模型,RUP过程的构架描述模板和HP公司的软件描述模板都和这个有莫大的渊源。也正是因为通过多个不同的角度来描述说明构架。不同的风险承担者可以通过构架进行交流,并且找到解决方案。基本上来说,构架的重要性可以被归纳为以下三点:(1)构架是风险承担者进行交流的手段。(2)构架是早期决策的体现。(3)构架是可传递,可重用的模型。具体的说明参见《软件构架实践》中的‘什么是软件构架’一章。由于构架如此的重要,在RUP过程中更是明确的说明整个的设计过程是以用例为驱动,以构架为核心的。
...全文
119 36 打赏 收藏 转发到动态 举报
写回复
用AI写文章
36 条回复
切换为时间正序
请发表友善的回复…
发表回复
gmc007 2003-08-30
  • 打赏
  • 举报
回复
晕了,今天尽是碰到一些长贴。

不过,好像都不错。

有空再看吧:)
Panr 2003-08-30
  • 打赏
  • 举报
回复
我认为构架应该从一个“计算数学”的“自动机”的角度来理解,这个自动机被要求能满足所有的需求

在“基于对象”的阶段,“自动机”指的就是全部协作图的集合
我对“什么是构架”的答案是明显带“基于对象”色彩的
我和你在“什么是构架”这个问题上没有达成共识,那么讨论构架的作用(以及如何设计构架)基本上也无法达成什么共识的





既然你问到了“类型数据”“实例数据”的关系,我再多说几句

“类型数据”和“实例数据”不是同一个概念。“类型数据”源于传统的推理逻辑学中的“语义学悖论”
“语义学悖论”的典型例子是“请指出以下命题的正确性:‘这句话是对的’”

“语义学悖论”指出推理逻辑的局限性,“当命题的语义是描述(或等价于描述)命题自身的时侯,推理逻辑将不在适用”
在逻辑学上对此的解释是:可以对术语系统进行再抽象,再抽象得到的术语将是独立于原术语系统的新的体系,推理逻辑只能在每个术语体系内部使用

可以称“实例数据”是一次抽象的术语系统,那么“类型数据”将是对“实例数据”的再抽象后获得的术语系统(二次抽象的术语系统)
在研究“类型数据”的语义时,我们将需要更高次抽象的术语系统(三次、四次...)


面对对象比基于对象的进步就在于:面对对象宣称它是利用语义进行设计
那么面对对象有义务研究高次抽象的术语系统的特性,而基于对象只是运用推理逻辑来研究客观世界特性






“类型数据”和“实例数据”的区别在于“语义的逻辑学意义”
面对对象是以“实例数据”研究客观世界的特性/命题;以“类型数据”研究实例数据的特性/命题

> “类型数据”,如果有,可以把它简单地认为它是“实例数据”
好的对象编程中应用代码根本接触不到“类型数据”,这句话是可以被忽略的
如果程序中接触到“类型数据”了,你可以把它理解为构造函数的模板参数,这是类型数据的唯一用途(我们在没有抽象机制的条件下是无法用类型数据来研究实例数据的特性),这时的“类型数据”和“实例数据”又有什么区别呢

> 而“什么时候能研究出结果”只是个技术问题
你现在就在冯·诺伊曼机器上写OOP,怎么解释?

> “‘基于对象’明确地承认自己暂不研究‘抽象化’理论”
然后我想问问,如果面对对象的‘抽象化’理论也只存在于人脑中,那么它与基于对象的区别在那里。既然你倦了,那就算了
fita 2003-08-29
  • 打赏
  • 举报
回复
To Panr(光荣):
对于抽象化,我的观点是抽象一定是建立在经验上的,知识也是从经验总结得来的,我认为没有一定的抽象化理论,要能抽象得好,一定要经验丰富。类-对象方法未能告诉我们How的问题,过程方法也同样未能。
人脑进行抽象一直都是依靠经验的,在经验的基础上,一种方法是对实例大量的分析比较,找出共同点和不同点,并进行归纳,还有一种方法是从别人的经验中学习,让有经验的人告诉你。要能够分辨出两只蟑螂,一种方法是自己养,通过观察大量的蟑螂,从中发现蟑螂的共同点和不同点,从而总结出能够分辨蟑螂的经验。还有一种方法是向专家学习,让他告诉你如何才能分辨出两只蟑螂来,这个专家一定也自己观察过大量的蟑螂。由于都是从经验得来的,所以抽象也可能由于经验不足而不准确,也可能存在某个实例不符合抽象经验的情况。

我们在做系统分析时也是如此,一种方法是进行实例的研究,通过观察实例对象的运作,从中总结出经验来,有了经验,就可以在知识领域定义类,这种方法通常都很花时间;另一种方法是向业务专家学习,从业务专家的经验中可以直接定义出类,这种方法时间较短,但不太可靠,需要实际的验证。我们通常会两种方法结合采用
因此,系统分析中从对象入手和从类入手两种方法都是可以采用的,它们的基础都是实际的经验。

类-对象理论是基于这样得经验:数据少变而过程多变,因此类-对象理论要求我们先看数据,再看数据之上的操作过程。而过程理论则让我们先看过程,再看过程操作的数据。也就是说过程理论建立在过程少变而数据多变的经验上。现实世界中两种情况都有,我们要做的是首先识别现实世界的具体情况,再用相应的方法去实现它。建立软件的架构其实就是首先识别变化少的部分建立起基本框架,再把变化多的部分进行隔离,我们不应局限于某一种方法,而是寻找一种合适的方法,只要能够尽快达到我们的目的,就是好的方法。
zhuma 2003-08-29
  • 打赏
  • 举报
回复
To Panr(光荣):

“实例数据”到“实例数据”的变化,即协作图(消息)。
难道不是状态图?

是不是
“类-对象”和“类型数据—实例对象”的
根本区别就是如何对待“抽象化”?
walkcamel 2003-08-29
  • 打赏
  • 举报
回复
突然间又想起来一点,关于抽象化长久没有进步,我想是不是这个问题大家是不是觉的没有研究的必要,才没人去做,所以就没什么进步了。:-),(开个玩笑)。
walkcamel 2003-08-29
  • 打赏
  • 举报
回复
呵呵,黑猩猩是不是人呢,也是公说公有理,婆说婆有理。关于“是”或者“不是”的问题也就此停了吧,毕竟不是做理论研究的。更多的讨论些“how to”方面的问题吧。
walkcamel 2003-08-29
  • 打赏
  • 举报
回复
如果DNA能构造出抽象的机制,半导体也一定可以
> 而“什么时候能研究出结果”只是个技术问题

我不这么认为,除非不再是基于目前图灵机的计算体系模式,而出现生物计算机或者量子计算机,否则不可能出现象人一样的人工智能,而是人参与的人工智能。

>当前的计算机软件是通过‘协作图’的特性满足需求,而不是通过‘协作图+实例化+抽象化+继承’的特性满足需求。

我希望你能够就这方面做进一步的解释,是不是我们不用协做图,我们就做不出满足需求的软件呢。
在只用机器码的年代一样有软件产生,那时候可是连抽象数据类型都没有的。
按你前面的描述,是不是每个对象实例都要要自己的协作图呢,但它们的操作过程一样,而操作数据是不一样的,如果不是,那是用什么来表示呢,类?抽象对象? 还是别的什么呢?我非常希望你能够以你的经验就这个问题回答我。

另外,你说的抽象化是种理论还是种方法,是不是一定要全部用形式化东西表示出来才能算严谨,在如何进行抽象化的方面,很多前人给出很有价值的经验,至于形式化,我只能说很抱歉,如果你能用数学表示这个世界的时候,也许这种水平能够达到你的定义要求。

>注意这个说法,在这种说法下“类型数据”“继承”“抽象化”三个概念的作用在软件分析中没有一丁点的体现.
我再次声明,没有用计算机工具并不代表我们不能做分析,也不能代表没有用这个方法。不错形式化是有助有工具的开发,可在软件过程中更多的是形式化的东西,就算是在面向过程,或者是ADT的分析方法中,又有多少是不要由人工参与的呢。


>对于“类型数据”,如果有,可以把它简单地认为它是“实例数据”
为什么? 你会认为这两个是同一概念?
rtdb 2003-08-29
  • 打赏
  • 举报
回复
晕! 原来自以为OOA,OOD已经用了多年,很熟练了,
什么封装,继承,多态, 设计模式均有心得,
让你们一说, 我倒糊涂了。

不好意思的问, 诸位多是学校的老师什么的吧?
Panr 2003-08-29
  • 打赏
  • 举报
回复
我已经看到大家都认同:
在对象理论中的确具有“抽象化”的步骤
无论这个步骤是在人脑内还是电脑内进行,这个步骤是确实必须存在的!



--------------------
先重复一下我前面的“对象理论概述”
//1 理论的学术研究要做的事是
a.建立自己的术语概念
b.研究概念的特性
c.研究概念之间的关系

//2 对象理论的基本概念至少必须包括“类型数据”和“实例数据”两个概念
它们间的关系至少必须包括:
“实例数据”对其它“实例数据”的作用,即协作图(消息)
“类型数据”对其它“实例数据”的作用,即实例化
“实例数据”对其它“类型数据”的作用,即抽象化
“类型数据”对其它“类型数据”的作用,即继承
所以完整地研究对象理论也需要涵盖“协作图”“实例化”“抽象化”“继承”的研究

//3 对象理论包括两个阶段
基于对象,其外延至少包括以下术语:“实例数据”“协作图”“实例化”
面对对象,其外延至少包括以下术语:“实例数据”“协作图”“实例化”“类型数据”“继承”“抽象化”

通俗地说基于对象只研究“实例数据”,面对对象同时研究“类型数据”和“实例数据”
(那么称基于对象为“ADT”理论,称面对对象为“类-对象”理论,应该还是中肯的。好吧我以后改称“基于对象”和“面对对象”)


> 要不要建立严谨的抽象化理论?
> 既然对象理论具有这个步骤,我觉得就要研究
> 留在人脑中是自发,能用电脑重演叫做自觉,这是一个政治问题
> 技术上说
> 我有学习能力是由于大脑皮层中有抽象的机制
> 如果DNA能构造出抽象的机制,半导体也一定可以
> 而“什么时候能研究出结果”只是个技术问题



--------------------
当前对象理论的使用水平
//1 我前面写错了,应该是这两句:
a.软件分析方法的目标是,分析需求书设计协作图
b.对协作图的唯一要求是,满足所有需求

我希望您考虑这样一个事实,
当前的计算机软件是通过‘协作图’的特性满足需求,而不是通过‘协作图+实例化+抽象化+继承’的特性满足需求

我这样认为的原因是以下这个现状:
现在我们只能使用这样的算法
“先有类型数据,然后看实例数据是否是属于这个类型数据”
而不是这样的算法
“没有类型数据,要求从实例数据归纳新建出合理的类型数据”


//2 我们的对象理论的运用只达到“基于对象”的水平
我说:“协作图”就是分析设计工作的目标
注意这个说法,在这种说法下“类型数据”“继承”“抽象化”三个概念的作用在软件分析中没有一丁点的体现

“抽象化”长久没有进步以后,“面对对象”只剩下“类型数据”“实例数据”“协作图”“实例化”“继承”五个术语了

“当前的计算机软件是通过‘协作图’满足需求”
既然类层次与需求是无关,在研究“如何满足需求”的时候,“继承”这个术语是可以被忽略的

对于“类型数据”,如果有,可以把它简单地认为它是“实例数据”
在这种简单化中,第一类“实例化”的过程是指数据对象的构造,ADT中的构造函数是有歧义的,我以一个不同的“实例数据”来作为构造

函数的参数也是合理的,这样“实例化”这个术语也是可以忽略的


[这种说法,当前]
[这在根本上是由于“抽象化”的研究不够深入造成现状的]


> 在没有严谨的抽象化理论前
> “类型数据”完全可以毫无损失地完全消失
> “继承”在代码重用和与客户交流方面还有一定的意义

> 协作图就是分析设计工作的目标也就意味着
> 对象理论只达到“基于对象”的应用水平
> 而不是“面对对象”的应用水平
> 应用水平的关键性制约是
> 抽象化是依靠丰富的经验,还是严谨的理论
> 其实在“基于对象”中也必然地包含“人脑内的抽象化”
> 而“基于对象”更是明确地承认自己暂不研究“抽象化”理论




to fita(天外飞仙):
的确是有难度,我觉得研究抽象化理论是需要一些勇气
您说呢

to zhuma(竹马):
原来写得不太确切,你再看看
和“类-对象”对应的是“ADT”,两者的根本区别是:是否研究类型数据

to walkcamel(虫子):
可是...
就是认识到抽象化的全部是由人来完成的,我才认为现在没有“面对对象”,只有“基于对象”
Panr 2003-08-29
  • 打赏
  • 举报
回复
分辨“鸽子”不行嘛,干嘛要分辨“蟑螂”?
Panr 2003-08-29
  • 打赏
  • 举报
回复
to zhuma(竹马) ( ):
你不理解可能是因为你在软件工程中学习“类-对象”,如果你去看专门的“类-对象”的文章,就知道我在说的是什么了
“类-对象”是一套学术研究总结出的理论,软件工程只是在运用这个理论中的基本结论。换句话说:“类-对象”理论是独立于软件工程的

理论的学术研究要做的事是
1.建立自己的术语概念
2.研究概念的特性
3.研究概念之间的关系



“类-对象”的基本概念至少必须包括“类型数据”和“实例数据”两个概念
它们间的关系至少必须包括:
“实例数据”到“实例数据”的变化,即协作图(消息)
“类型数据”到“实例数据”的变化,即实例化
“实例数据”到“类型数据”的变化,即抽象化
“类型数据”到“类型数据”的变化,即继承
所以完整的“类-对象”研究也需要涵盖“协作图”“实例化”“抽象化”“继承”

当前的研究成果集中于协作图、实例化、继承三个方面。在抽象化上没有实质性进步
现在我们只能使用这样的算法
“先有类型数据,然后看实例数据是否是属于这个类型数据”
而不是这样的算法
“没有类型数据,要求从实例数据归纳新建出合理的类型数据”



我认为“ADT”是“类-对象”概念中的一个子集,它只研究实例对象的特性,而“类-对象”则同时研究实例对象和类型数据
抽象化研究的迟缓导致类的特性的研究并不透彻,继承的作用也就是在方便交流和代码重用

在当前这种算法模式中,你可以在承诺不使用继承以后,再把类型数据理解为一种新的实例对象
那么“类-对象”就退化为典型的“ADT”了




to walkcamel(虫子):
开个玩笑,勿在意啦



你认为下面两句话对不对:
“软件方法是为了分析业务逻辑,构架协作图为目标的”
“架构中的需求是依靠实例数据的协作实现的”
注意:如果答案是“对”的话,你已经在软件方法中排除了“类-对象”分析法
如果不对的话,请指出错误

如果“架构中的需求是依靠实例数据的协作实现的”的话(架构中不会涉及类型数据的话)
我的观点是在分析业务逻辑的阶段,暂不考虑继承有利于专注地
代码重用应该在完成架构设计后,指定开发计划时考虑



你认为在软件方法有没有“抽象化”的阶段,请用“有”或“没有”回答
我认为必然有,只是我们得依靠人脑进行抽象化(我甚至还认为,规范的需求书中大部分的条款都会用实例对象来提要求,越规范越少使用类型数据)

更准确地说是“类-对象”向我们提出了抽象的要求,却未指导我们该如何做(而我认为HOW 才是它应该研究的东西),所有的一切都是经验
作为一种理论不可要求操作者有丰富的经验,因为有经验的话不用理论也可以成功
我以为现在的“类-对象”理论是一个诡辩




to fita(天外飞仙):
你好
是的,我见过有人把类型数据理解为实例数据的定义空间,把名字空间理解为类型数据的定义空间
(名字空间应该就是对应于编译原理中问题域)



我不介意它错一两次,我说“如果正确率达到可以接受的比例”,如果你拿来两个双胞胎的照相我自己可能也分不出 :)
我能分辨人是因为我知道每个人的五官、脸型、体型等属性是不一样的,不能分辨蟑螂是因为它们不一样的属性不是脸型,如果我养殖蟑螂的话也许在半年后我能告诉你怎么分辨蟑螂

但我一生下来时并不知道要看“五官、脸型、体型等属性”,好象父母老师也没这样教导我过
而我现在知道了!因为我有概括能力,有概括能力就有学习能力。概括能力是抽象能力的一种,我要得就是抽象能力
我是个唯物主义者,....



我学习面向过程的组织结构的时候,可不是把“代码和数据分离”作为它的基本特征来看待。感觉您这种提法就是带歧视性的
在学习“面向过程”中感觉最深的ANSI C 92标准文献中的“顺序点”的概念,你用过断点调试么,这就是“顺序点”
你能不用断点调试么?!
walkcamel 2003-08-29
  • 打赏
  • 举报
回复
fita(天外飞仙):
类-对象理论要求我们先看数据,再看数据之上的操作过程
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

这个是基于面向数据的思想吧。
walkcamel 2003-08-29
  • 打赏
  • 举报
回复
Panr(光荣):
"软件方法是为了分析业务逻辑,构架协作图为目标的" 这句话我不敢全认同,分析业务逻辑是出发点,但同时分析的还有很多非业务的要求,这是其一。协作图是要表术的成果之一,这是表述动态不份的,但不是全部,还有包括类的静态结构图等。还有重要的一点,没有任何地方说明“类-对象”分析是要全部由计算机来进行的,或者说是全程数据话的,抽象化的操作就是由人来完成的,这点你也承认,但这只是个任务角色的分配问题,并不代表我在软件方法中就没有用到“类-对象”理论(实际上我从来不用这个称呼的),或者称做面向对象方法吧,甚至我不是面向计算机的时候,我用这中想法来分析问题,我一样会这么称呼我所的方法。
另外你关于经验和理论的看法,我想你看以去看马哲中关于感性知识和理性知识的辨证讨论,我个人认为唯物主义辨证法是一门极其有用的哲学思想,虽然考试的时候我都很讨厌它。而且在你关于学术理论中要做的事情的定义中没有任何一条是关于“how to”,是吧。
我甚至还认为,规范的需求书中大部分的条款都会用实例对象来提要求,越规范越少使用类型数据。这点我表示某中程度的同样,我们应该用场景来描述用户需求。但未必都是实例对象,很多的时候业务规则处理的就是抽象对象,因为实例对象在这里的意义不大。但有的地方必须用,因为更能表达的要表达意思。事实上我们在处理信息的时候总是在不同程度上的进行着一些抽象的操做,这点上你必须承认,抽象的目的是用来减低复杂度的。不是吗?

fita 2003-08-28
  • 打赏
  • 举报
回复
对于面向对象和面向过程方法,我也想说几句:
过去面向过程的分析方法,以及面向过程语言占主导,我想这是计算机的硬件架构决定的,计算机的硬件架构中CPU与存储是分开的,而且由CPU来负责指挥整个计算机的运行,所以在计算机底层结构决定了一定是面向过程的方式,软件编写以面向过程方式也是很自然的事情,单机的操作系统用过程语言实现也是自然的选择。假想计算机的结构中如果是每个存储单元都带有可以执行操作的部件,我想操作系统的底层设计也许就是面向对象的了。其实,以过程的观点来理解多个CPU地并行执行,我感觉就很难理解了,而以面向对象的观点来理解多个CPU并行执行则简明得多。

现在的计算机都连成了网络,从高一级的层次上看,网络上的各个单机节点就是存储单元带有执行操作的部件单元,因此网络应用这一界别的软件系统以面向对象的方法来设计也是很自然的事情,这也许就是面向对象方法越来越流行的原因吧。我想未来基于网络的操作系统,一定是用面向对象的思想来设计的,底层的实现也可能会转向面向对象语言
fita 2003-08-28
  • 打赏
  • 举报
回复
我认为Panr(光荣)对于类和对象之间关系的理解较为正确,但也有不足的地方,现谈谈我的观点:
类和对象是属于两个不同领域的东西,类属于知识领域,对象属于操作领域,在软件的实际运行中,实际存在的是对象,类是对于对象各种属性和行为的一种约束,属于某个类的对象,它的行为模式一定是遵守这个类的规定的,也可以说,类是这个对象所具备的知识,对象在按照它所具有的知识在进行各种活动。类和对象的关系与过程与进程之间的关系是类似的。我们通过编写类来告诉对象该怎么动作,因此可以说类是对象的一种抽象,但只是一方面的抽象,一个对象的行为可以从多个方面进行抽象,也就是说从多个知识领域进行描述,这时这个对象同时属于多个类。在知识领域中不仅仅只有类,我们在软件设计中,还可以在知识领域构建一些对象,在运行期间改变对象的行为,我以前玩foxpro时,就常常利用宏语言这么干,我想用java也可以做得到,人工智能也是在知识领域对象里面做文章,使得对象的“知识”可以不断进化。
关于知识领域和操作领域,在《analysis pattern》这本书里面有非常精彩的描述。

Panr(光荣)对于抽象的要求有点太高了,拿两张照片,就是让你来看,也未必能判断出是否同一个人啊,要不美军怎么老抓错萨达姆。另外,假如我让你判断两只蟑螂是不是一样的,恐怕你就更加看不出来了吧,也许还没有软件做得好,因为你的知识是有限的,类也一样,我们在做软件,不要求对象具备所有的知识,只需要它具备能够完成工作所需要的知识就可以了,也就是把它需要知道的知识写到类里面就可以了。

flysharker 2003-08-28
  • 打赏
  • 举报
回复
以前学软件体系结构的时候没好好学,现在在实践当中感觉不是用理论来指导实践,而是由实践来向理论靠拢,有种自底向上的感觉,看了以上两位高人的讨论,有不少感触,接着看。
zhuma 2003-08-28
  • 打赏
  • 举报
回复
软工版上少见的精彩论战
尽管有些地方我看不太懂

以我的学习背景
大概也包括一般的面向对象学习者
对walkcamel(虫子)的观点应该是比较好接受的

而Panr(光荣)的观点
有些地方看不懂
不好置评
由于我的学习方向之一就是ADT
以前一直认为其是“基于对象”的代表
也就再也没有深入思考过
现在听了Panr(光荣)对ADT的解释
觉得还是有一定启发的
希望Panr(光荣)能进一步为我
讲解一下面向对象和ADT的关系
谢谢
walkcamel 2003-08-28
  • 打赏
  • 举报
回复
1:关于奔驰600的比喻我认为不是很正常,如果当初这种车不叫奔驰600而叫“慢牛3000”,你现在看过后还能有“奔驰600”的概念吗?就如奔驰600一样,如果首先提出类概念的人不把它叫“class‘, 而是”glass“,那么我们现在就不会在这里讨论什么是类了。不过我承认“类的概念在语义/逻辑上有明确对应物”这句话是有一定道理,但这种对应并不是直接的,一目了然的,更多的是经过人的抽象加工而成。而且光荣兄这里讲的也和前面讲的有点自相矛盾了(“由于我个人在分析业务逻辑的过程中找不到“类”的对应物,我觉得这是人为构造出的概念”)。:)

2:在讨论有关ADT结构和面向对象结构的区别的时候,有种观点认为这两者之间的主要差别是在于继承性和多态性,本人深以为然。事实上我个人也认为面向对象的关键就在于继承和多态。我们在C中就能够很好的实现ADT的操作,显然,大家都公认C不是面向对象语言。所以类型数据和实例数据并不是区分面向对象和非面向对象的关键,不过我认同你说的”类型数据“和”实例数据“的概念,以及实例化的语意的两层意思。

3:关于你的抽象化抽象化的标准我不太认同,图象识别涉及的并不只是抽象化的问题,还有很多别的因素在起作用,不过我想你把”抽象化’列入人工智能的范围,想必你在很大程度上是将抽象化等同于模式识别了。而且和你举的例子相反的是,抽象化层次越高的所包含的面越广,包含的具体的信息越少。我们说奔驰600是轿车,但也不能不承认普桑也是轿车,但我们可以说后者不是高级轿车。就是这个道理,显然轿车的抽象层次更高,再往上的是机动车,车,物品。所以CObject是所有类的父类(VC++中)。很显然,在不同的处理层次上,所需要的抽象级别是不一样的,在机动车管理中并不会对奔驰600做有特别的规定,但买车的人就需要的分清楚自己买的是什么车了。这也是“微核”模型的思想起源。如果我们再往下探究,我们可以在“类型数据”的基础上再抽象出一层“类型数据类型”,想想吧,在C中的STRUCT在编译程序中会用什么样的数据结构来表示的。不过如果太抽象了,抽象的层次太多了的话,处理起来就比较的复杂了,所以OMT对对象模型也只定义了4个层次。
4:我没有任何藐视面向过程的程序结构的意思,每种思想都有其产生的背景和使用范围。面向对象能够让我们更好的理解程序,但却在运行效率上有所损失。在一些实时性要求比较高的地方并不是很适合用面向对象的。linux的内核也还是用C写的。对你后面的7点观点我表示同意
wnc 2003-08-28
  • 打赏
  • 举报
回复
对构架的理解不错,构架就是各种角色协调的框架,
是用来降低风险的,优秀的设计文档,在设计构架的时候,
对各种风险都要靠略
walkcamel 2003-08-28
  • 打赏
  • 举报
回复
to Panr(光荣):
我对能够与你进行这种讨论感到十分的荣幸,如果说我的言语间有什么地方使你感到不舒服的话,我这里向你表示十分的谦意,但请相信我绝对没有要人生攻击的意思,再次向你表示歉意。:)
加载更多回复(16)

1,265

社区成员

发帖
与我相关
我的任务
社区描述
软件工程/管理 管理版
社区管理员
  • 研发管理社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧