面向对象方法和结构化方法各自的特点与利弊

结构化分析设计方法遵循面向过程的问题求解方法，其中心思想是用计算机能够理解的逻辑来描述和表达待解决的问题及其具体的解决过程。结构化的程序设计的核心就是算法加数据结构。 面向过程方法大多基于瀑布模型，需要对整体结构做以通盘的掌握。当用户的需求发生变化时，整个软件功能就随之发生变化，从而导致整个软件结构的不稳定。同时，过程分析和数据分析始终是两个相对独立的过程，两者之间存在着明显的边界，这个问题始终在结构化方法中终没解决。 对象是面向对象的程序设计的核心，它由描述状态的属性（变量）和用来实现对象行为的方法（函数）组成，完成了从数据模型到处理模型的结合与统一。面向对象方法论的出发点和基本原则是尽可能的模拟人类习惯的思维方式，使开发软件的方法与过程尽可能的接近人类认识世界解决问题的方法与过程。 结构化的程序设计是一种自上而下的设计方法，设计者用一个主函数概括出整个应用程序需要做的事情主线，并由对一系列子函数的调用组成。以函数为中心。 结构化方法是将系统看成是过程的集合，过程与数据实体之间交互，过程接受输入并产生输出； 面向对象方法则不再把程序看成工作在数据上的一系列过程或函数的集合，而是把程序看作是相互协作而又彼此独立的对象的集合。 从概念方面看，结构化软件是功能的集合；面向对象软件是事物对象的集合。 从构成方面看，结构化软件是过程和数据的集合，以过程为中心；面向对象软件是数据和相应 *** 作的封装，以对象为中心。 从运行控制方面看，结构化软件采用顺序处理方式，由过程驱动控制；面向对象软件采用交互式，并行处理方式，由消息驱动控制。

结构化程序设计特点：

优点： 与非结构化程序相比，结构化程序在调试、可读性和可维护性等方面都有很大的改进。

缺点：代码重用性不高：以过程为中心设计新系统，除了一些标准函数，大部分代码都必须重新编写。

由于软、硬件技术的不断发展和用户需求的变化，按照功能划分设计的系统模块容易发生变化，使得开发出来的模块的可维护性欠佳。

面向过程模式将数据与过程分离，若对某一数据结构做了修改，所有处理数据的过程都必须重新修订，这样就增加了很多的编程工作量。

面向对象的优点：

而面向对象围绕现实世界的概念来组织模块，采用对象描述问题空间的实体，用程序代码模拟现实世界中的对象，使程序设计过程更自然、更直观。

面向过程是以功能为中心来描述系统，而面向对象是以数据为中心来描述系统。相对于功能而言，数据具有更强的稳定性。

面向对象模拟了对象之间的通信。就象人们之间互通信息一样，对象之间也可以通过消息进行通信。这样，我们不必知道一个对象是怎样实现其行为的，只需通过对象提供的接口进行通信并使用对象所具有的行为功能。而面向过程则通过函数参数和全局变量达到各过程模块联系的目的。

面向对象把一个复杂的问题分解成多个能够完成独立功能的对象（类），然后把这些对象组合起来去完成这个复杂的问题。采用面向对象模式就象在流水线上工作，我们最终只需将多个零部件（已设计好的对象）按照一定关系组合成一个完整的系统。这样使得软件开发更有效率。

程序设计主要方法有面向结构的方法和面向对象的方法。

结构化程序设计

随着计算机的价格不断下降，硬件环境不断改善，运行速度不断提升。程序越写越大，功能越来越强，讲究技巧的程序设计方法已经不能适应需求了。记得是哪本书上讲过，一个软件的开发成本是由：程序设计 30% 和程序维护 70% 构成。这是书上给出的一个理论值，但实际上，从我十几年的工作经验中，我得到的体会是：程序设计占 10%，而维护要占 90%。也许我说的还是太保守了，维护的成本还应该再提高。下面这个程序，提供了两种设计方案，大家看看哪个更好一些那？

题目：对一个数组中的100个元素，从小到大排序并显示输出。(BASIC)

方法1：冒泡法排序，同时输出。

FOR I=1 TO 100

　 FOR J=I+1 TO 100

IF A[I] > A[J] THEN T=A[J]: A[J]=A[I]: A[I]=T

　 NEXT J

　 A[I]

NEXT I

方法2：冒泡法排序，然后再输出。

FOR I=1 TO 100

FOR J=I+1 TO 100

IF A[I] > A[J] THEN T=A[J]: A[J]=A[I]: A[I]=T

NEXT

NEXT

FOR I=1 TO 100

A[I]

NEXT

