OO三步曲之浅析OO的基石[原创]

[MatrixCpp]

注：文章所有权归作者 倪 硕 所有，欢迎任何形式的转载，不过请注明原始文章作者以及出处地点：http://nishuo.35123.net.并且欢迎访问MatrixCpp的专栏
------------------------------------------

OO三步曲



前言：面向对象程序设计（Object-Oriented Programming,以下简称OOP）是一种起源于六十年代的Simula语言，发展已经将近三十年的程序设计思想。其自身理论已经十分完善，并被多种面向对象程序设计语言（Object-Oriented Programming Language,以下简称OOPL）实现。如果把Unix系统看成是国外在系统软件方面的文化根基，那么Smalltalk语言无疑在OOPL领域和Unix持有相同地位。由于很多原因，国内大部分程序设计人员并没有很深的OOP以及OOPL理论，很多人从一开始学习到工作很多年都只是接触到c/c++,java,vb,delphi等静态类型语言，而对纯粹的OOP思想以及作为OOPL根基的Smalltalk以及动态类型语言知之甚少，不知道其实世界上还有一些可以针对变量不绑定类型的编程语言。而这些对比却是深刻理解OO理论的重要部分，而国内这方面的资料也为数不多。故把自己的一些OO学习心得写下来做为一个系列文章（一共三篇，第一篇描叙OOP的一些基本但容易被误解的理论，第二篇主要说明各种OOPL演化和发展以及对于OOP理论的支持，第三篇主要是说模式和组件在OOP中的地位以及展望OOP的未来），由于文章描叙的只是自己对于OOP/OOPL的理解，错误以及浅薄之处再所难免，只是希望对大家能起到抛砖引玉的作用。





浅析OO的基石



从抽象说起



Booch曾经在他自己的OO领域内的名著[Booch 94]中开篇就论叙到了复杂性是软件开发过程中所故有的特质。而人们处理复杂性的最根本武器就是抽象。广义的抽象代表的是对复杂系统的简化描叙或规格说明，为了突出系统的本质属性而故意忽略其中的非实质性细节。“一个概念只有当能被最终用来实现的机制独立的描叙，理解，分析时，才将这个概念限定为抽象的概念”。而Booch也给出了他心目中关于OO领域内的狭义抽象定义：“抽象表示一个对象与其他所有对象相区别的基本特征，因此提供了同观察者角度有关的清晰定义的概念界限。”因此，根据不同观察角度，我们可以针对OOP给出不同级别的抽象层次。通常，面对一个典型的面向对象程序，[Budd 2002]将其分成五个抽象层，分别覆盖了OOP中的分析，设计与编程的各个阶段：

1， 最高级别的抽象层上，程序被看成是由很多相互作用并且遵守契约的对象所组成的对象集合。对象之间相互合作完成程序的计算任务。这个抽象级别上的典型代表就是设计模式思想（Design Pattern）。

2， 第二个抽象层就是一个对象集单元，也就是一群定义之间有相互联系的对象，在程序设计语言级别来看Java中是packages,C++中是name space。这个抽象级别上的典型代表就是模块化思想(Modularity)。

3， 第三个抽象层所代表的是典型的OOP模式：客户/服务器模型，这主要是用来抽象两个对象之间的互交过程。在这个抽象级别上的典型代表就是对象之间的消息机制(Message Passing)。

4， 第四个抽象层就是针对一组相似对象定义一个类作为生成对象的模板，类定义了对象的对外使用接口以及继承对象所需的内部继承接口，而这个抽象层次的典型代表就是接口编程(Interface Programming)。

5， 第五个抽象层就是实现一个类所需要的方法和成员变量的实现(Implementation)。在这里OOP最终和POP（Procedure-Oriented Programming）相融合。

当然，我们可以根据各自的观察角度划分成更细的抽象层次比如说针对第五层抽象用到的POP理论，我们还可以进一步的划分出控制抽象（三种完全描叙图灵机计算模型所需要的控制结构）以及数据抽象（ADTs）等等，并由此继续下去（如果你的想象力足够丰富的话：）。





