面向对象编程（Object Oriented Programming，OOP，面向对象程序设计）是一种计算机编程架构。OOP 的一条基本原则是计算机程序是由单个能够起到子程序作用的单元或对象组合而成。OOP 达到了软件工程的三个主要目标：重用性、灵活性和扩展性。为了实现整体运算，每个对象都能够接收信息、处理数据和向其它对象发送信息。

面向对象编程


面向对象编程-OOP 主要有以下的概念和组件
什么是OOP？
　　OOP的许多原始思想都来之于Simula语言，并在Smalltalk语言的完善和标准化过程中得到更多的扩展和对以前的思想的重新注解。可以说OO思想和OOPL几乎是同步发展相互促进的。与函数式程序设计（functional-programming）和逻辑式程序设计（logic-programming）所代表的接近于机器的实际计算模型所不同的是，OOP几乎没有引入精确的数学描叙，而是倾向于建立一个对象模型，它能够近似的反映应用领域内的实体之间的关系，其本质是更接近于一种人类认知事物所采用的哲学观的计算模型。由此，导致了一个自然的话题，那就是OOP到底是什么？[D&T1988][B.S1991].。在OOP中，对象作为计算主体，拥有自己的名称，状态以及接受外界消息的接口。在对象模型中，产生新对象，旧对象销毁，发送消息，响应消息就构成OOP计算模型的根本。
　　对象的产生有两种基本方式。一种是以原型（prototype）对象为基础产生新的对象。一种是以类（class）为基础产生新对象。原型的概念已经在认知心理学中被用来解释概念学习的递增特性，原型模型本身就是企图通过提供一个有代表性的对象为基础来产生各种新的对象，并由此继续产生更符合实际应用的对象。而原型-委托也是OOP中的对象抽象，代码共享机制中的一种。一个类提供了一个或者多个对象的通用性描叙。从形式化的观点看，类与类型有关，因此一个类相当于是从该类中产生的实例的集合。而这样的观点也会带来一些矛盾，比较典型的就是在继承体系下，子集（子类）对象和父集（父类）对象之间的行为相融性可能很难达到，这也就是OOP中常被引用的---子类型（subtype）不等于子类（subclass）[Budd2002]。而在一种所有皆对象的世界观背景下，在类模型基础上还诞生出了一种拥有元类（metaclass）的新对象模型。即类本身也是一种其他类的对象。以上三种根本不同的观点各自定义了三种基于类（class-based）,基于原型（prototype-based）和基于元类（metaclass-based）的对象模型。而这三种对象模型也就导致了许多不同的程序设计语言（如果我们暂时把静态与动态的差别放在一边）。是的，我们经常接触的C++, Java都是使用基于类的对象模型，但除此之外还有很多我们所没有接触的OOPL采用了完全不一样的对象模型，他们是在用另外一种观点诠释OOP的内涵。

面向对象编程
组件 － 数据和功能一起在运行着的计算机程序中形成的单元，组件在 OOP 计算机程序中是模块和结构化的基础。
抽象性 － 程序有能力忽略正在处理中信息的某些方面，即对信息主要方面关注的能力。
封装 － 也叫做信息封装：确保组件不会以不可预期的方式改变其它组件的内部状态；只有在那些提供了内部状态改变方法的组件中，才可以访问其内部状态。每类组件都提供了一个与其它组件联系的接口，并规定了其它组件进行调用的方法。
多态性 － 组件的引用和类集会涉及到其它许多不同类型的组件，而且引用组件所产生的结果得依据实际调用的类型。
继承性 － 允许在现存的组件基础上创建子类组件，这统一并增强了多态性和封装性。典型地来说就是用类来对组件进行分组，而且还可以定义新类为现存的类的扩展，这样就可以将类组织成树形或网状结构，这体现了动作的通用性。
　　


