OOP知识---对OOA\OOD\OOP思想
面向对象编程（Object Oriented Programming，OOP，面向对象程序设计）是一种计算机编程架构。OOP 的一条基本原则是计算机程序是由单个能够起到子程序作用的单元或对象组合而成。OOP 达到了软件工程的三个主要目标：重用性、灵活性和扩展性。为了实现整体运算，每个对象都能够接收信息、处理数据和向其它对象发送信息。OOP 主要有以下的概念和组件：
组件－数据和功能一起在运行着的计算机程序中形成的单元，组件在OOP计算机程序中是模块和结构化的基础。
抽象性－程序有能力忽略正在处理中信息的某些方面，即对信息主要方面关注的能力。
封装－也叫做信息封装：确保组件不会以不可预期的方式改变其它组件的内部状态；只有在那些提供了内部状态改变方法的组件中，才可以访问其内部状态。每类组件都提供了一个与其它组件联系的接口，并规定了其它组件进行调用的方法。
多态性－组件的引用和类集会涉及到其它许多不同类型的组件，而且引用组件所产生的结果得依据实际调用的类型。
继承性－允许在现存的组件基础上创建子类组件，这统一并增强了多态性和封装性。典型地来说就是用类来对组件进行分组，而且还可以定义新类为现存的类的扩展，这样就可以将类组织成树形或网状结构，这体现了动作的通用性。
由于抽象性、封装性、重用性以及便于使用等方面的原因，以组件为基础的编程在脚本语言中已经变得特别流行。Python和Ruby是最近才出现的语言，在开发时完全采用了OOP的思想，而流行的Perl脚本语言从版本5开始也慢慢地加入了新的面向对象的功能组件。用组件代替“现实”上的实体成为JavaScript（ECMAScript） 得以流行的原因，有论证表明对组件进行适当的组合就可以在英特网上代替 HTML 和 XML 的文档对象模型（DOM）。
设计模式、技术和直觉构成严峻的挑战。这是选择编程语言之前必须认识到的，尽管不同语言的设计特性可能促进或者阻碍这一转化。
在网络应用的增长中，一个很重要的部分是小型移动设备和特殊Internet设备的爆炸性增长。这些设备各有各的操作系统，或者只在某种特定的设备领域内有共同的操作系统。我们现在还可以一一列举出这些设备——家庭接入设备、蜂窝电话、电子报纸、PDA、自动网络设备等等。但是这些设备领域的数量和深入程度将会很快变得难以估量。我们都知道这个市场大得惊人，PC的兴起与之相比不过小菜一碟。因此在这些设备的应用程序市场上，竞争将会相当残酷。获胜的重要手段之一，就是尽快进入市场。开发人员需要优秀的工具，迅速高效地撰写和调试他们的软件。平台无关性也是制胜秘诀之一，它使得程序员能够开发出支持多种设备平台的软件。
预期的另一个变化是，我们对于代码(Java)和数据(XML)协同型应用程序的开发能力将会不断提高。这种协同是开发强大应用程序的核心目标之一。我们从XML的迅速流行和ebXML规范的进展中，已经看到了这个趋势。ebXML是一个针对电子商务和国际贸易的，基于XML的开放式基础构架，由联合国贸易促进和电子商务中心(UN/CEFACT)与结构性信息标准推进组织(OASIS)共同开发。
我们能否期望出现一个真正的面向组件(component-oriented)的语言？它的创造者会是谁呢？
Stroustrup: 这个领域中之所以缺乏成果，正是因为人们——主要是那些非程序员们——对“组件”这个意义含糊的字眼寄予了太多的期望。这些人士梦想，有朝一日，组件会以某种方式把程序员赶出历史舞台。以后那些称职的“设计员”只需利用预先调整好的组件，把鼠标拖一拖放一放，就把系统组合出来。对于软件工具厂商来说，这种想法还有另一层意义，他们认为，到时候只有他们才保留有必要的技术，有能力编写这样的组件。
这种想法有一个最基本的谬误：这种组件很难获得广泛欢迎。一个单独的组件或框架(framework)，如果能够满足一个应用程序或者一个产业领域对所提出的大部分要求的话，对于其制造者来说就是划算的产品，而且技术上也不是很困难。可是该产业内的几个竞争者很快就会发现，如果所有人都采用这些组件，那么彼此之间的产品就会变得天下大同，没什么区别，他们将沦为简单的办事员，主要利润都将钻进那些组件/框架供应商的腰包里！
小“组件”很有用，不过产生不了预期的杠杆效应。中型的、更通用的组件非常有用，但是构造时需要非同寻常的弹性。
组件－数据和功能一起在运行着的计算机程序中形成的单元，组件在OOP计算机程序中是模块和结构化的基础。
抽象性－程序有能力忽略正在处理中信息的某些方面，即对信息主要方面关注的能力。
封装－也叫做信息封装：确保组件不会以不可预期的方式改变其它组件的内部状态；只有在那些提供了内部状态改变方法的组件中，才可以访问其内部状态。每类组件都提供了一个与其它组件联系的接口，并规定了其它组件进行调用的方法。
多态性－组件的引用和类集会涉及到其它许多不同类型的组件，而且引用组件所产生的结果得依据实际调用的类型。
继承性－允许在现存的组件基础上创建子类组件，这统一并增强了多态性和封装性。典型地来说就是用类来对组件进行分组，而且还可以定义新类为现存的类的扩展，这样就可以将类组织成树形或网状结构，这体现了动作的通用性。
由于抽象性、封装性、重用性以及便于使用等方面的原因，以组件为基础的编程在脚本语言中已经变得特别流行。Python和Ruby是最近才出现的语言，在开发时完全采用了OOP的思想，而流行的Perl脚本语言从版本5开始也慢慢地加入了新的面向对象的功能组件。用组件代替“现实”上的实体成为JavaScript（ECMAScript） 得以流行的原因，有论证表明对组件进行适当的组合就可以在英特网上代替 HTML 和 XML 的文档对象模型（DOM）。
设计模式、技术和直觉构成严峻的挑战。这是选择编程语言之前必须认识到的，尽管不同语言的设计特性可能促进或者阻碍这一转化。
在网络应用的增长中，一个很重要的部分是小型移动设备和特殊Internet设备的爆炸性增长。这些设备各有各的操作系统，或者只在某种特定的设备领域内有共同的操作系统。我们现在还可以一一列举出这些设备——家庭接入设备、蜂窝电话、电子报纸、PDA、自动网络设备等等。但是这些设备领域的数量和深入程度将会很快变得难以估量。我们都知道这个市场大得惊人，PC的兴起与之相比不过小菜一碟。因此在这些设备的应用程序市场上，竞争将会相当残酷。获胜的重要手段之一，就是尽快进入市场。开发人员需要优秀的工具，迅速高效地撰写和调试他们的软件。平台无关性也是制胜秘诀之一，它使得程序员能够开发出支持多种设备平台的软件。
预期的另一个变化是，我们对于代码(Java)和数据(XML)协同型应用程序的开发能力将会不断提高。这种协同是开发强大应用程序的核心目标之一。我们从XML的迅速流行和ebXML规范的进展中，已经看到了这个趋势。ebXML是一个针对电子商务和国际贸易的，基于XML的开放式基础构架，由联合国贸易促进和电子商务中心(UN/CEFACT)与结构性信息标准推进组织(OASIS)共同开发。
我们能否期望出现一个真正的面向组件(component-oriented)的语言？它的创造者会是谁呢？
Stroustrup: 这个领域中之所以缺乏成果，正是因为人们——主要是那些非程序员们——对“组件”这个意义含糊的字眼寄予了太多的期望。这些人士梦想，有朝一日，组件会以某种方式把程序员赶出历史舞台。以后那些称职的“设计员”只需利用预先调整好的组件，把鼠标拖一拖放一放，就把系统组合出来。对于软件工具厂商来说，这种想法还有另一层意义，他们认为，到时候只有他们才保留有必要的技术，有能力编写这样的组件。
这种想法有一个最基本的谬误：这种组件很难获得广泛欢迎。一个单独的组件或框架(framework)，如果能够满足一个应用程序或者一个产业领域对所提出的大部分要求的话，对于其制造者来说就是划算的产品，而且技术上也不是很困难。可是该产业内的几个竞争者很快就会发现，如果所有人都采用这些组件，那么彼此之间的产品就会变得天下大同，没什么区别，他们将沦为简单的办事员，主要利润都将钻进那些组件/框架供应商的腰包里！
小“组件”很有用，不过产生不了预期的杠杆效应。中型的、更通用的组件非常有用，但是构造时需要非同寻常的弹性。