什么是OOP？



OOP的许多原始思想都来之于Simula语言，并在Smalltalk语言的完善和标准化过程中得到更多的扩展和对以前的思想的重新注解。可以说OO思想和OOPL几乎是同步发展相互促进的。与函数式程序设计（functional-programming）和逻辑式程序设计（logic-programming）所代表的接近于机器的实际计算模型所不同的是，OOP几乎没有引入精确的数学描叙，而是倾向于建立一个对象模型，它能够近似的反映应用领域内的实体之间的关系，其本质是更接近于一种人类认知事物所采用的哲学观的计算模型。由此，导致了一个自然的话题，那就是OOP到底是什么？[D&T 1988][B.S 1991] .。在OOP中，对象作为计算主体，拥有自己的名称，状态以及接受外界消息的接口。在对象模型中，产生新对象，旧对象销毁，发送消息，响应消息就构成OOP计算模型的根本。



对象的产生有两种基本方式。一种是以原型（prototype）对象为基础产生新的对象。一种是以类（class）为基础产生新对象。原型的概念已经在认知心理学中被用来解释概念学习的递增特性，原型模型本身就是企图通过提供一个有代表性的对象为基础来产生各种新的对象，并由此继续产生更符合实际应用的对象。而原型-委托也是OOP中的对象抽象，代码共享机制中的一种。一个类提供了一个或者多个对象的通用性描叙。从形式化的观点看，类与类型有关，因此一个类相当于是从该类中产生的实例的集合。而这样的观点也会带来一些矛盾，比较典型的就是在继承体系下，子集（子类）对象和父集（父类）对象之间的行为相融性可能很难达到，这也就是OOP中常被引用的---子类型（subtype）不等于子类（subclass）[Budd 2002]。而在一种所有皆对象的世界观背景下，在类模型基础上还诞生出了一种拥有元类（metaclass）的新对象模型。即类本身也是一种其他类的对象。以上三种根本不同的观点各自定义了三种基于类（class-based）,基于原型（prototype-based）和基于元类（metaclass-based）的对象模型。而这三种对象模型也就导致了许多不同的程序设计语言（如果我们暂时把静态与动态的差别放在一边）。是的，我们经常接触的C++,Java都是使用基于类的对象模型，但除此之外还有很多我们所没有接触的OOPL采用了完全不一样的对象模型，他们是在用另外一种观点诠释OOP的内涵。





什么是类型（type）?



类型以及类型系统的起源以及研究与发展是独立于OOP的。早在五十年代的FORTRAN语言编译器实现中，就已经采用类型系统作为类型检查的一种手段。广义的类型一般被定义为一种约束，也就是一种逻辑公式。而在对类型的研究过程中产生多种方法，比如[C&W 1985]等。而代数方法（algebraic approach）是一种非常好的建立类型的形式化规范的方法。代数中的一个类型对应于一系列元素，在它们之上定义代数操作。同时在此基础上二阶λ演算已经被用于继承和模板所支持的模型。在上面两种方法中，类型被认为是一系列满足确定约束条件的元素，更抽象的方式可以把一个类型当作规定一个约束条件，如果我们规定的约束条件越好，相对应的被定义元素的集合就越精密，所以逻辑公式（logical formulas）就成为描叙类型特征的最合适工具。在这里，我们不想深入的探究对于类型理论的各种不同的数学模型，我们需要明白的是类型（type）以及类型理论这个在编程语言中经常应用到的概念的内涵是极其丰富的，而其自身理论的发展并非局限于OOP之中，但当两者相结合的时候就对我们的程序观产生了巨大的影响。

[yangqing2000]

Java语言由于设计理念和C++有着很大的区别，它采用的是第3种对象模型，一切对象（除了基本类型对象）都是基于堆分配的。这也是Java语言必须采用虚拟机的原因所在。