面向对象编程
由于抽象性、封装性、重用性以及便于使用等方面的原因，以组件为基础的编程在脚本语言中已经变得特别流行。Python 和 Ruby 是最近才出现的语言，在开发时完全采用了 OOP 的思想，而流行的 Perl 脚本语言从版本5开始也慢慢地加入了新的面向对象的功能组件。用组件代替“现实”上的实体成为 JavaScript（ECMAScript） 得以流行的原因，有论证表明对组件进行适当的组合就可以在英特网上代替 HTML 和 XML 的文档对象模型（DOM）。 （JavaScript并不是真正的面向对象语言）
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的内涵。
什么是oop的基本思想呢？把组件的实现和接口分开，并且让组件具有多态性。不过，两者还是有根本的不同。oop强调在程序构造中语言要素的语法。你必须得继承，使用类，使用对象，对象传递消息。gp不关心你继承或是不继承，它的开端是分析产品的分类，有些什么种类，他们的行为如何。就是说，两件东西相等意味着什么？怎样正确地定义相等操作？不单单是相等操作那么简单，你往深处分析就会发现“相等”这个一般观念意味着两个对象部分，或者至少基本部分是相等的，据此我们就可以有一个通用的相等操作。再说对象的种类。假设存在一个顺序序列和一组对于顺序序列的操作。那么这些操作的语义是什么？从复杂度权衡的角度看，我们应该向用户提供什么样的顺序序列？该种序列上存在那些操作？那种排序是我们需要的？只有对这些组件的概念型分类搞清楚了，我们才能提到实现的问题：使用模板、继承还是宏？使用什么语言和技术？gp的基本观点是把抽象的软件组件和它们的行为用标准的分类学分类，出发点就是要建造真实的、高效的和不取决于语言的算法和数据结构。当然最终的载体还是语言，没有语言没法编程。stl使用c ，你也可以用ada来实现，用其他的语言来实现也行，结果会有所不同，但基本的东西是一样的。到处都要用到二分查找和排序，而这就是人们正在做的。对于容器的语义，不同的语言会带来轻微的不同。但是基本的区别很清楚是gp所依存的语义，以及语义分解。例如，我们决定需要一个组件swap，然后指出这个组件在不同的语言中如果工作。显然重点是语义以及语义分类。而oop所强调的（我认为是过分强调的）是清楚的定义类之间的层次关系。oop告诉了你如何建立层次关系，却没有告诉你这些关系的实质。
（这段不太好理解，有一些术语可能要过一段时间才会有合适的中文翻译——译者）
面向对象的编程方法OOP是九十年代才流行的一种软件编程方法。它强调对象的“抽象”、“封装”、“继承”、“多态”。我们讲程序设计是由“数据结构” “算法”组成的。从宏观的角度讲，OOP下的对象是以编程为中心的，是面向程序的对象。我们今天要讲的OOD是面向信息的对象，是以用户信息为中心的。
面向对象编程-OOP技术的历史
　　面向对象技术最初是从面向对象的程序设计开始的，它的出现以60年代simula语言为标志。80年代中后期，面向对象程序设计逐渐成熟，被计算机界理解和接受，人们又开始进一步考虑面向对象的开发问题。这就是九十年代以Microsoft Visual系列OOP软件的流行的背景。
　　传统的结构化分析与设计开发方法是一个线性过程，因此，传统的结构化分析与设计方法要求现实系统的业务管理规范，处理数据齐全，用户能全面完整地其业务需求。
　　传统的软件结构和设计方法难以适应软件生产自动化的要求，因为它以过程为中心进行功能组合，软件的扩充和复用能力很差。
　　对象是对现实世界实体的模拟，因面能更容易地理解需求，即使用户和分析者之间具有不同的教育背景和工作特点，也可很好地沟通。
　　区别面向对象的开发和传统过程的开发的要素有：对象识别和抽象、封装、多态性和继承。
　　对象(Object)是一个现实实体的抽象，由现实实体的过程或信息牲来定义。一个对象可被认为是一个把数据（属性）和程序（方法）封装在一起的实体，这个程序产生该对象的动作或对它接受到的外界信号的反应。这些对象操作有时称为方法。对象是个动态的概念,其中的属性反映了对象当前的状态。
　　类(Class)用来描述具有相同的属性和方法的对象的集合。它定义了该集合中每个对象所共有的属性和方法。对象是类的实例。
　　由上分析不难看出，尽管OOP技术更看中用户的对象模型，但其目的都是以编程为目的的，而不是以用户的信息为中心的，总想把用户的信息纳入到某个用户不感兴趣的“程序对象”中。
面向对象编程-OOP 的优缺点
OOP 的优点：使人们的编程与实际的世界更加接近，所有的对象被赋予属性和方法，结果编程就更加富有人性化。
OOP 的也有缺点，就 C 而言，由于面向更高的逻辑抽象层，使得 C 在实现的时候，不得不做出性能上面的牺牲，有时候甚至是致命的 ( 所有对象的属性都经过内置多重指针的间接引用是其性能损失的主要原因之一；不过，笔者的局限性在于未使用过 VC 外的面向对象语言，所以不是十分肯定，哈哈，有人笑出来了… )。
在计算机速度飞速发展的今天，你可能会说，一丁点的性能牺牲没什么大不了。是的，从面向对象的角度，使的编程的结构更加清晰完整，数据更加独立和易于管理，性能的牺牲可以带来这么多的好处，没有理由不做稳赚的生意吧？
不过，在某些对速度要求极高特殊场合，例如你做的是电信的交换系统，每秒钟有超过百万的人同时进行电话交换，如果，每一个数据交换过程都是一个对象，那么总的性能损失将是天文数字！！
或者这个例子不够贴身，再举个例子吧。假如你受聘于一个游戏设计公司，老板希望做出来的游戏可以更多的兼顾到更多的电脑使用者，游戏每秒钟的运行的帧可以更多，子弹和爆炸物可以更多、更华丽。那么，你会发现使用 C 会使你的程序变得笨拙，无法满足你的需求，除非你非得要你的游戏运行于奔腾四的机器上 ( 如果不是，而你又坚持用 C 的对象编程，那么请减少主角的枪的威力吧 )。
如果你是冥顽不宁的人，你说不相信 OOP 会有性能上的损失，那么，我记得曾看到在 CSDN 上关于 VB 和 VC 执行效率的讨论的文章，讲述的就是使用了 MFC 以后，执行效率甚至低于 VB 开发出来的东西。请各位验证一下：如果使用的是纯粹的 C 语言语法的话，那么一定会比在 VB 编出来的东西要快很多 ( GetTickCount 函数可以查阅 MSDN ,如果想更加精确一些，可以使用 QueryPerformanceCounter 函数 )。
面向对象编程-OOP的未来
在未来三年，程序员编写代码的方式会发生那些变化？
现在有一个趋势，编译器厂商试图把其特有的“对象模型”和图形界面(GUI)细节推销给用户。比如微软的COM和Inprise的类属性“properties”。对于用户来说，这既不必要，也不情愿。我所希望看到的程序库，应该是用标准C 打造，界面灵活，值得信赖的程序库。通常，这些界面应该是平台无关的。C 的表达能力极强，即使不使用大量的宏，也应该足以达成这一要求。就算有些地方无法百分之百的遵守这一原则，也应该将对于平台和厂家的依赖性限制起来。这个目标的完成情况，可以反映软件工具产业对于应用程序开发行业的关注程度。我怀疑目前对于那些独立的、跨平台厂商来说，并不存在相应的市场。如果能够建立这样的市场，也许能够促进厂商们为客户做出“真正有用的”产品。
在网络应用的增长中，一个很重要的部分是小型移动设备和特殊Internet设备的爆炸性增长。这些设备各有各的操作系统，或者只在某种特定的设备领域内有共同的操作系统。我们现在还可以一一列举出这些设备——家庭接入设备、蜂窝电话、电子报纸、PDA、自动网络设备等等。但是这些设备领域的数量和深入程度将会很快变得难以估量。我们都知道这个市场大得惊人，PC的兴起与之相比不过小菜一碟。因此在这些设备的应用程序市场上，竞争将会相当残酷。获胜的重要手段之一，就是尽快进入市场。开发人员需要优秀的工具，迅速高效地撰写和调试他们的软件。平台无关性也是制胜秘诀之一，它使得程序员能够开发出支持多种设备平台的软件。
面向对象编程-不同OOP语言各有什么优势和劣势？
Stroustrup: C 的优点自始至终都是这么几条：灵活、高效，而且并非专有语言。现在ISO C 标准的出现，巩固了最后一点。
我认为C 的高效是它最基本的优点。这种高效来自于其特有的数据和计算模型，较之Java和C#，这种模型更加贴近机器。不过，哪些程序才真正地渴望这么高的效率？这是个问题。我认为这类程序非常多。人们对于计算机的期望，永远都超越硬件科技的发展速度。很显然，Java和C#的设计者的想法不同，他们认为，在很多地方效率问题无关紧要。
C 主要的缺点，归罪于糟糕的教育（是那些始终认为C 是个纯粹面向对象语言的人，和那些把C 当成C语言变体的人导致了这种情况），归罪于不同平台上的不一致性，归罪于不完整、不标准的编译器实现，归罪于平台无关的系统级程序库的缺少。
这些问题归于一点，就是缺乏一个卓越的厂商，能够满足整个C 社区的需求，勇于投入大量的资金开发必要的程序库。

