什么是OOP

Posted 2023-04-04

OOP即面向对象程序设计，全称为Object Oriented Programming，是一种计算机编程架构。其本质是以建立模型体现出来的抽象思维过程和面向对象的方法，模型是用来反映现实世界中事物特征的。

面向对象程序设计以对象为核心，该方法认为程序由一系列对象组成。类是对现实世界的抽象，包括表示静态属性的数据和对数据的操作，对象是类的实例化。对象间通过消息传递相互通信，来模拟现实世界中不同实体间的联系。在面向对象的程序设计中，对象是组成程序的基本模块。

扩展资料：

面向对象程序设计的优点：

1、数据抽象的概念可以在保持外部接口不变的情况下改变内部实现，从而减少甚至避免对外界的干扰；

2、通过继承大幅减少冗余的代码，并可以方便地扩展现有代码，提高编码效率，也减低了出错概率，降低软件维护的难度；

3、结合面向对象分析、面向对象设计，允许将问题域中的对象直接映射到程序中，减少软件开发过程中中间环节的转换过程；

4、通过对对象的辨别、划分可以将软件系统分割为若干相对为独立的部分，在一定程度上更便于控制软件复杂度；

5、以对象为中心的设计可以帮助开发人员从静态（属性）和动态（方法）两个方面把握问题，从而更好地实现系统。

参考资料来源：百度百科-OOP