显然，“方法1”比“方法2”的效率要高，运行的更快。但是，从现在的程序设计角度来看，“方法2”更高级。原因很简单：（1）功能模块分割清晰——易读；（2）也是最重要的——易维护。程序在设计阶段的时候，就要考虑以后的维护问题。比如现在是实现了在屏幕上的输出，也许将来某一天，你要修改程序，输出到打印机上、输出到绘图仪上；也许将来某一天，你学习了一个新的高级的排序方法，由“冒泡法”改进为“快速排序”、“堆排序”。那么在“方法2”的基础上进行修改，是不是就更简单了，更容易了？！这种把功能模块分离的程序设计方法，就叫“结构化程序设计”。

面向对象的程序设计

随着程序的设计的复杂性增加，结构化程序设计方法又不够用了。不够用的根本原因是“代码重用”的时候不方便。面向对象的方法诞生了，它通过继承来实现比较完善的代码重用功能。很多学生在应聘工作，面试的时候，常被问及一个问题“你来谈谈什么是面向对象的程序设计”，学生无言，回来问我，这个问题应该怎么回答。我告诉他，你只要说一句话就够了“面向对象程序设计是对数据的封装；范式（模板）的程序设计是对算法的封装。”后来再有学生遇到了这个问题，只简单的一句对答，对方就对这个学生就刮目相看了（学生后来自豪地告诉我的）。为什么那？因为只有经过彻底的体会和实践才能提炼出这个精华。

面向对象的设计方法和思想，其实早在70年代初就已经被提出来了。其目的就是：强制程序必须通过函数的方式来 *** 纵数据。这样实现了数据的封装，就避免了以前设计方法中的，任何代码都可以随便 *** 作数据而因起的BUG，而查找修改这个BUG是非常困难的。那么你可以说，即使我不使用面向对象，当我想访问某个数据的时候，我就通过调用函数访问不就可以了吗？是的，的确可以，但并不是强制的。人都有惰性，当我想对 i 加1的时候，干吗非要调用函数呀？算了，直接i++多省事呀。呵呵，正式由于这个懒惰，当程序出BUG的时候，可就不好捉啦。而面向对象是强制性的，从编译阶段就解决了你懒惰的问题。

巧合的是，面向对象的思想，其实和我们的日常生活中处理问题是吻合的。举例来说，我打算丢掉一个茶杯，怎么扔那？太简单了，拿起茶杯，走到垃圾桶，扔！注意分析这个过程，我们是先选一个“对象”------茶杯，然后向这个对象施加一个动作——扔。每个对象所能施加在它上面的动作是有一定限制的：茶杯，可以被扔，可以被砸，可以用来喝水，可以敲它发出声音；一张纸，可以被写字，可以撕，可以烧。也就是说，一旦确定了一个对象，则方法也就跟着确定了。我们的日常生活就是如此。但是，大家回想一下我们程序设计和对计算机的 *** 作，却不是这样的。拿DOS的 *** 作来说，我要删除一个文件，方法是在DOS提示符下：c:> del 文件名<回车>。注意看这个过程，动作在前（del），对象在后(文件名),和面向对象的方法正好顺序相反。那么只是一个顺序的问题，会带来什么影响那？呵呵，大家一定看到过这个现象：File not found “啊~~~，我错了，我错了，文件名敲错了一个字母”，于是重新输入：c:> del 文件名2<回车>。不幸又发生了，计算机报告：File read only 哈哈，痛苦吧:)。所以DOS的 *** 作其实是违反我们日常生活中的习惯的（当然，以前谁也没有提出过异议），而现在由于使用了面向对象的设计，那么这些问题，就在编译的时候解决了，而不是在运行的时候。objfun()，对于这条语句，无论是对象，还是函数，如果你输入有问题，那么都会在编译的时候报告出来，方便你修改，而不是在执行的时候出错，害的你到处去捉虫子。

同时，面向对象又能解决代码重用的问题——继承。我以前写了一个“狗”的类，属性有（变量）：有毛、4条腿、有翘着的尾巴（耷拉着尾巴的那是狼）、鼻子很灵敏、喜欢吃肉骨头方法有（函数）：能跑、能闻、汪汪叫如果它去抓耗子，人家叫它“多管闲事”。好了，狗这个类写好了。但在我实际的生活中，我家养的这条狗和我以前写的这个“狗类”非常相似，只有一点点的不同，就是我的这条狗，它是：卷毛而且长长的，鼻子小，嘴小。于是，我派生一个新的类型，叫“哈巴狗类”在“狗类”的基础上，加上新的特性。好了，程序写完了，并且是重用了以前的正确的代码——这就是面向对象程序设计的好处。我的成功只是站在了巨人的肩膀上。当然，如果你使用VC的话，重用最多的代码就是MFC的类库。

一个新的编程范式提出和流行并不见得就是各方面都强于之前的，而是因为某些特定的领域出现了一些现有的范式难以解决的问题而已。就像函数式其实非常古老了，最近突然流行起来无非是其天然适合高并发的环境罢了。