最后一句话好像是不对的。这不是java必须采用虚拟机的原因所在。可以把一个C++程序的一
切对象改为在堆中分配，即运行时分配（用new和指针)，这个程序仍然是可以编译的。
java采用虚拟机目的是跨平台，是为internet而生（想想一个程序可以在ibm的大型机上运行，同时无需修改还能在win-intel的pc上运行，目前只有java才能做到，方法是只要在每个机器上装个java虚拟机就可以了）。

• 打赏
• 举报

回复 赞

[abei11]

支持这样的好贴

• 打赏
• 举报

回复 赞

[carbon107]

up

• 打赏
• 举报

回复 赞

[arya]

"与函数式程序设计（functional-programming）和逻辑式程序设计（logic-programming）所代表的接近于机器的实际计算模型所不同的是，OOP几乎没有引入精确的数学描叙，..."

虽然楼上不是专门讨论函数式程序设计和逻辑式程序设计的, 我也不得不指出, 认为"函数式程序设计"和"逻辑式程序设计"是代表了"接近于机器的实际计算模型", 实在是一个大笑话. 除非楼上认为实际机器就是"理想数学机器". 与这二者比起来, 毋宁说OOPL更加接近机器的实际计算模型, 虽然OOPL已经是相当高级的机器模型.

• 打赏
• 举报

回复 赞

[MatrixCpp]

to yangqing2000():

确实，这是个概念错误，不过我当时想表达是java必须采取GC的原因，由于GC在虚拟机实现所以我犯了这个表达上的错误，下面的讨论一样我是想指大家对GC的判断而不是虚拟机，谢谢指正。

• 打赏
• 举报

回复 赞

[MatrixCpp]

to arya(行者) :

首先我没有定义"接近于机器的实际计算模型",，所以导致了歧义性，这是文章不严谨的地方~：）

另外不知道你认为“函数式程序设计和逻辑式程序设计”是代表的什么数学模型或者哲学模型。这方面我了解不多，只看过一些论文而已，没有一个全面的认识。不过我的观点是从图灵机观点看，计算机的实际模型是功能化分解的依赖于算法和流程化执行的。也就是说在程序设计过程中，计算次序是早绑定的，而这于是OO设计和其他计算模型的根本区别之一，因为OO设计是不强调计算的次序而是bottom-up的分解problem domain。不知道这样的理解是否全面。望指点~：）

• 打赏
• 举报

回复 赞

[MatrixCpp]

什么是类型（type）?



类型以及类型系统的起源以及研究与发展是独立于OOP的。早在五十年代的FORTRAN语言编译器实现中，就已经采用类型系统作为类型检查的一种手段。广义的类型一般被定义为一种约束，也就是一种逻辑公式。而在对类型的研究过程中产生多种方法，比如[C&W 1985]等。而代数方法（algebraic approach）是一种非常好的建立类型的形式化规范的方法。代数中的一个类型对应于一系列元素，在它们之上定义代数操作。同时在此基础上二阶λ演算已经被用于继承和模板所支持的模型。在上面两种方法中，类型被认为是一系列满足确定约束条件的元素，更抽象的方式可以把一个类型当作规定一个约束条件，如果我们规定的约束条件越好，相对应的被定义元素的集合就越精密，所以逻辑公式（logical formulas）就成为描叙类型特征的最合适工具。在这里，我们不想深入的探究对于类型理论的各种不同的数学模型，我们需要明白的是类型（type）以及类型理论这个在编程语言中经常应用到的概念的内涵是极其丰富的，而其自身理论的发展并非局限于OOP之中，但当两者相结合的时候就对我们的程序观产生了巨大的影响。



类（class），类型(type)，接口（interface）



这三个概念是在OOP中出现频率最多，也最容易混淆的。而对于这三个概念的澄清也是文章写作的初衷。让我们先看看大师们对于这三个概念的描叙----

“The fundamental unit of programming in Java programming language is the class, but the fundamental unit of the object-oriented design is the type.while classes define types,it is very useful and powerful to be able to define a type without defining a class.Interface define types in an abstract form as a collection of methods or other types that form the contract for the type.” [Jams 2000]。

“In C++,A class is a user definite type”[B.S 1998]。