参考技术A 　　是面向对象编程（Object Oriented Programming，OOP，面向对象程序设计）是一种计算机编程架构。OOP 的一条基本原则是计算机程序是由单个能够起到子程序作用的单元或对象组合而成。
　　简介：
　　OOP: Object Oriented Programming,面向对象的程序设计。所谓“对象”在显式支持面向对象的语言中，一般是指类在内存中装载的实例，具有相关的成员变量和成员函数（也称为：方法）。面向对象的程序设计完全不同于传统的面向过程程序设计，它大大地降低了软件开发的难度，使编程就像搭积木一样简单，是当今电脑编程的一股势不可挡的潮流。
　　OOP 达到了软件工程的三个主要目标：重用性、灵活性和扩展性。为了实现整体运算，每个对象都能够接收信息、处理数据和向其它对象发送信息。OOP 主要有以下的概念和组件：
　　组件 － 数据和功能一起在运行着的计算机程序中形成的单元，组件在 OOP 计算机程序中是模块和结构化的基础。
　　抽象性 － 程序有能力忽略正在处理中信息的某些方面，即对信息主要方面关注的能力。
　　封装 － 也叫做信息封装：确保组件不会以不可预期的方式改变其它组件的内部状态；只有在那些提供了内部状态改变方法的组件中，才可以访问其内部状态。每类组件都提供了一个与其它组件联系的接口，并规定了其它组件进行调用的方法。
　　多态性 － 组件的引用和类集会涉及到其它许多不同类型的组件，而且引用组件所产生的结果得依据实际调用的类型。
　　继承性 － 允许在现存的组件基础上创建子类组件，这统一并增强了多态性和封装性。典型地来说就是用类来对组件进行分组，而且还可以定义新类为现存的类的扩展，这样就可以将类组织成树形或网状结构，这体现了动作的通用性。
　　由于抽象性、封装性、重用性以及便于使用等方面的原因，以组件为基础的编程在脚本语言中已经变得特别流行。Python 和 Ruby 是最近才出现的语言，在开发时完全采用了 OOP 的思想，而流行的 Perl 脚本语言从版本5开始也慢慢地加入了新的面向对象的功能组件。用组件代替“现实”上的实体成为 javascript（ECMAScript） 得以流行的原因，有论证表明对组件进行适当的组合就可以在英特网上代替 html 和 XML 的文档对象模型（DOM）。 参考技术B 在本文（也是本系列的第五部分）中，Teodor 解释了什么是面向对象编程，何时使用它以及它是如何在 Perl 中工作的。面向对象编程（OOP）是一种强大的编程技术，但它不是万能药。优秀的程序员必须理解如何使用它，并且必须知道何时依赖更传统的编程技术。在 Perl 中使用 OOP 很简单。与 C++ 和 Java 等限制性更强的 OOP 语言不同，Perl 中的 OOP 很少对程序员施加强制性约束。OOP 是对每一名程序员的工具箱的必要补充，并且是用于扩展可用 Perl 解决的问题范围的非常有用的技术。什么是面向对象编程（OOP）？OOP 是一种用于解决问题的编程方法或通用方法。与之相反，算法是用于解决特定问题的 特定方法。OOP 天生是一种强有力的方法；它往往使过程型和函数型编程方法与该问题较少相关，并且除非它与过程型和函数型编程方法的混合对其极其有益，否则它们之间不会很好地结合在一起。在 Perl 中，这种强大的力量有所减弱，但仍然很好地存在着。 本文讨论 Perl 中的 OOP 对比函数型和过程型编程的基本知识，并演示如何在 Perl 程序和模块中使用 OOP。请记住，本文只是一篇概述，而不是对 Perl 中 OOP 所有方面的详尽解释。这样的详尽解释需要几本书才能讲完，并且已经被写过几次了。有关详细信息，请参阅本文稍后的 参考资料。 究竟什么是 OOP？OOP 是一种通过使用对象来解决问题的技术。在编程术语中，对象是这样一些实体：它们的特性和行为是解决手头问题所必需的。这个定义本应该更详细些，但是做不到，因为当今计算机行业中 OOP 方法的种类之多简直难以想象。在Perl 编程环境中，OOP 并不是使用该语言所必需的。Perl 版本 5 和更高版本鼓励使用 OOP，但确切地说不要求这样做。所有 Perl 库都是模块，这意味着它们至少使用 OOP 的基本部分。而且，大多数 Perl 库都作为对象实现，这意味着用户必须通过良好定义的接口将它们作为具有特定行为和特性的 OOP 实体来使用。回页首基本的 OO 编程语言特性通常，有三个语言特性是 OOP 编程语言所必需的。它们是继承、多态性和封装。Perl 支持继承。当一个对象（子对象）使用另一个对象作为起点（父对象），并且随后在需要时修改其特性和行为时，就要用到 继承。子-父关系是 OOP 所必需的，因为它使得在其它对象基础上构建对象成为可能。这种重用是使 OOP 成为程序员宠儿的好处之一。 有两种继承：单一继承和多重继承。 单一继承要求子对象只有一个父对象，而 多重继承更自由（与实际生活一样，在编程过程中具有两个以上的父对象会导致混乱并使子对象难以工作，因此，不要过多使用多重继承）。尽管两个或两个以上的父对象实际上很少见，但 Perl 支持多重继承。 多态性（来自希腊语，表示“很多形态”）是使一个对象被看成另一个对象的技术。这有点复杂，那么我举个例子。比方说，您有一个绵羊牧场，里面有四只绵羊（绵羊属），但是您刚刚买了两只山羊（山羊属）和一只德国牧羊犬（犬科犬属）。您一共有多少动物？您得把所有的绵羊、山羊和狗加起来，结果是 7 只。其实您刚刚应用了多态性，即为了计算，把三种不同种类的动物当成一种通用类型（“动物”）对待。如果您把绵羊、山羊和狗当成哺乳动物看待，这就是一个简单的信心飞跃。生物学家每天都以这种方式使用多态性，而程序员则以从其它科学领域“窃用”（我是指“重用”）好主意闻名。Perl 完全支持 多态性。但它用得不是很频繁，因为 Perl 程序员看起来更喜欢用对象特性、而不是通过修改继承的行为来修改通用行为。这意味着您更可能看到创建三个 IO::Socket::INET 对象的代码：一个对象用于在端口 234 接收和发送 UDP 包、一个对象用于在端口 80 接收 TCP 包，还有一个对象在端口 1024 发送 TCP 包，而不大会看到对第一种情况使用 IO::Socket::INET::UDPTransceiver 、对第二种情况使用 IO::Socket::INET::TCPReceiver 而对第三种情况使用 IO::Socket::TCPTransmitter 的代码。这就象是在生物学术语中说狗和山羊都是哺乳动物，但是山羊属于山羊属，而狗属于犬属。 OOP 纯化论者认为每件事都应该正确分类，但是 Perl 程序员根本不是纯化论者。他们往往更不拘束于 OOP 规则，这使得他们在聚会中比 OOP 纯化论者更快乐。封装指的是以这样一种方式包含对象行为和特性：除非对象作者允许，否则用户无法访问该对象的行为和特性。在这种方式下，对象用户无法做不准他们做的事，无法访问不准他们访问的数据，并且通常是有害数据。Perl 通常用松弛的方法封装。请参阅 清单1。 回页首为什么说 OOP 是一种强有力的方法？返回到我们最初的 OOP 如何是一种强有力的方法这一主题，我们现在可以看到 OOP 结合了几个关键的概念，这使得它很难与过程型和函数型编程（PP 和 FP）混合使用。首先，PP 和 FP 都没有继承或类多态性的概念，因为在 PP 和 FP 中根本就没有类。在 PP 和 FP 中存在封装，但只在过程型级别，从来不作为类或对象属性封装。既然程序员不怕麻烦来使用这些基本的 OOP 工具，那就意味着程序员通常更可能对整个项目使用 OOP，而不是混合不兼容的方法。有人可能争论说所有程序最终都归结为指令的过程型执行，因此无论 OOP 程序实现得有多纯，每个 OOP 程序都在其函数（也称为方法）和创建第一个对象（该对象做其余工作）的代码中包含过程型代码。甚至象 Java 那样接近“纯”OOP 的语言都无法避免地需要一个 main() 函数。因此，看起来 OOP 只是 PP 的一个子集。但是这种 OOP 向序列指令的归结和实际为每个操作所执行的汇编程序指令一样，都不是系统架构设计师或程序员所关心的事。请记住，OOP 本身只是一种方法，而不是目的。 OOP 与过程型编程方法合作得不是很好，因为它集中在对象上，而过程型编程基于过程（我们将 过程大致定义为不使用 OOP 技术就可以得到的函数，而将 方法定义为只有在对象中才能得到的函数）。正如方法一样，过程只是由用户调用的函数，但是二者之间有一些差异。 过程不使用对象数据。必须在它们的参数列表中为它们传递数据，或者它们必须使用所在作用域中的数据。过程可以访问调用它时传递给它的任何数据，甚至整个程序的全局数据。方法应该只访问它们对象的数据。实际上，方法的函数作用域通常是包含该方法的对象。常常发现过程使用全局数据，尽管只有在绝对必要时才应该这样做。应该尽快重写使用全局数据的方法。过程通常用几个参数调用其它过程。方法应该只有几个参数，并且它们调用其它方法的次数比其它过程更多。函数型编程（FP）与 OOP 配合不好有几个原因。最重要的原因是 FP 基于用来解决问题的详细函数型方法，而 OOP 则使用对象来表达概念，并且，与 OOP 方法只能在包含它们的对象中使用不同，FP 过程得到处使用。综上所述，我们现在可以解释 Perl 为什么是混合 OOP、FP 和 PP 方法的最佳语言之一。回页首Perl 是如何将 OOP 与过程型和函数型编程结合起来的？Perl 是一种松弛的语言。它极力让程序员以他们认为方便的任何方式做他们想做的任何事。这与 Java 和 C++ 之类的语言截然不同。例如，如果程序员原本没有声明变量，Perl 乐于允许程序员自动创建变量（尽管不鼓励这样做，并且可以通过使用高度推荐的“use strict”编译指示阻止）。如果您要向自己的脚开枪，Perl 会给您十发子弹和一个激光瞄准镜，然后站在一旁鼓励您。因此，Perl 是一种非常便于滥用方法的语言。别害怕。没关系。例如，访问内部的对象数据、实时更改类和实时重定义方法都是允许的。Perl 方式是：允许程序员为了编码、调试和执行效率的目的而去打破规则。如果这有助于完成工作，那么没关系。因此，Perl 本身可能是程序员最好的朋友，也可能是最坏的敌人。如果混合 OOP、FP 和 PP 意味着打破规则，那么为什么任何人都想要混合 OOP、FP 和 PP 呢？让我们回头想想这个问题。什么是 OOP、FP 和 PP？它们只是现有的为编程团队服务的编程方法、概念集和规则集。OOP、FP 和 PP 是工具，每名程序员的首要工作就是要了解他的工具。如果一名程序员在排序散列时不能使用 FP 的 Schwartzian 变换，而是编写他自己的 Sort::Hashtable ，或者不能重用 Sys::Hostname 模块，而是编写过程代码来获得系统主机名，那么这个程序员是在浪费时间、精力和金钱，并且降低了代码质量和可靠性。 一个编程团队可能会因为它们最熟知的工具而沾沾自喜，对它们来说，这可能正是最坏的事。如果一个团队只使用象计算机编程行业那样令人冲动和充满创新的行业中所保证的可用工具的一部分，那么它在几年之后注定要变得毫无用处。程序员应该能够结合任何使工作更有效、代码更好以及使团队更具创新能力的方法。Perl 认可并鼓励这种态度。回页首OOP 的好处OOP 的好处太多，本文难以列举。正如我在前面提到的那样，有很多关于该主题的书籍。这些好处中的一小部分是：易于代码重用、代码质量的改进、一致的接口和可适应性。因为OOP 建立在类和对象的基础之上，所以重用 OO 代码意味着在需要时只需简单地导入类。至今为止，代码重用是使用 OOP 的唯一最主要原因，也是 OOP 在当今业界中的重要性和流行性日益增加的原因所在。这里有一些陷阱。例如，在当前的情况下，以前问题的解决方案可能不理想，并且文档库编制得很差，以至于理解和使用文档编制很差的库所花的时间可能与重新编写库的时间一样长。系统架构设计师的工作是看到和避免这些陷阱。使用OOP 可以提高代码质量，因为封装减少了数据毁坏（“友好之火”），而继承和多态性则减少了必须编写的新代码数量和复杂性。在代码质量和编程创新之间有一个微妙的平衡，这最好留给团队去发现，因为它完全取决于团队的构成和目的。OOP 继承和重用使得在代码中实现一致的接口变得简单，但是并不能说所有的 OO 代码都有一致的接口。程序员仍然必须遵循通用的体系结构。例如，团队应该在错误日志记录的格式和接口方面达成一致，最好通过一个允许日后扩展并且极其易用的示范模块接口来这样做。只有在那时，每名程序员才能承诺使用该接口，而不是无规则的 print 语句，因为他们会认识到在出现下一个错误日志记录函数时，学习该接口的努力不会白费。可适应性在编程中是一个有些含糊的概念。我愿意把它定义成对环境和用法更改的接受性和预见性。对于编写良好的软件来说，可适应性很重要，因为所有的软件必须随着外部世界而进化。编写良好的软件应该很容易进化。OOP 通过模块设计、改进的代码质量和一致的接口确保新操作系统或者新报告格式不要求对体系结构的核心作出根本更改，从而有助于软件的进化。回页首如何在 Perl 中使用 OOP不管您是否相信，Perl 中的 OOP 对初级和中级用户都不难，甚至对高级用户也没那么复杂。根据我们到目前为止所讨论的有关 OOP 的复杂工作方式，您可能不这么认为。然而，Perl 却乐意对程序员施加尽可能少的限制。Perl OOP 就象烤肉（恕我比喻不当）。每个人都带来自己的肉，并以自己喜爱的方式烤肉。甚至还有烤肉的团队精神也是那样，就象可以轻易在不相关的对象之间共享数据一样。我们必须采取的第一步是理解 Perl 包。包类似于 C++ 中的名称空间和 Java 中的库：象用来将数据限制在特定区域的围栏。然而，Perl 包只是为程序员提供建议。缺省情况下，Perl 不限制包之间的数据交换（尽管程序员可以通过词法变量这样做）。清单1. 包名、切换包、在包之间共享数据和包变量#!/usr/bin/perl # note: the following code will generate warnings with the -w switch, # and won‘t even compile with "use strict". It is meant to demonstrate # package and lexical variables. You should always "use strict". # pay attention to every line! # this is a global package variable; you shouldn‘t have any with "use strict" # it is implicitly in the package called "main" $global_sound = " "; package Cow; # the Cow package starts here # this is a package variable, accessible from any other package as $Cow::sound $sound = "moo"; # this is a lexical variable, accessible anywhere in this file my $extra_sound = "stampede"; package Pig; # the Pig package starts, Cow ends # this is a package variable, accessible from any other package as $Pig::sound $Pig::sound = "oink"; $::global_sound = "pigs do it better"; # another "main" package variable # we‘re back to the default (main) package package main; print "Cows go: ", $Cow::sound; # prints "moo" print "\nPigs go: ", $Pig::sound; # prints "oink" print "\nExtra sound: ", $extra_sound; # prints "stampede" print "\nWhat‘s this I hear: ", $sound; # $main::sound is undefined! print "\nEveryone says: ", $global_sound; # prints "pigs do it better" 请注意，可以在所有三个包（“main”、“Pig”和“Cow”）中访问文件作用域内的词法变量 $extra_sound ，因为在该示例中它们是在同一文件中定义的。通常，每个包在它自己文件内部定义，以确保词法变量为该包所私有。这样就可以实现封装。（有关详细信息，请运行“ perldoc perlmod”。） 接下来，我们要将包与类关联。就 Perl 而言，类只是一个奇特的包（相反，对象由 bless() 函数特别创建）。同样，Perl 对 OOP 规则实施得不是很严格，以便程序员不为其所约束。 new() 方法是类构造器的惯用名称（尽管按照 Perl 惯有的不严格方式，您可以使用任意名称）。当将类实例化成对象时都要调用它。 清单2. barebones 类#!/usr/bin/perl -w package Barebones; use strict; # this class takes no constructor parameters sub new my $classname = shift; # we know our class name bless , $classname; # and bless an anonymous hash 1; 可以通过将清单 2 中的代码放入任何目录内名为 Barebones.pm 的文件中，然后在该目录中运行以下命令来测试该代码（这表示：“在库路径中包括当前目录，使用 Barebones 模块，然后创建一个新的 Barebones 对象”）：perl -I. -MBarebones -e ‘my $b = Barebones->new()‘ 例如，可以在 new() 方法中放入 print 语句，以便看到 $classname 变量所拥有的内容。 如果调用 Barebones::new() 而不是 Barebones->new() ，类名将不会传递到 new() 。换句话说， new() 将不作为构造器，而只是普通的函数。 您可能要问：为什么需要传入 $classname 。为什么不直接用 bless , "Barebones"; ？因为继承的缘故，这个构造器可能被一个从 Barebones 继承、但名称却不是 Barebones 的类调用。您可能正在用错误的名称享有错误的事，而在 OOP 中，那是个坏主意。 除了new() 之外，每个类都需要成员数据和方法。定义它们就象编写几个过程一样简单。 清单3. 带有成员数据和方法的类#!/usr/bin/perl -w package Barebones; use strict; my $count = 0; # this class takes no constructor parameters sub new my $classname = shift; # we know our class name $count++; # remember how many objects bless , $classname; # and bless an anonymous hash sub count my $self = shift; # this is the object itself return $count; 1; 可以用以下命令测试该代码：perl -I. -MBarebones -e ‘my $b = Barebones->new(); Barebones->new(); print $b->count‘ 您应该得到 ‘2‘ 这个结果。构造器被调用两次，它修改词法变量（ $count），该变量被限制在 Barebones 包的作用域，而 不是每个Barebones 对象的作用域。应该将对象本身范围内的数据存储在对象本身中。在 Barebones 的示例中，被享有成对象的是匿名散列。请注意我们怎样才能在每次调用该对象的方法时访问该对象，因为对该对象的引用是传递给那些方法的第一个参数。 有几个特殊的方法，例如 DESTROY() 和AUTOLOAD()，Perl 在某些条件下会自动调用它们。 AUTOLOAD() 是用来允许动态方法名称的全捕获（catch-all）方法。 DESTROY() 是对象析构器，但是除非您确实非常非常需要，否则不应该使用它。在 Perl 中使用析构器通常表明您还在象 C/C++ 程序员那样考虑问题。 让我们看一下继承。在 Perl 中通过更改 @ISA 变量来这样做。您只需将一个类名表赋值给该变量即可。就是这样。您可以在 @ISA 中放入任何东西。您可以使您的类成为 Satan 的子类。Perl 不在乎（尽管您的牧师、部长、教长、犹太学者等可能在乎）。 清单4. 继承#!/usr/bin/perl -w package Barebones; # add these lines to your module‘s beginning, before other code or # variable declarations require Animal; # the parent class @ISA = qw(Animal); # announce we‘re a child of Animal # note that @ISA was left as a global default variable, and "use # strict" comes after its declaration. That‘s the easiest way to do it. use strict; use Carp; # make your new() method look like this: sub new my $proto = shift; my $class = ref($proto) || $proto; my $self = $class->SUPER::new(); # use the parent‘s new() method bless ($self, $class); # but bless $self (an Animal) as Barebones 1; 这些是 Perl 中 OOP 的最基本知识。Perl 语言中还有很多您应该探索的知识。人们已经撰写了很多有关这一主题的书籍。如果想阅读的话，请参考 参考资料。 回页首h2xs：您最好的新朋友您不想拥有一个可以为您编写 Perl 类、还可以编写文档（POD）框架并且通常可以通过正确地完成这些事而使您的生活轻松一些的工具吗？Perl 正好带有这种工具： h2xs。 别忘了使用几个重要标志：“ -A -n Module”。利用这些标志，h2xs 将生成一个名为“Module”、且里面全是有用文件的框架目录。这些文件是： Module.pm ，模块本身，带有已经编写好的框架文档。 Module.xs ，用于将您的模块与 C 代码链接。（有关详细信息，请运行“ perldoc perlxs”。） MANIFEST ，用于打包的文件列表。 test.pl ，框架测试脚本。 Changes ，对该模块所做更改的日志。 Makefile.PL，makefile 生成器（用“ perl Makefile.PL ”运行它。） 您无需使用所有这些文件，但是在您确实需要它们时知道它们在那里是很好的。本回答被提问者采纳