编程（程序设计）实际上是一个对现实世界中的事物抽象，并由计算机语言实现的过程。

核心的步骤就包含三个：理解、抽象、实现。

不同的理解思路，会导致完全不同的抽象结果，不同的抽象结果就会提供各不同的理解。

最后根据理解和抽象，由特定的语言完成时间，但其结果要想完全理解还需要前两个步骤支撑。

有点像建筑中的“房子是什么，房地产设计，盖房子”。

面向对象设计原则是OOPS编程的核心，学习面向对象编程像“抽象”、“封装”、“多态”、“继承”等基础知识是重要的，但同时为了创建简洁、模块化的设计，了解这些设计原则也同等重要。

(设计原则)底线是永远追求高内聚、低耦合的编码或设计。Apache和Sun的开源代码是学习和OOPS设计原则的良好范例。它们向我们展示了，设计原则在编程中是如何使用的。JDK使用了一些设计原则：BorderFactory类中的工厂模式、Runtime类中的单例模式、io类中的装饰器模式。顺便说一句，如果您真的对编码原则感兴趣，请阅读JoshuaBloch的Effective，他编写过API。我个人最喜欢的关于面向对象设计模式的是KathySierra的HeadFirstDesignPattern(深入浅出设计模式)，以及其它的关于深入浅出面向对象分析和设计。这些书对编写更好的代码有很大帮助，充分利用各种面向对象和SOLID的设计模式。

虽然学习设计模式(原则)最好的方法是现实中的例子和理解违反设计原则带来的不便，本文的宗旨是向那些没有接触过或正处于学习阶段的程序员介绍面向对象设计原则。

DRY_Don’trepeatyourself

我们第一个面向对象设计原则是：DRY，从名称可以看出DRY(don’trepeatyourself)意思是不写重复代码，而是抽象成可复用的代码块。如果您有两处以上相同的代码块，请考虑把它们抽象成一个单独的方法；或者您多次使用了硬编码的值，请把它们设置成公共常量。这种面向对象设计原则的优点是易于维护。重要的是不要滥用此原则，重复不是针对代码而是针对功能来说。它的意思是，如果您使用通用代码来验证OrderID和SSN，这并不意味着它们是相同的或者他们今后将保持不变。通过把通用代码用于实现两种不同的功能，或者您把这两种不同的功能密切地联系在一起；当您的OrderID格式改变时，您的SSN验证代码将会中断。所以要当心这种耦合，而且不要把彼此之间没有任何关系却类似的代码组合在一起。

封装经常修改的代码

EncapsulateWhatChanges

在软件领域永远不变的是“变化”，所以把您认为或怀疑将来要被修改的代码封装起来。这种面向对象设计模式的优点是：易于测试和维护恰当封装的代码。如果您在用编程，那么请遵守以下原则：变量和方法的访问权限默认设置为私有，并且逐步放开它们的访问权限，例如从“private”到“protected”、“notpublic”。中的一些设计模式使用了封装，工厂设计模式就是一个例子，它封装了创建对象的代码而且提供了以下灵活性：后续生成新对象不影响现有的代码。

打开/关闭设计原则

OpenClosedDesignPrinciple

类、方法/函数应当是对扩展(新功能)开放，对修改闭合。这是另外一个优雅的SOLID设计原则，以防止有人修改通过测试的代码。理想情况下假如您添加了新功能，那么您的代码要经过测试，这就是打开/关闭设计原则的目标。顺便说一句，SOLID中的字母“O”指的是打开/关闭设计原则。

单一职责原则

SingleResponsibilityPrinciple(SRP)

单一职责原则是另外一个SOLID设计原则，SOLID中的字母“S”指的就是它。按照SRP，一个类修改的原因应当有且只有一个，或者一个类应当总是实现单一功能。如果您在中的一个类实现了多个功能，那么这些功能之间便产生了耦合关系；如果您修改其中的一个功能，您有可能就打破了这种耦合关系，那么就要进行另一轮测试以避免产生新的问题。

依赖注入/反转原则

DependencyInjectionorInversionprinciple

不要问框架的依赖注入功能将会给你带来什么益处，依赖注入功能在spring框架里已经很好的得到了实现，这一设计原则的优雅之处在于：DI框架注入的任何一个类都易于用模拟对象进行测试，并且更易于维护，因为创建对象的代码在框架里是集中的而且和客户端代码是隔离的。有多种方法可以实现依赖注入，例如使用字节码工具，其中一些AOP(面向切面编程)框架如切入点表达式或者spring里使用的代理。想对这种SOLID设计原则了解更多，请看IOC和DI设计模式中的例子。SOLID中的字母“D”指的就是这种设计原则。