“A type is a name used to denote a particular interface……An object may have many types,and widely different objects can share a type.Part of an object’s interface may be characterized by one type ,and other parts by other types.Two objects of the same type need only share parts of their interface.Interface can contain other interface as subset.We say that a type is a subtype of another if its interface contain the interface of its supertype.Often we speak of a subtype inheriting the interface of its supertype”[Gamma 1995]



在其中，一共出现了四个概念：类（class），类型(type)，接口（interface）以及契约（contract）。这里我们说到的类型和上面提到的类型有所不同，是狭义的OOP中的类型。为了理解这几个概念，我先划分出三个概念域：一个是针对现实世界的，一个是针对特定程序设计范型的（在这里就是OO设计范型），最后一个是针对编译器实现的。也就是说，在现实世界中的概念必须有一种手段映射到OO范型中去，而OO范型中的概念也应该在编译器实现中有相同的概念对应。由此，我们可以这样说，类是做为现实世界中的概念，而传统的OOPL都会提供class关键字来表示对现实世界模拟的支持。而接口，是作为OO程序设计范型中与类对应的一个概念。在OO设计中，我们所要做的就是针对接口进行设计和编程，而接口的实质含义就是对象之间的一种契约。而类型就是编译器实现中针对类和接口所定义的对应概念。可以这样说，类是现实世界中存在的客观概念，是唯物的。接口是设计人员定义出来的，存在于设计人员心中的概念，是唯心的。而类型是类和接口这两种概念的编译器实现的映射概念，也是唯物的。类型主要是用来指导编译器的类型检查的谓词，类是创建现实对象的模板，接口是OO设计中的关键概念。这三个概念相互区别（分别位于不同的概念域），又相互联系（都是代表相同的概念的不同概念域的映射）。有了上面的理解，我们看看下面最常见的Java语句：

people a=new man();

这代表了什么？程序员向编译器声明了一个people类型（type）的对象变量a，而对象变量a本身却指向了一个man类（class）的实体（而在编译器中理解是对象变量a指向了一个类型为man的实体）。再让我们回到[Jams 2000]，其中句子的根本含义我们可以概括如下：声明一个类或者一个接口都同时向编译器注册了一个新的类型，而此类或者接口以及类型都是共享同样的一个名字。也就是说。编译器所能理解的全部都是类型，而程序员的工作是把现实中的类概念转化为设计中的接口概念，而编译器对应于上两种概念都有直接的支持，那就是一个类声明或者接口声明在编译器的理解来看就是一个类型声明。但是反过来却不一定成立。一个类可以有多个接口（一个类完全有可能实现了设计人员的多个契约条件），同时也就可能有多个类型（因为类型不过是接口这个设计域内的概念在编译器中的实现）。

• 打赏
• 举报

回复 赞

[MatrixCpp]

多态，替换原则，对象切割



多态作为OO中的核心机制之一拥有着丰富的内涵。顾名思义，多态就是一种名称多种形态的意思。其主要有三种形式：函数多态，对象变量多态，泛型多态。函数多态主要包括函数重载（overload）和改写(overriding)。泛型多态（genericity）主要是提供了一种创建通用工具的方法，可以在特定的场合将其特化。在这里，我们重点要考量的是对象变量多态。在理解对象变量多态之前，我们首先了解一下OO核心机制之一的替换原则。静态类型的OOPL的一个特征就是一个变量所包含的值（value）的类型可能并不等于这个变量所声明的类型，在传统的编程语言中并不具备这样的特征，因为我们不可能把声明为整型的变量赋上字符串的变量值。而替换原则发生作用的情况就隐含的描叙了两种不同类型所具有的关联----类型继承。Barbara Liskov曾经这样描叙替换原则以及起作用的类型之间的关联：对于类型为S的每个对象s，存在一个类型为T的对象t，对于根据类型T所定义的所有程序P，如果用对象s替换对象t，程序P的行为保持不变，那么类型S就是类型T的子类型[Liskov 1988]



在理解了多态以及替换原则后，我们可以继续深入理解继承与替换原则相结合所带来的新的观点。可以说继承与替换原则的引入影响了几乎所有的OOPL，包括类型系统，值语义/引用语义，对象内存空间分配等等。下面，我将试图逐步的拨开其中的各种因果。



