面向过程与面向对象各自的优缺点是什么

面向过程就是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用就可以了。

面向对象是把构成问题事务分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙某个事物在整个解决问题的步骤中的行为。

例如五子棋，面向过程的设计思路就是首先分析问题的步骤：1、开始游戏，2、黑子先走，3、绘制画面，4、判断输赢，5、轮到白子，6、绘制画面，7、判断输赢，8、返回步骤2，9、输出最后结果。把上面每个步骤用分别的函数来实现，问题就解决了。

而面向对象的设计则是从另外的思路来解决问题。整个五子棋可以分为 1、黑白双方，这两方的行为是一模一样的，2、棋盘系统，负责绘制画面，3、规则系统，负责判定诸如犯规、输赢等。第一类对象（玩家对象）负责接受用户输入，并告知第二类对象（棋盘对象）棋子布局的变化，棋盘对象接收到了棋子的i变化就要负责在屏幕上面显示出这种变化，同时利用第三类对象（规则系统）来对棋局进行判定。

可以明显地看出，面向对象是以功能来划分问题，而不是步骤。同样是绘制棋局，这样的行为在面向过程的设计中分散在了总多步骤中，很可能出现不同的绘制版本，因为通常设计人员会考虑到实际情况进行各种各样的简化。而面向对象的设计中，绘图只可能在棋盘对象中出现，从而保证了绘图的统一。

功能上的统一保证了面向对象设计的可扩展性。比如我要加入悔棋的功能，如果要改动面向过程的设计，那么从输入到判断到显示这一连串的步骤都要改动，甚至步骤之间的循序都要进行大规模调整。如果是面向对象的话，只用改动棋盘对象就行了，棋盘系统保存了黑白双方的棋谱，简单回溯就可以了，而显示和规则判断则不用顾及，同时整个对对象功能的调用顺序都没有变化，改动只是局部的。

再比如我要把这个五子棋游戏改为围棋游戏，如果你是面向过程设计，那么五子棋的规则就分布在了你的程序的每一个角落，要改动还不如重写。但是如果你当初就是面向对象的设计，那么你只用改动规则对象就可以了，五子棋和围棋的区别不就是规则吗？（当然棋盘大小好像也不一样，但是你会觉得这是一个难题吗？直接在棋盘对象中进行一番小改动就可以了。）而下棋的大致步骤从面向对象的角度来看没有任何变化。

当然，要达到改动只是局部的需要设计的人有足够的经验，使用对象不能保证你的程序就是面向对象，初学者或者很蹩脚的程序员很可能以面向对象之虚而行面向过程之实，这样设计出来的所谓面向对象的程序很难有良好的可移植性和可扩展性。

结构化程序的概念首先是从以往编程过程中无限制地使用转移语句而提出的。转移语句可以使程序的控制流程强制性的转向程序的任一处，在传统流程图中，就是用上节我们提到的"很随意"的流程线来描述这种转移功能。如果一个程序中多处出现这种转移情况，将会导致程序流程无序可寻，程序结构杂乱无章，这样的程序是令人难以理解和接受的，并且容易出错。尤其是在实际软件产品的开发中，更多的追求软件的可读性和可修改性，象这种结构和风格的程序是不允许出现的。比如：C，FORTRAN，PASCAL等等

结构化程序设计方法主要由以下三种逻辑结构组成：

1)顺序结构：顺序结构是一种线性、有序的结构，它依次执行各语句模块。

2)循环结构：循环结构是重复执行一个或几个模块，直到满足某一条件为止。

3)选择结构：选择结构是根据条件成立与否选择程序执行的通路。

采用结构化程序设计方法，程序结构清晰，易于阅读、测试、排错和修改。由于每个模块执行单一功能，模块间联系较少，使程序编制比过去更简单，程序更可靠，而且增加了可维护性，每个模块可以独立编制、测试。

面向对象程序语言中支持的对象具有三个明显得特征：

封装、继承、多态；而Javascript在类别和副本上并没有明显地分界。事实上，Javascript语言中所有的变量数据类型在JS中都是对象。JS总共支持4种对象：内置对象、自定义对象、浏览器程序对象和ActiveX对象。

return

this只是返回该对象，以便别处引用，但并不是多出一个对象。

所以，面向过程的程序设计中：程序=算法+数据结构

数据结构和算法相分离的，所以，系统庞大后，它的控制、移植、重用就成了问题。

而在面向对象的程序设计中：

对象=数据结构+算法

程序=对象+对象+

所以克服了面向过程的设计中存在的问题。

弊端是，没有人还记得面向对象原本要解决的问题是什么。

1、面向对象原本要解决什么（或者说有什么优良特性）

似乎很简单，但实际又很不简单：面向对象三要素封装、继承、多态

（警告：事实上，从业界如此总结出这面向对象三要素的一刹那开始，就已经开始犯错了！）。

封装：封装的意义，在于明确标识出允许外部使用的所有成员函数和数据项，或者叫接口。

有了封装，就可以明确区分内外，使得类实现者可以修改封装内的东西而不影响外部调用者；而外部调用者也可以知道自己不可以碰哪里。这就提供一个良好的合作基础——或者说，只要接口这个基础约定不变，则代码改变不足为虑。

继承+多态：继承和多态必须一起说。一旦割裂，就说明理解上已经误入歧途了。

先说继承：继承同时具有两种含义：其一是继承基类的方法，并做出自己的改变和/或扩展——号称解决了代码重用问题；其二是声明某个子类兼容于某基类（或者说，接口上完全兼容于基类），外部调用者可无需关注其差别（内部机制会自动把请求派发[dispatch]到合适的逻辑）。

再说多态：基于对象所属类的不同，外部对同一个方法的调用，实际执行的逻辑不同。

很显然，多态实际上是依附于继承的两种含义的：“改变”和“扩展”本身就意味着必须有机制去自动选用你改变/扩展过的版本，故无多态，则两种含义就不可能实现。

所以，多态实质上是继承的实现细节；那么让多态与封装、继承这两个概念并列，显然是不符合逻辑的。不假思索的就把它们当作可并列概念使用的人，显然是从一开始就被误导了——正是这种误导，使得大多数人把注意力过多集中在多态这个战术层面的问题上，甚至达到近乎恶意利用的程度；同时却忽略了战略层面的问题，这就致使软件很容易被他们设计成一滩稀屎（后面会详细谈论这个）。

实践中，继承的第一种含义（实现继承）意义并不很大，甚至常常是有害的。因为它使得子类与基类出现强耦合。

继承的第二种含义非常重要。它又叫“接口继承”。

接口继承实质上是要求“做出一个良好的抽象，这个抽象规定了一个兼容接口，使得外部调用者无需关心具体细节，可一视同仁的处理实现了特定接口的所有对象”——这在程序设计上，叫做归一化。

归一化使得高层的外部使用者可以不加区分的处理所有接口兼容的对象集合——就好象linux的泛文件概念一样

以上就是关于面向过程与面向对象各自的优缺点是什么全部的内容，包括:面向过程与面向对象各自的优缺点是什么、与面向对象程序设计相比,结构化程序设计有什么样的优势和劣势、举例说明面向对象编程和结构化编程的优缺点等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！