在java中，OOA是什么？OOD是什么？OOP是什么？

注：本文来源于《   在java中，OOA是什么？OOD是什么？OOP是什么？》

在java中，OOA是什么？OOD是什么？OOP是什么？

                             OOA

　　Object-Oriented Analysis：面向对象分析方法

　　是在一个系统的开发过程中进行了系统业务调查以后，按照面向对象的思想来分析问题。OOA与结构化分析有较大的区别。OOA所强调的是在系统调查资料的基础上，针对OO方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。

　　OOA（面向对象的分析）模型由5个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。在这种方法中定义了两种对象类之间的结构，一种称为分类结构，一种称为组装结构。分类结构就是所谓的一般与特殊的关系。组装结构则反映了对象之间的整体与部分的关系。

　　OOA在定义属性的同时，要识别实例连接。实例连接是一个实例与另一个实例的映射关系。

　　OOA在定义服务的同时要识别消息连接。当一个对象需要向另一对象发送消息时，它们之间就存在消息连接。

　　OOA 中的5个层次和5个活动继续贯穿在OOD（画向对象的设计）过程中。OOD模型由4个部分组成。它们分别是设计问题域部分、设计人机交互部分、设计任务管理部分和设计数据管理部分。

　　一、OOA的主要原则。

　　（1）抽象：从许多事物中舍弃个别的、非本质的特征，抽取共同的、本质性的特征，就叫作抽象。抽象是形成概念的必须手段。