首先考虑,people a; 这样的代码在编译器中将如何实现？可以肯定是首先将把类型people绑定到对象a上，然后必须为对象a分配空间。同时，我们创建people的子类man，由于man IS A people。根据多态以及替换原则，我们当然可以让对象a保存一个man类型的值（这就是替换原则的表现）。这是一种直观的描叙，但在编程语言的实现过程中就出现一些困难。我们知道继承是一种扩展接口与实现的方式，那么我们就很难保证man类型不对people类型做扩展，而一旦做出扩展，我们如何能用存储people对象的空间去存储man类型的对象值呢？

people a；

man b=new man();

a=b;

这样的代码将首先把b对象进行切割，然后再存储到a对象空间去。然而这并不是我们所期望的。那么，为了支持OOP的继承，多态，替换原则，但却需要避免对象切割的发生，面对对象a我们将采用何种分配空间模型呢？常用的有下面三种方式：

1， 只为a分配基类people的存储空间，不支持对象多态以及替换原则。这样的模型内存分配紧凑，存储效率很高。

2， 分配继承树中的最大类对象所需要空间（在这里是man类的对象值空间），这样的模型简单，同时可以实现多态和替换原则而避免对象切割问题，但是十分浪费内存空间十分明显。

3， 只分配用于保存一个指针所需要的存储空间，在运行时通过堆来分配对象实际类型所需要的空间大小，这样也可以实现多态和替换原则而避免对象切割问题。（也就是说a只是一个对象的引用，而不是真实的对象，真实对象的生成必须靠程序员显式的声明）。

对于上面提到的三种内存模型，1和3都被一些程序设计语言所采用。相信说到这里，大家应该开始慢慢明白了。是的，C++作为C语言的继承者，对于效率的追求迫使它必须采用第一种最小静态空间分配的方式，由于基于栈空间的程序运行效率要比基于堆空间的程序运行效率高出许多，所以C++允许用栈空间保存对象，但同时也允许堆空间保存对象，可以说C++是采用了1和3两种相混合的内存模型，而C++中基于1内存模型的对象，也就是说基于栈内存空间的对象是没有办法体现多态和替换原则的（请思考一下在C++中什么对象是基于栈的），而基于3内存模型的对象将支持多态和替换原则（又想一想在C++中什么对象是基于堆的）。这里，我们终于可以揭开第一层迷雾了，很多人都知道在C++中只有指针和引用才能支持对象的多态行为，但是为什么会如此？上面做出了最好的解释。



Java语言由于设计理念和C++有着很大的区别，它采用的是第3种对象模型，一切对象（除了基本类型对象）都是基于堆分配的。这也是Java语言必须采用虚拟机的原因所在。在C++中很大一部分对象是不需要程序员进行管理的（静态空间对象），而在Java中，如果不采用虚拟机机制，所有的对象都需要程序员管理，而这样的开发代价将是巨大而不现实的。这也就揭开了第二层迷雾，当我们在对比C++和Java语言的时候总是为虚拟机是否有其价值而争论不休，但当你抛开所谓的好与不好的简单讨论，进入到其语言本身的内在对象存储本质的时候，也许对于各种声音才会有一个属于自己的清醒认识。



让我们继续望下走，不同的对象内存分配模型直接影响到其程序设计语言的赋值的含义。在各种编程语言中，赋值可以给出两种不同的语义解释：复制语义和指针语义。很明显，由于C++支持两种相混合的对象存储模型（但是默认的存储方式是栈存储），所以在C++中默认赋值语义采用的是前者，但C++同时提供了指针语义的功能支持（在拷贝构造函数和=运算符重载中用户进行自定义）。而在Java中采用的是后者。这也就是我们揭开的最后一道迷雾，不同的对象存储模型直接导致了不同的赋值语义。





面向对象的计算模型和可计算性