面向对象编程五大原则
作者: jiarui1230 , 　出处:IT专家网论坛,　责任编辑: 包春林,　2008-05-07 04:00
　　在面向对象设计中，如何通过很小的设计改变就可以应对设计需求的变化，这是令设计者极为关注的问题。为此不少OO先驱提出了很多有关面向对象的设计原则用于指导OO的设计和开发。下面是几条与类设计相关的设计原则。

　　单一职责原则SRP：Single Responsibility Principle

　　开放封闭原则OCP：Open-Close Principle

　　Liskov替换原则LSP：Liskov Substitution Principle

　　依赖倒置原则DIP：Dependency Invertion Principle

　　接口隔离原则ISP：Interface Separate Principle

　　在面向对象设计中，如何通过很小的设计改变就可以应对设计需求的变化，这是令设计者极为关注的问题。为此不少OO先驱提出了很多有关面向对象的设计原则用于指导OO的设计和开发。下面是几条与类设计相关的设计原则。

　　1. 开闭原则(the Open Closed Principle OCP)

　　一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向对象设计的方法，是软件工程设计方法的重要原则之一。我们以收音机的例子为例，讲述面向对象的开闭原则。我们收听节目时需要打开收音机电源，对准电台频率和进行音量调节。但是对于不同的收音机，实现这三个步骤的细节往往有所不同。比如自动收缩电台的收音机和按钮式收缩在操作细节上并不相同。因此，我们不太可能针对每种不同类型的收音机通过一个收音机类来实现(通过重载)这些不同的操作方式。但是我们可以定义一个收音机接口，提供开机、关机、增加频率、降低频率、增加音量、降低音量六个抽象方法。不同的收音机继承并实现这六个抽象方法。这样新增收音机类型不会影响其它原有的收音机类型，收音机类型扩展极为方便。此外，已存在的收音机类型在修改其操作方法时也不会影响到其它类型的收音机。

