OOP技术简介

   OOP( Object Oriented Programming)是一种通过使用对象来解决问题的编程技术，例如c++，java等等。在编程术语中，对象是这样一些实体：它们的特性和行为是解决手头问题所必需的。这个定义本应该更详细些，但是做不到，因为当今计算机行业中 OOP 方法的种类之多简直难以想象。

1,OOP的特性：
   
   OOP 是一种用于解决问题的编程方法或通用方法。与之相反，算法是用于解决特定问题的特定方法。OOP 天生是一种强有力的方法；它往往使过程型和函数型编程方法与该问题较少相关，并且除非它与过程型和函数型编程方法的混合对其极其有益，否则它们之间不会很好地结合在一起。
   
    通常，有三个语言特性是 OOP 编程语言所必需的。它们是继承、多态性和封装。

   有两种继承：单一继承和多重继承。 单一继承要求子对象只有一个父对象，而 多重继承更自由（与实际生活一样，在编程过程中具有两个以上的父对象会导致混乱并使子对象难以工作，因此，不要过多使用多重继承）。尽管两个或两个以上的父对象实际上很少见，但 Perl 支持多重继承。

   多态性（来自希腊语，表示“很多形态”）是使一个对象被看成另一个对象的技术。这有点复杂，那么我举个例子。比方说，您有一个绵羊牧场，里面有四只绵羊（绵羊属），但是您刚刚买了两只山羊（山羊属）和一只德国牧羊犬（犬科犬属）。您一共有多少动物？您得把所有的绵羊、山羊和狗加起来，结果是 7 只。其实您刚刚应用了多态性，即为了计算，把三种不同种类的动物当成一种通用类型（“动物”）对待。如果您把绵羊、山羊和狗当成哺乳动物看待，这就是一个简单的信心飞跃。生物学家每天都以这种方式使用多态性，而程序员则以从其它科学领域“窃用”（我是指“重用”）好主意闻名。

   封装指的是以这样一种方式包含对象行为和特性：除非对象作者允许，否则用户无法访问该对象的行为和特性。在这种方式下，对象用户无法做不准他们做的事，无法访问不准他们访问的数据，并且通常是有害数据。

2,OOP与FP(函数型编程),PP(过程型编程)的区别：
  
    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 过程得到处使用。

3,OOP编程技术的好处：
   
   OOP 的好处太多，本文难以列举。正如我在前面提到的那样，有很多关于该主题的书籍。这些好处中的一小部分是：易于代码重用、代码质量的改进、一致的接口和可适应性。

   因为 OOP 建立在类和对象的基础之上，所以重用 OO 代码意味着在需要时只需简单地导入类。至今为止，代码重用是使用 OOP 的唯一最主要原因，也是 OOP 在当今业界中的重要性和流行性日益增加的原因所在。

   这里有一些陷阱。例如，在当前的情况下，以前问题的解决方案可能不理想，并且文档库编制得很差，以至于理解和使用文档编制很差的库所花的时间可能与重新编写库的时间一样长。系统架构设计师的工作是看到和避免这些陷阱。

   使用 OOP 可以提高代码质量，因为封装减少了数据毁坏（“友好之火”），而继承和多态性则减少了必须编写的新代码数量和复杂性。在代码质量和编程创新之间有一个微妙的平衡，这最好留给团队去发现，因为它完全取决于团队的构成和目的。

   OOP 继承和重用使得在代码中实现一致的接口变得简单，但是并不能说所有的 OO 代码都有一致的接口。程序员仍然必须遵循通用的体系结构。例如，团队应该在错误日志记录的格式和接口方面达成一致，最好通过一个允许日后扩展并且极其易用的示范模块接口来这样做。只有在那时，每名程序员才能承诺使用该接口，而不是无规则的 print 语句，因为他们会认识到在出现下一个错误日志记录函数时，学习该接口的努力不会白费。

   可适应性在编程中是一个有些含糊的概念。我愿意把它定义成对环境和用法更改的接受性和预见性。对于编写良好的软件来说，可适应性很重要，因为所有的软件必须随着外部世界而进化。编写良好的软件应该很容易进化。OOP 通过模块设计、改进的代码质量和一致的接口确保新操作系统或者新报告格式不要求对体系结构的核心作出根本更改，从而有助于软件的进化。