　　抽象原则有两方面的意义：第一，尽管问题域中的事物是很复杂的，但是分析员并不需要了解和描述它们的一切，只需要分析研究其中与系统目标有关的事物及其本质性特征。第二，通过舍弃个体事物在细节上的差异，抽取其共同特征而得到一批事物的抽象概念。

　　抽象是面向对象方法中使用最为广泛的原则。抽象原则包括过程抽象和数据抽象两个方面。

　　过程抽象是指，任何一个完成确定功能的操作序列，其使用者都可以把它看作一个单一的实体，尽管实际上它可能是由一系列更低级的操作完成的。

　　数据抽象是根据施加于数据之上的操作来定义数据类型，并限定数据的值只能由这些操作来修改和观察。数据抽象是OOA的核心原则。它强调把数据（属性）和操作（服务）结合为一个不可分的系统单位（即对象），对象的外部只需要知道它做什么，而不必知道它如何做。

　　（2）封装就是把对象的属性和服务结合为一个不可分的系统单位，并尽可能隐蔽对象的内部细节。

　　（3）继承：特殊类的对象拥有的其一般类的全部属性与服务，称作特殊类对一般类的继承。

　　在OOA中运用继承原则，就是在每个由一般类和特殊类形成的一般—特殊结构中，把一般类的对象实例和所有特殊类的对象实例都共同具有的属性和服务，一次性地在一般类中进行显式的定义。在特殊类中不再重复地定义一般类中已定义的东西，但是在语义上，特殊类却自动地、隐含地拥有它的一般类（以及所有更上层的一般类）中定义的全部属性和服务。继承原则的好处是：使系统模型比较简练也比较清晰。