　　2. 替换原则 (the Liskov Substitution Principle LSP)

　　子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC (Design by Contract) 的概念推出。

　　我们以学生为例，夜校生为学生的子类，因此在任何学生可以出现的地方，夜校生均可出现。这个例子有些牵强，一个能够反映这个原则的例子时圆和椭圆，圆是椭圆的一个特殊子类。因此任何出现椭圆的地方，圆均可以出现。但反过来就可能行不通。

　　运用替换原则时，我们尽量把类B设计为抽象类或者接口，让C类继承类B(接口B)并实现操作A和操作B，运行时，类C实例替换B，这样我们即可进行新类的扩展(继承类B或接口B)，同时无须对类A进行修改。

　　3. 依赖原则 (the Dependency Inversion Principle DIP)

　　在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。

　　在结构化设计中，我们可以看到底层的模块是对高层抽象模块的实现(高层抽象模块通过调用底层模块)，这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化方法的一个"硬伤"。

　　面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。

　　为此，我们在进行业务设计时，应尽量在接口或抽象类中定义业务方法的原型，并通过具体的实现类(子类)来实现该业务方法，业务方法内容的修改将不会影响到运行时业务方法的调用。

　　4. 接口分离原则(the Interface Segregation Principle ISP)

　　采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。

　　ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植性将大打折扣。

　　这个原则的本质相当简单。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。

　　以上四个原则是面向对象中常常用到的原则。此外，除上述四原则外，还有一些常用的经验诸如类结构层次以三到四层为宜、类的职责明确化(一个类对应一个具体职责)等可供我们在进行面向对象设计参考。但就上面的几个原则看来，我们看到这些类在几何分布上呈现树型拓扑的关系，这是一种良好、开放式的线性关系、具有较低的设计复杂度。一般说来，在软件设计中我们应当尽量避免出现带有闭包、循环的设计关系，它们反映的是较大的耦合度和设计复杂化。