编程就是用计算所需要的指令构成一种运算装置，无论我们的程序设计思想以及程序设计语言如何发展和提高，最终我们所使用的底层计算数学模型并没有改变。但高级程序设计语言给我们带来的变革是在其语言环境中构建起了一个全新的，更抽象的虚拟计算模型。Smalltalk语言引入的对象计算模型从根本上改变了以前的传统计算模型，以前的计算模型突出的是顺序计算过程中的机器状态，而现在的对象计算模型突出的对象之间的协作其计算结果由参加计算的所有的对象的状态总体构成。而由于对象本身具有自身状态，我们也可以把一个对象看成是一个小的计算机器。这样，面向对象的计算模型就演变成了许多小的计算机器的合作计算模型。图灵机作为计算领域内的根本计算模型，精确的抓住了计算的要点：什么是可计算的，计算时间和空间存储大小开销有多大。计算模型清楚的界定了可计算性的范围，也就界定了哪些问题是可求解，哪些问题是不可求解的。OOP为程序员提供了一种更加抽象和易于理解的新的计算模型，但其本身并没有超越冯.诺依曼体系所代表的图灵机数学计算模型。所以我们不能期望OOP能帮助我们解决更多的问题，或者减少运算的复杂度。但OOP却能帮助我们用一种更容易被我们所理解和接受的方式去描叙和解决现实问题。





结 束



这篇文章做为这个系列的第一篇，对于OOP中的许多核心概念和机制进行了有益的讨论，作者衷心的希望通过这篇文章能够让大家对于OOP有更深入的理解，同时明白OOP作为已经发展将近三十年的程序设计思想，其自身丰富的理论内涵不是单单学习几门OOPL就可以领悟。最后期望本文能实现了它的初衷---抛砖引玉。





Reference:



[D&T 1988] : Type Theories and Object-Oriented programming by Scott Danforth and Chris Tomlinson on ACM Computing Surveys Vol.20 No.1 March 1988



[Liskov 1988] :Data Abstraction and Hierarchy by Barbara Liskov on Sigplan Notices,23(5),1988



[C&W 1985] On understanding types,data abstraction,and polymorphism by Cardelli . L and Wegner . P on ACM Computing Surveys Vol.17 No.4 Dec 1985



[B.S 1991] What is “Object-Oriented programming”?(1991 revised version) by Bjarne Stroustrup AT&T Bell Lab Murray Hill ,New Jersey 07974



[B.S 1998] 《The C++ programming language (Special Editon)》 by Bjarne Stroustrup Addison Wesley 1998



[Gamma 1995] 《Design Pattern》by Eric Gamma etc Addison Wesley 1995



[Booch 94] : 《Object-Oriented Analysis and Design with Application (Sec Editon)》 by Grady Booch Addison Wesley 1994



[Jams 2000] : 《The Java programming language (Third Editon)》by Ken Arnold, Jams Gosling, David Holmes Addison Wesley 2000



[Budd 2002]: 《Introduction to Object-Oriented programming (Third Editon)》 by Timothy A.Budd Addison Wesley 2002



参考书籍：



《C++程序设计语言》Bjarne Stroustrup著 裘宗燕译 机械工业出版社 2002年



《设计模式》Erich Gamma等著 李英军等译 机械工业出版社 2000年



《面向对象软件开发原理》Anton著 袁兆山等译 机械工业出版社 2003年



《面向对象编程导论》Timothy A.Budd著 黄明军等译 机械工业出版社 2003年



《面向对象分析与设计》 Grady Booch著 冯博琴等译 机械工业出版社 2003年



《面向对象软件构造》(英文版.第二版) Bertrand Meyer著 机械工业出版社 2003年

• 打赏
• 举报

回复 赞

[arya]

不知道你学习了什么论文让你得出"函数式程序设计"或者"逻辑式程序设计"的计算模型是早绑定的结论? 或者早绑定的计算模型就比晚绑定的计算模型更加接近实际的机器模型? 虽然你没有对"机器的实际计算模型"作出定义, 我猜它是"冯-诺伊曼机"总不会太离谱吧. 这种"实际机器"的模型都可以看做是一个顺序执行的状态机的模型. 让我们来看看函数式语言和逻辑式语言的计算模型是否和这类模型相仿.