　　（4）分类：就是把具有相同属性和服务的对象划分为一类，用类作为这些对象的抽象描述。分类原则实际上是抽象原则运用于对象描述时的一种表现形式。

　　（5）聚合：又称组装，其原则是：把一个复杂的事物看成若干比较简单的事物的组装体，从而简化对复杂事物的描述。

　　（6）关联：是人类思考问题时经常运用的思想方法：通过一个事物联想到另外的事物。能使人发生联想的原因是事物之间确实存在着某些联系。

　　（7）消息通信：这一原则要求对象之间只能通过消息进行通信，而不允许在对象之外直接地存取对象内部的属性。通过消息进行通信是由于封装原则而引起的。在OOA中要求用消息连接表示出对象之间的动态联系。

　　（8）粒度控制：一般来讲，人在面对一个复杂的问题域时，不可能在同一时刻既能纵观全局，又能洞察秋毫。因此需要控制自己的视野：考虑全局时，注意其大的组成部分，暂时不详察每一部分的具体的细节；考虑某部分的细节时则暂时撇开其余的部分。这就是粒度控制原则。

　　（9）行为分析：现实世界中事物的行为是复杂的。由大量的事物所构成的问题域中各种行为往往相互依赖、相互交织。

　　二、面向对象分析产生三种分析模型

