好贷网好贷款

【整理】面向对象与面向过程

发布时间:2016-12-3 14:54:13 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"【整理】面向对象与面向过程",主要涉及到【整理】面向对象与面向过程方面的内容,对于【整理】面向对象与面向过程感兴趣的同学可以参考一下。

维基百科: 面向对象程序设计(英语:Object-oriented programming,缩写:OOP)是一种程序设计范型,同时也是一种程序开发的方法。对象指的是类的实例。它将对象作为程序的基本单元,将程序和数据封装其中,以提高软件的重用性、灵活性和扩展性。[1] 面向对象程序设计可以看作一种在程序中包含各种独立而又互相调用的对象的思想,这与传统的思想刚好相反:传统的程序设计主张将程序看作一系列函数的集合,或者直接就是一系列对计算机下达的指令。面向对象程序设计中的每一个对象都应该能够接受数据、处理数据并将数据传达给其它对象,因此它们都可以被看作一个小型的“机器”,即对象。 目前已经被证实的是,面向对象程序设计推广了程序的灵活性和可维护性,并且在大型项目设计中广为应用。 百度知道: 面向过程就是分析出解决问题所需要的步骤,然后用函数把这些步骤一步一步实现,使用的时候一个一个依次调用就可以了。  面向对象是把构成问题事务分解成各个对象,建立对象的目的不是为了完成一个步骤,而是为了描叙某个事物在整个解决问题的步骤中的行为。 例如五子棋,面向过程的设计思路就是首先分析问题的步骤:1、开始游戏,2、黑子先走,3、绘制画面,4、判断输赢,5、轮到白子,6、绘制画面,7、判断输赢,8、返回步骤2,9、输出最后结果。把上面每个步骤用分别的函数来实现,问题就解决了。 而面向对象的设计则是从另外的思路来解决问题。整个五子棋可以分为 1、黑白双方,这两方的行为是一模一样的,2、棋盘系统,负责绘制画面,3、规则系统,负责判定诸如犯规、输赢等。第一类对象(玩家对象)负责接受用户输入,并告知第二类对象(棋盘对象)棋子布局的变化,棋盘对象接收到了棋子的i变化就要负责在屏幕上面显示出这种变化,同时利用第三类对象(规则系统)来对棋局进行判定。 可以明显地看出,面向对象是以功能来划分问题,而不是步骤。同样是绘制棋局,这样的行为在面向过程的设计中分散在了总多步骤中,很可能出现不同的绘制版本,因为通常设计人员会考虑到实际情况进行各种各样的简化。而面向对象的设计中,绘图只可能在棋盘对象中出现,从而保证了绘图的统一。 功能上的统一保证了面向对象设计的可扩展性。比如我要加入悔棋的功能,如果要改动面向过程的设计,那么从输入到判断到显示这一连串的步骤都要改动,甚至步骤之间的循序都要进行大规模调整。如果是面向对象的话,只用改动棋盘对象就行了,棋盘系统保存了黑白双方的棋谱,简单回溯就可以了,而显示和规则判断则不用顾及,同时整个对对象功能的调用顺序都没有变化,改动只是局部的。 再比如我要把这个五子棋游戏改为围棋游戏,如果你是面向过程设计,那么五子棋的规则就分布在了你的程序的每一个角落,要改动还不如重写。但是如果你当初就是面向对象的设计,那么你只用改动规则对象就可以了,五子棋和围棋的区别不就是规则吗?(当然棋盘大小好像也不一样,但是你会觉得这是一个难题吗?直接在棋盘对象中进行一番小改动就可以了。)而下棋的大致步骤从面向对象的角度来看没有任何变化。 当然,要达到改动只是局部的需要设计的人有足够的经验,使用对象不能保证你的程序就是面向对象,初学者或者很蹩脚的程序员很可能以面向对象之虚而行面向过程之实,这样设计出来的所谓面向对象的程序很难有良好的可移植性和可扩展性。 csdn Damon_tong: 自己的理解: 面向过程是一种以事件为中心的编程思想,以功能(行为)为导向,按模块化的设计,就是分析出解决问题所需要的步骤,然后用函数把这些步骤一步一步实现,实现的时候一个一个依次调用就可以了 面向对象是一种以事物为中心的编程思想,以数据(属性)为导向,将具有相同一个或者多个属性的物体抽象为“类”,将他们包装起来;而有了这些数据(属性)之后,我们再考虑他们的行为(对这些属性进行怎样的操作),是把构成问题的事物分解成各个对象,建立对象的目的不是为了完成一个步骤,而是为了描述某个事物在整个解决问题的步骤中的行为。面向对象的技术,是一种以对象为基础,以事件或消息来驱动对象执行处理的程序设计技术。它具有封装性,继承性以及多态性 ------------------------------------------------------------------------------------------------------------------------------------ 面向过程就是分析出解决问题所需要的步骤,然后用函数把这些步骤一步一步实现,使用的时候一个一个依次调用就可以了。面向对象是把构成问题事务分解成各个对象,建立对象的目的不是为了完成一个步骤,而是为了描叙某个事物在整个解决问题的步骤中的行为。 面向过程 面向过程的程序设计是一种自上而下的设计方法,设计者用一个main函数概括出整个应用程序需要做的事,而main函数由对一系列子函数的调用组成。对于main中的每一个子函数,都又可以再被精炼成更小的函数。重复这个过程,就可以完成一个过程式的设计。其特征是以函数为中心,用函数来作为划分程序的基本单位,数据在过程式设计中往往处于从属的位置。      面向过程式设计的优点是易于理解和掌握,这种逐步细化问题的设计方法和大多数人的思维方式比较接近。      然而,过程式设计对于比较复杂的问题,或是在开发中需求变化比较多的时候,往往显得力不从心。这是因为过程式的设计是自上而下的,这要求设计者在一开始就要对需要解决的问题有一定的了解。在问题比较复杂的时候,要做到这一点会比较困难,而当开发中需求变化的时候,以前对问题的理解也许会变得不再适用。事实上,开发一个系统的过程往往也是一个对系统不断了解和学习的过程,而过程式的设计方法忽略了这一点。      在面向过程式设计的语言中,一般都既有定义数据的元素,如C语言中的结构,也有定义操作的元素,如C语言中的函数。这样做的结果是数据和操作被分离开,容易导致对一种数据的操作分布在整个程序的各个角落,而一个操作也可能会用到很多种数据,在这种情况下,对数据和操作的任何一部分进行修改都会变得很困难。      在面向过程式设计中,main()函数处于一个非常重要的地位。设计者正是在main()函数中,对整个系统进行一个概括的描述,再以此为起点,逐步细化出整个应用程序。然而,这样做的一个后果,是容易将一些较外延和易变化的逻辑(比如用户交互)同程序的核心逻辑混淆在一起。假设我们编写一个图形界面的计算器程序和一个命令行界面的计算器程序,可以想象这两个版本的main()函数会有很大的差异,由此衍生出来的程序很有可能也会迥然不同,而这两个版本的程序本应该有很大部分可以共用才对。      面向过程式设计还有一个问题就是其程序架构的依赖关系问题。一个典型的过程式程序往往如Figure 1所示:        Figure 1      图中的箭头代表了函数间的调用关系,也是函数间的依赖关系。如图所示,main()函数依赖于其子函数,这些子函数又依赖于更小的子函数,而在程序中,越小的函数处理的往往是细节实现,这些具体的实现,又常常变化。这样的结果,就是程序的核心逻辑依赖于外延的细节,程序中本来应该是比较稳定的核心逻辑,也因为依赖于易变化的部分,而变得不稳定起来,一个细节上的小小改动,也有可能在依赖关系上引发一系列变动。可以说这种依赖关系也是过程式设计不能很好处理变化的原因之一,而一个合理的依赖关系,应该是倒过来,由细节实现依赖于核心逻辑才对。      面向对象设计      面向对象是一种自下而上的程序设计方法。不像过程式设计那样一开始就要用main概括出整个程序,面向对象设计往往从问题的一部分着手,一点一点地构建出整个程序。面向对象设计以数据为中心,类作为表现数据的工具,是划分程序的基本单位。而函数在面向对象设计中成为了类的接口。      面向对象设计自下而上的特性,允许开发者从问题的局部开始,在开发过程中逐步加深对系统的理解。这些新的理解以及开发中遇到的需求变化,都会再作用到系统开发本身,形成一种螺旋式的开发方式。(在这种开发方式中,对于已有的代码,常需要运用Refactoring技术来做代码重构以体现系统的变化。)      和函数相比,数据应该是程序中更稳定的部分,比如,一个网上购物程序,无论怎么变化,大概都会处理货物、客户这些数据对象。不过在这里,只有从抽象的角度来看,数据才是稳定的,如果考虑这些数据对象的具体实现,它们甚至比函数还要不稳定,因为在一个数据对象中增减字段在程序开发中是常事。因此,在以数据为中心构建程序的同时,我们需要一种手段来抽象地描述数据,这种手段就是使用函数。在面向对象设计中,类封装了数据,而类的成员函数作为其对外的接口,抽象地描述了类。用类将数据和操作这些数据的函数放在一起,这可以说就是面向对象设计方法的本质。      在面向对象设计中类之间的关系有两种:客户(Client)关系和继承(Inheritance)关系。客户关系如Figure 2所示,表示一个类(Client)会使用到另一个类(Server)。一般将这种关系中的Client类称为客户端,Server类称为服务器。        Figure 2      继承关系如Figure 3所示,表示一个类(Child)对另一个类(Parent)的继承。一般将这种关系中的Parent类称为父类,Child类称为子类。        Figure 3      面向对象设计的过程就是将各个类按以上的两种关系组合在一起,这两种关系都非常简单,不过组合在一起却能提供强大的设计能力。下面介绍如何利用这两种关系来划分程序的不同模块。      在很多应用中,我们都需要将数据存储到数据库中。一个常见的解决手段是使用分层的方法,将程序分为应用层和存储层,Figure 4中是这种方法一个不太成熟的设计:        Figure 4      Application代表应用层的逻辑,DB代表了数据库访问的逻辑,在这个设计中,Application直接调用了DB的服务来将数据存储到数据库中。这样做的缺点是Application对DB有了依赖关系,一旦DB有了任何变化,Application都有可能会受其影响需要改动。当然,如果只是两个类的话,这种依赖关系根本算不上什么问题,然而,我们有理由相信,应用层和存储层都会由不只一个类组成,并都有一定的复杂度,这时它们之间的这种依赖关系就会让人头痛了。当程序的模块越来越多,如果不限制它们之间的联系,那模块间的依赖、程序的复杂度和开发维护的难度都会成指数上升。      所幸的是引入面向对象中的继承关系,我们可以解决这一问题,如图Figure 5所示:        Figure 5      Persistence是一个接口,其包含了Application存储所需用到的服务。DB实现了这个接口,Application则调用Persistence中的服务来存储数据,两者都只依赖于Persistence。这样,Application到DB的依赖关系被Persistence这个接口切断了。因为接口中只包含了服务,也就是成员函数的声明,而不包括任何数据和函数的实现,所以Persistence接口的内容会很简单。在Persistence不变的情况下,Application和DB这两个模块都可以自由地进行修改而不影响到对方。就这样,通过在中间插入接口的方法,程序的模块被划分开,依赖关系也变得容易管理的多。      如果从另一个角度来看Figure 4中的设计,应用层是程序的核心部分,而存储层则可以看成是实现的细节,这个设计犯了和过程式设计同样的错误,即核心逻辑依赖于具体的实现细节,这样,当细节变化时,核心逻辑也会受到影响:假如,当我们需要将数据改存到文件或目录服务中时,按照Figure 4中的设计Application模块就难免受到影响。在Figure 5的设计中则没有这一问题:这里我们可以把Application和Persistence看成是程序的核心逻辑,而Persistence接口的实现(DB)可以看成是程序的细节实现,其依赖关系是细节依赖于核心,当细节变化时核心不会受其影响,这才是一个稳定的依赖关系。遵从这一设计,我们可以在不影响程序核心的情况下,为程序添加或更改存储类型,如Figure 6所示:        Figure 6      这里值得注意的是Persistence和Application被划分到了一起,这是因为Persistence中的服务都是根据Application中的需求制定出来的,Persistence和Application的关系比起它和其子类的关系更加紧密。将接口和其调用者放入一个模块是一个常见的做法,当然,也可以将接口单独划分为一个模块,这一般是在有多个不同的调用模块依赖于该接口,或不同模块间需要更清晰的分离时才这样做。

上一篇:ioclt和stty命令的使用
下一篇:安装Sql2005出错 1935 0x800700200

相关文章

相关评论