先看函数式语言. 其代表是Haskell(纯函数式语言).
Haskell有以下特点:
1. 无副作用(no side effects). 这就和"状态机"一下子有天壤之别了.
2. 惰性求值(lazy evaluation). 数据不到被求值的那一刻不"显露"出来. 这个状态是缺省的. 基本上你不费点劲, 你的haskell程序处处都是lazy evaluation. 这个比OOPL的某些晚绑定的对象数据模型如何?
3. 高阶函数. 在Haskell语言里, 表达函数的函数, 函数的函数的函数, 等等, 那是司空见惯的事情. 函数可以以数据的形式进行运算(lambda表达式). 而这, 已经脱离了具体机器模型的范畴, 而进入了数学和逻辑的范畴.

再看逻辑式语言. 其代表自然是Prolog语言:
Prolog语言有以下特点:
1. 基于warren抽象机. warren抽象机你可以慢慢研究. warren抽象机是建立在逻辑数据上的计算模型, 实际上是一种基于树的计算模型(warren抽象机的数据组织也是基于树的). 它的核心操作是合一(unification)运算. 这一运算是数据结构和控制结构的结合点. 数据和控制流在此单一操作中互相影响(有没有嗅出你的"晚绑定"味道?)
2. 从warren抽象机出发, Prolog很自然的就是无(数据)副作用和惰性求值的. 这个恕我不再展开.
3. 高阶逻辑. Prolog还提供了一定的二阶逻辑能力. 这也进入了数学和逻辑的范畴.

你当然可以说, 以上两种计算模型都是可以用状态机模型实现的. 实现是一回事情, 概念的差别是另外一回事情. 这两种计算模型虽然都是从状态机模型构造出来的, 但是却不是状态机模型轻易能够模仿的. 而且两者在概念上都更接近于纯数学和逻辑, 而不是状态机. 正因为函数式语言和逻辑式语言概念上的高级特点, 它们的程序很容易就可以被并行运算(改编译器就可以, 程序不用动), 虽然在个人机上它们常常以串行运算的面目出现. 这又显示了它们高于实际机器模型的一面.

• 打赏
• 举报

回复 赞

[Laper]

mark

• 打赏
• 举报

回复 赞

[WildLife]

关注高手的讨论，崇拜中......，请继续！！

• 打赏
• 举报

回复 赞

[MatrixCpp]

to arya(行者):

"与函数式程序设计（functional-programming）和逻辑式程序设计（logic-programming）所代表的接近于机器的实际计算模型所不同的是，OOP几乎没有引入精确的数学描叙，而是倾向于建立一个对象模型，它能够近似的反映应用领域内的实体之间的关系，其本质是更接近于一种人类认知事物所采用的哲学观的计算模型。"

这是我说到的,其中函数式与逻辑式程序设计是否接近计算机的实际计算模型,在这个论点上,由于我个人的学习不够全面也许做出了错误的论断(我还需要再看些东西确认),而后面的我想要说明的是"OOP几乎没有引入精确的数学描叙......."我想,这和你的一些观点是一致的,也就是说不管函数式与逻辑式程序设计是否接近计算机的实际计算模型他们都是引入了比较精确的数学模型或者进入了逻辑范畴,从你的回帖中可以看出来你对此是认同的.而我上面说的那段话,我想我想说明的重点就是要得到我们都认同的这个论断,只是我采用的论据你不是十分认可对不?~:)

在函数和逻辑编程方面,我没有详细的了解.至于说我看了那么论文,在我后面的Reference里面都写了,当然有一些是以前看过的,也许就没有写上去了,不过大部分的都在那里面了,如果你有兴趣可以参考.

最后,谢谢你的指正

• 打赏
• 举报

回复 赞

[bing_huo]

高。。收藏

• 打赏
• 举报

回复 赞

[deepth]

new b!

• 打赏
• 举报

回复 赞

[caocao82]

学习ing~!

• 打赏
• 举报

回复 赞