优先使用组合而非继承

ForCompositionoverInheritance

如果可以的话，要优先使用组合而非继承。你们中的一些人可能为此争论，但我发现组合比继承更有灵活性。组合允许在运行时通过设置属性修改一个类的行为，通过使用多态即以接口的形式实现类之间的组合关系，并且为修改组合关系提供了灵活性。甚至Effective也建议优先使用组合而非继承。

里氏替换原则

LiskovSubstitutionPrincipleLSP

根据里氏替换原则，父类出现的地方可以用子类来替换，例如父类的方法或函数被子类对象替换应该没有任何问题。LSP和单一职责原则、接口隔离原则密切相关。如果一个父类的功能比其子类还要多，那么它可能不支持这一功能，而且也违反了LSP设计原则。为了遵循LSPSOLID设计原则，派生类或子类(相对父类比较)必须增强功能，而非减少。SOLID中的字母“L”指的就是LSP设计原则。

接口隔离原则

接口隔离原则指，如果不需要一个接口的功能，那么就不要实现此接口。这大多在以下情况发生：一个接口包含多种功能，而实现类只需要其中一种功能。接口设计是一种棘手的工作，因为一旦发布了接口，您就不能修改它否则会影响实现该接口的类。在中这种设计原则的另一个好处是：接口有一个特点，任何类使用它之前都要实现该接口所有的方法，所以使用功能单一的接口意味着实现更少的方法。

编程以接口(而非实现对象)为中心

编程总是以接口(而非实现对象)为中心，这会使代码的结构灵活，而且任何一个新的接口实现对象都能兼容现有代码结构。所以在中，变量、方法返回值、方法参数的数据类型请使用接口。这是许多程序员的建议，Effective以及headfirstdesignpattern等书也这样建议。

代理原则

不要期望一个类完成所有的功能，电脑培训认为可以适当地把一些功能交给代理类实现。代理原则的典范是：中的equals()和hashCode()方法。为了比较两个对象的内容是否相同，我们让用于比较的类本身完成对比工作而非它们的调用方。这种设计原则的好处是：没有重复编码而且很容易修改类的行为。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

思想的区别 结构化程序设计思想：在编程之前，先对程序系统根据业务需要进行整体的规划，描述出系统的流程。对程序系统进行模块化分和功能分配。设计出各种图表，指明数据的流向。

缺点：

1）缺少扩展性：进行程序设计的时候只将系统着眼于现有业务功能的实现，没有考虑到系统将来的业务变化情况。

2）灵活性差：进行程序设计，时没有对软件的系统的设计和实现进行合理的分工。

3）违反职能均衡原则。面向对象程序设计思想：在进行程序开发之前，先将程序的业务变化进行合理的分析，将程序中的代码与现实中的事物结构特征结合起来考虑。优点：实现了程序系统的可扩展性，可重用性，可维护性。缺点：体系庞大，难以掌握。

面向对象程序设计和结构化程序设计应用程序的区别区别：对数据和对数据的处理的区别面向对象应用程序将程序中的数据和对数据的 *** 作描述为一个整体，即类。

面向对象最重要的功能，是在语言层面，做出一些归类和划分。这给出了额外信息，有助于提高程序的可维护性，和可控。

也就是说，传达出，数据之间，函数之间，数据和函数之间的疏密和逻辑关系。通过对复杂任务，化整为零，实现分工协作和任务简化，这类似分治法。

同时，在编程模型中建立了对象的概念，通常更加切合人类的思考习惯，通过合理的封装，设计良好的对象接口，从而帮助人们更容易开发和管控自己的代码。

关于楼主提问，我补充下，OO 的选择 和 GUI 是完全独立无关的。GUI 也可以以面向过程的方式开发。在适合 OO 的各种场合（不一定是 GUI），采用 OO 来编程当然也是十分有益的。

然后面向对象的使用，人们很容易僵化，要谨防：

（1）过度OO。不必要的加深对象关系网络深度，会降低程序的可维护性和可控性，最终失控而导致项目失败。

（2）一些人对面向过程才去完全对立，这是一种教条主义和僵硬呆板的理解。实际上绝对的 OO，必然不是最正确的。不管强行 OO 只能是弄巧成拙的愚蠢人。意识不到，OO 并不是适用所有模型，或者说，很多场合，没有必要 OO和没有 OO 的特别收益。

实际情况，一般是 OO 和 面向过程两者的合理结合组合，来解决问题。而不是非此即彼的关系。

以上就是关于面向对象方法和结构化方法各自的特点与利弊全部的内容，包括:面向对象方法和结构化方法各自的特点与利弊、面向对象程序设计和结构化程序设计各有什么优缺点、面向对象程序设计比传统的面向过程程序设计更有什么好处等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！