　　1、对象模型:对用例模型进行分析,把系统分解成互相协作的分析类,通过类图/对象图描述对象/对象的属性/对象间的关系,是系统的静态模型

　　2、动态模型:描述系统的动态行为,通过时序图/协作图描述对象的交互,以揭示对象间如何协作来完成每个具体的用例,单个对象的状态变化/动态行为可以通过状态图来表达

　　3、功能模型(即用例模型à作为输入)。

　　三、OOA的主要优点

　　（1）加强了对问题域和系统责任的理解；

　　（2）改进与分析有关的各类人员之间的交流；

　　（3）对需求的变化具有较强的适应性；

　　（4）支持软件复用。

　　（5）贯穿软件生命周期全过程的一致性。

　　（6）实用性；

　　（7）有利于用户参与。

    四、OOA方法的基本步骤

　　在用OOA具体地分析一个事物时，大致上遵循如下五个基本步骤：

　　第一步，确定对象和类。这里所说的对象是对数据及其处理方式的抽象，它反映了系统保存和处理现实世界中某些事物的信息的能力。类是多个对象的共同属性和方法集合的描述，它包括如何在一个类中建立一个新对象的描述。

　　第二步，确定结构（structure）。结构是指问题域的复杂性和连接关系。类成员结构反映了泛化-特化关系，整体-部分结构反映整体和局部之间的关系。

　　第三步，确定主题（subject）。主题是指事物的总体概貌和总体分析模型。

　　第四步，确定属性（attribute）。属性就是数据元素，可用来描述对象或分类结构的实例，可在图中给出，并在对象的存储中指定。

　　第五步，确定方法（method）。方法是在收到消息后必须进行的一些处理方法：方法要在图中定义，并在对象的存储中指定。对于每个对象和结构来说，那些用来增加、修改、删除和选择一个方法本身都是隐含的（虽然它们是要在对象的存储中定义的，但并不在图上给出），而有些则是显示的。

 

 

 

                                                           OOD

　　面向对象设计（Object-Oriented Design，OOD）方法是OO方法中一个中间过渡环节。其主要作用是对OOA分析的结果作进一步的规范化整理，以便能够被OOP直接接受。

　　面向对象设计（OOD）是一种软件设计方法，是一种工程化规范。这是毫无疑问的。按照Bjarne Stroustrup的说法，面向对象的编程范式（paradigm）是[Stroustrup, 97]：

　　l 决定你要的类；

　　l 给每个类提供完整的一组操作；

　　l 明确地使用继承来表现共同点。

　　由这个定义，我们可以看出：OOD就是“根据需求决定所需的类、类的操作以及类之间关联的过程”。

　　OOD的目标是管理程序内部各部分的相互依赖。为了达到这个目标，OOD要求将程序分成块，每个块的规模应该小到可以管理的程度，然后分别将各个块隐藏在接口（interface）的后面，让它们只通过接口相互交流。比如说，如果用OOD的方法来设计一个服务器-客户端（client-server）应用，那么服务器和客户端之间不应该有直接的依赖，而是应该让服务器的接口和客户端的接口相互依赖。

　　这种依赖关系的转换使得系统的各部分具有了可复用性。还是拿上面那个例子来说，客户端就不必依赖于特定的服务器，所以就可以复用到其他的环境下。如果要复用某一个程序块，只要实现必须的接口就行了。

　　OOD是一种解决软件问题的设计范式（paradigm），一种抽象的范式。使用OOD这种设计范式，我们可以用对象（object）来表现问题领域（problem domain）的实体，每个对象都有相应的状态和行为。我们刚才说到：OOD是一种抽象的范式。抽象可以分成很多层次，从非常概括的到非常特殊的都有，而对象可能处于任何一个抽象层次上。另外，彼此不同但又互有关联的对象可以共同构成抽象：只要这些对象之间有相似性，就可以把它们当成同一类的对象来处理。

　　一、OOD背景知识

　　计算机硬件技术却在飞速发展。从几十年前神秘的庞然大物，到现在随身携带的移动芯片；从每秒数千次运算到每秒上百亿次运算。当软件开发者们还在寻找能让软件开发生产力提高一个数量级的“银弹”[Brooks, 95]时，硬件开发的生产力早已提升了百倍千倍。

　　硬件工程师们能够如此高效，是因为他们都很懒惰。他们永远恪守“不要去重新发明轮子”的古训。Grady Booch把这些黑箱称为类属（class category），现在我们则通常把它们称为“组件（component）”。

　　类属是由被称为类（class）的实体组成的，类与类之间通过关联（relationship）结合在一起。一个类可以把大量的细节隐藏起来，只露出一个简单的接口，这正好符合人们喜欢抽象的心理。所以，这是一个非常伟大的概念，因为它给我们提供了封装和复用的基础，让我们可以从问题的角度来看问题，而不是从机器的角度来看问题。

　　软件的复用最初是从函数库和类库开始的，这两种复用形式实际上都是白箱复用。到90年代，开始有人开发并出售真正的黑箱软件模块：框架（framework）和控件（control）。框架和控件往往还受平台和语言的限制，现在软件技术的新潮流是用SOAP作为传输介质的Web Service，它可以使软件模块脱离平台和语言的束缚，实现更高程度的复用。但是想一想，其实Web Service也是面向对象，只不过是把类与类之间的关联用XML来描述而已[Li, 02]。

　　在过去的十多年里，面向对象技术对软件行业起到了极大的推动作用。在可以预测的将来，它仍将是软件设计的主要技术——至少我看不到有什么技术可以取代它的。

　　二、OOD到底从哪儿来？

　　有很多人都认为：OOD是对结构化设计（Structured Design，SD）的扩展，其实这是不对的。OOD的软件设计观念和SD完全不同。SD注重的是数据结构和处理数据结构的过程。而在OOD中，过程和数据结构都被对象隐藏起来，两者几乎是互不相关的。不过，追根溯源，OOD和SD有着非常深的渊源。

　　1967年前后，OOD和SD 的概念几乎同时诞生，它们分别以不同的方式来表现数据结构和算法。当时，围绕着这两个概念，很多科学家写了大量的论文。其中，由Dijkstra和 Hoare两人所写的一些论文讲到了“恰当的程序控制结构”这个话题，声称goto语句是有害的，应该用顺序、循环、分支这三种控制结构来构成整个程序流程。这些概念发展构成了结构化程序设计方法；而由Ole-Johan Dahl所写的另一些论文则主要讨论编程语言中的单位划分，其中的一种程序单位就是类，它已经拥有了面向对象程序设计的主要特征。

　　这两种概念立刻就分道扬镳了。在结构化这边的历史大家都很熟悉：NATO会议采纳了Dijkstra的思想，整个软件产业都同意goto语句的确是有害的，结构化方法、瀑布模型从70年代开始大行其道。同时，无数的科学家和软件工程师也帮助结构化方法不断发展完善，其中有很多今天足以使我们振聋发聩的名字，例如Constantine、Yourdon、DeMarco和Dijkstra。有很长一段时间，整个世界都相信：结构化方法就是拯救软件工业的 “银弹”。当然，时间最后证明了一切。

　　而此时，面向对象则在研究和教育领域缓慢发展。结构化程序设计几乎可以应用于任何编程语言之上，而面向对象程序设计则需要语言的支持[1]，这也妨碍了面向对象技术的发展。实际上，在60年代后期，支持面向对象特性的语言只有Simula-67这一种。到70年代，施乐帕洛阿尔托研究中心（PARC）的 Alan Key等人又发明了另一种基于面向对象方法的语言，那就是大名鼎鼎的Smalltalk。但是，直到80年代中期，Smalltalk和另外几种面向对象语言仍然只停留在实验室里。

　　到90年代，OOD突然就风靡了整个软件行业，这绝对是软件开发史上的一次革命。不过，登高才能望远，新事物总是站在旧事物的基础之上的。70年代和80年代的设计方法揭示出许多有价值的概念，谁都不能也不敢忽视它们，OOD也一样。

　　三、OOD和传统方法有什么区别？

　　还记得结构化设计方法吗？程序被划分成许多个模块，这些模块被组织成一个树型结构。这棵树的根就是主模块，叶子就是工具模块和最低级的功能模块。同时，这棵树也表示调用结构：每个模块都调用自己的直接下级模块，并被自己的直接上级模块调用。

　　那么，哪个模块负责收集应用程序最重要的那些策略？当然是最顶端的那些。在底下的那些模块只管实现最小的细节，最顶端的模块关心规模最大的问题。所以，在这个体系结构中越靠上，概念的抽象层次就越高，也越接近问题领域；体系结构中位置越低，概念就越接近细节，与问题领域的关系就越少，而与解决方案领域的关系就越多。

　　但是，由于上方的模块需要调用下方的模块，所以这些上方的模块就依赖于下方的细节。换句话说，与问题领域相关的抽象要依赖于与问题领域无关的细节！这也就是说，当实现细节发生变化时，抽象也会受到影响。而且，如果我们想复用某一个抽象的话，就必须把它依赖的细节都一起拖过去。

　　而在OOD中，我们希望倒转这种依赖关系：我们创建的抽象不依赖于任何细节，而细节则高度依赖于上面的抽象。这种依赖关系的倒转正是OOD和传统技术之间根本的差异，也正是OOD思想的精华所在。

　　四、OOD步骤

　　细化重组类

　　细化和实现类间关系,明确其可见性

　　增加属性,指定属性的类型与可见性

　　分配职责,定义执行每个职责的方法

　　对消息驱动的系统,明确消息传递方式

　　利用设计模式进行局部设计

　　画出详细的类图与时序图

　　五、OOD设计过程中要展开的主要几项工作

　　（一）对象定义规格的求精过程

　　对于OOA所抽象出来的对象-＆-类以及汇集的分析文档，OOD需要有一个根据设计要求整理和求精的过程，使之更能符合OOP的需要。这个整理和求精过程主要有两个方面：一是要根据面向对象的概念

　　模型整理分析所确定的对象结构、属性、方法等内容，改正错误的内容，删去不必要和重复的内容等。二是进行分类整理，以便于下一步数据库设计和程序处理模块设计的需要。整理的方法主要是进行归

　　类，对类一＆一对象、属性、方法和结构、主题进行归类。

　　（二）数据模型和数据库设计

　　数据模型的设计需要确定类-＆-对象属性的内容、消息连接的方式、系统访问、数据模型的方法等。最后每个对象实例的数据都必须落实到面向对象的库结构模型中。

　　（三）优化

　　OOD的优化设计过程是从另一个角度对分析结果和处理业务过程的整理归纳，优化包括对象和结构的优化、抽象、集成。

　　对象和结构的模块化表示OOD提供了一种范式，这种范式支持对类和结构的模块化。这种模块符合一般模块化所要求的所有特点，如信息隐蔽性好，内部聚合度强和模块之间耦合度弱等。

　　集成化使得单个构件有机地结合在一起，相互支持。

　　六、OO方法的特点和面临的问题

　　OO方法以对象为基础，利用特定的软件工具直接完成从对象客体的描述到软件结构之间的转换。这是OO方法最主要的特点和成就。OO方法的应用解决了传统结构化开发方法中客观世界描述工具与软

　　件结构的不一致性问题，缩短了开发周期，解决了从分析和设计到软件模块结构之间多次转换映射的繁杂过程，是一种很有发展前途的系统开发方法。

　　但是同原型方法一样,OO方法需要一定的软件基础支持才可以应用，另外在大型的MIS开发中如果不经自顶向下的整体划分，而是一开始就自底向上的采用OO 方法开发系统，同样也会造成系统结构不合理、各部分关系失调等问题。所以OO方法和结构化方法目前仍是两种在系统开发领域相互依存的、不可替代的方法。

　　七、OOD能给我带来什么？

　　问这个问题的人，脑子里通常是在想“OOD能解决所有的设计问题吗？”没有银弹。OOD也不是解决一切设计问题、避免软件危机、捍卫世界和平……的银弹。OOD只是一种技术。但是，它是一种优秀的技术，它可以很好地解决目前的大多数软件设计问题——当然，这要求设计者有足够的能力。

　　OOD可能会让你头疼，因为要学会它、掌握它是很困难的；OOD甚至会让你失望，因为它也并不成熟、并不完美。OOD也会给你带来欣喜，它让你可以专注于设计，而不必操心那些细枝末节；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)，如果能够满足一个应用程序或者一个产业领域对所提出的大部分要求的话，对于其制造者来说就是划算的产品，而且技术上也不是很困难。可是该产业内的几个竞争者很快就会发现，如果所有人都采用这些组件，那么彼此之间的产品就会变得天下大同，没什么区别，他们将沦为简单的办事员，主要利润都将钻进那些组件/框架供应商的腰包里！

　　小“组件”很有用，不过产生不了预期的杠杆效应。中型的、更通用的组件非常有用，但是构造时需要非同寻常的弹性。