面向对象的三个基本特征
原文URL:http://blog.163.com/gogles @ yeah/blog/static/1616881772010311640263 /
1 .抽象和打包：
抽象是指将系统需要处理的数据与这些数据上的操作结合起来，根据功能、性质、用途等因素抽象为不同的抽象数据类型。 每个抽象数据类型都包含数据和对该数据的批准操作。 在面向对象的编程中，抽象数据类型以“类”结构实现，每个类都封装有相关的数据和操作。 封装是指将抽象数据类型与基于数据的操作相结合，以确保数据在抽象数据类型内部受到保护，并且仅通过将系统的其他部分包装在数据之外并允许进行的操作才能与该抽象数据类型进行交互。 2 .继承：是与传统方法不同的最具特色的方法。 这是面向对象程序中两个类之间的关系。 这意味着一个类可以从另一个类(即其父类)继承状态和行为。 继承父类的类称为子类。 继承优势：使用继承，程序员可以在不同的子类中多次重用父类中的代码，从而使程序结构清晰，便于维护和修改。 另一方面，子类可以提供父类中没有的特殊行为。 3 .多态性是指一个程序中共存同名的方法，调用方只需使用相同的方法名，系统根据情况调用相应的不同方法，实现不同的功能。 多态性也被称为“一个名字，多个方法”。 面向对象的三个基本特征和五个设计原则原文网站： http://blog.csdn.net/cancan 8538/article/details/8057095一，三个基本特征
面向对象的三个基本特征是封装、继承和多态性。
你最好理解包。 封装是面向对象的特征之一是对象和类概念的主要特性
封装就是把客观的东西封装成抽象的类。 然后，类可以只让受信任的类或对象操作自己的数据和方法，而不信任的可以隐藏信息。
继承面向对象编程(OOP )语言的主要功能之一是“继承”。 继承是指使用现有类的所有功能并在不重写原始类的情况下进行扩展的能力。
通过继承创建的新类称为“子类”或“派生类”。
继承的类称为“基类”、“父类”或“超类”。
继承的过程是从一般到特殊的过程。
要实现继承，可以在“继承”(Inheritance )和“组合”(Composition )下实现。
在某些OOP语言中，一个子类可以继承多个基类。 但是，一般来说，子类只有一个基类。 要实现多重继承，可以通过多级继承来实现。
继承概念的实现方式有继承实现、接口继承、可见继承三种。
继承是指使用基类属性和方法而无需额外编码的能力。
接口继承是指仅使用属性和方法的名称，但子类必须提供实现能力。
视觉继承是子窗体(类)使用基窗体(类)实现外观和代码的能力。
在考虑使用继承时，有一点需要注意。 那就是，两个班之间的关系应该是“属于”的关系。 例如，Employee是一个人，而Manager也是一个人，所以这两个类都可以继承Person类。 但是，Leg类不能继承Person类。 因为腿不是一个人。
抽象类只定义子类创建的常规属性和方法。 创建抽象类时，请使用关键字接口而不是Class。
o开发范式大致可分为以下几个阶段：划分对象抽象类将类组织起来形成分层结构(继承和合成)在类和实例中设计和实现。
“多态性”(polymorphisn )是一种允许父对象等效于一个或多个子对象的技术，指定值后，父对象将以不同的方式工作，具体取决于当前指定的子对象的特性。 简而言之，允许将子类类型的指针赋值给父类类型的指针
实现多态性，有两种方式，覆盖、重载。
覆盖是子类重新定义父类虚函数的一种做法。
重载意味着允许存在多个同名的函数，这些函数的参数表不同(参数数量可能不同，参数类型可能不同，两者可能不同)。
其实，重载的概念不是“面向对象编程”。 重载的实现是编译器根据函数的不同参数表限定同名函数的名称，这些同名函数成为不同的函数(至少对编译器来说是如此)。 例如，功能函数(:integer ) :integer； 和函数函数(p :字符串) :integer； 编译器限定的函数名称可能是int_func、str_func。 与此相对
两个函数的调用，在编译器间就已经确定了，是静态的（记住：是静态）。也就是说，它们的地址在编译期就绑定了（早绑定），因此，重载和多态无关！真正和多态相关的是“覆盖”。当子类重新定义了父类的虚函数后，父类指针根据赋给它的不同的子类指针，动态（记住：是动态！）的调用属于子类的该函数，这样的函数调用在编译期间是无法确定的（调用的子类的虚函数的地址无法给出）。因此，这样的函数地址是在运行期绑定的（晚邦定）。结论就是：重载只是一种语言特性，与多态无关，与面向对象也无关！引用一句Bruce Eckel的话：“不要犯傻，如果它不是晚邦定，它就不是多态。”那么，多态的作用是什么呢？
我们知道，封装可以隐藏实现细节，使得代码模块化；继承可以扩展已存在的代码模块（类）；它们的目的都是为了——代码重用。而多态则是为了实现另一个目的——接口重用！多态的作用，就是为了类在继承和派生的时候，保证使用“家谱”中任一类的实例的某一属性时的正确调用。
概念讲解
泛化（Generalization）
图表 1 泛化
在上图中，空心的三角表示继承关系（类继承），在UML的术语中，这种关系被称为泛化（Generalization）。Person(人)是基类，Teacher(教师)、Student(学生)、Guest(来宾)是子类。
若在逻辑上B是A的“一种”，并且A的所有功能和属性对B而言都有意义，则允许B继承A的功能和属性。
例如，教师是人，Teacher 是Person的“一种”（a kind of ）。那么类Teacher可以从类Person派生（继承）。
如果A是基类，B是A的派生类，那么B将继承A的数据和函数。
如果类A和类B毫不相关，不可以为了使B的功能更多些而让B继承A的功能和属性。
若在逻辑上B是A的“一种”（a kind of ），则允许B继承A的功能和属性。
聚合（组合）
图表 2 组合
若在逻辑上A是B的“一部分”（a part of），则不允许B从A派生，而是要用A和其它东西组合出B。
例如，眼（Eye）、鼻（Nose）、口（Mouth）、耳（Ear）是头（Head）的一部分，所以类Head应该由类Eye、Nose、Mouth、Ear组合而成，不是派生（继承）而成。
聚合的类型分为无、共享(聚合)、复合(组合)三类。
聚合（aggregation）
图表 3 共享
上面图中，有一个菱形（空心）表示聚合（aggregation）（聚合类型为共享），聚合的意义表示has-a关系。聚合是一种相对松散的关系，聚合类B不需要对被聚合的类A负责。
组合（composition）
图表 4 复合
这幅图与上面的唯一区别是菱形为实心的，它代表了一种更为坚固的关系——组合（composition）（聚合类型为复合）。组合表示的关系也是has-a，不过在这里，A的生命期受B控制。即A会随着B的创建而创建，随B的消亡而消亡。
依赖(Dependency)
图表 5 依赖
这里B与A的关系只是一种依赖(Dependency)关系，这种关系表明，如果类A被修改，那么类B会受到影响。
二、五种设计原则
"面向对象设计五大原则"和良性依赖原则在应付变化方面的作用。
单一职责原则(Single-Resposibility Principle)。"对一个类而言，应该仅有一个引起它变化的原因。"本原则是我们非常熟悉地"高内聚性原则"的引申，但是通过将"职责"极具创意地定义为"变化的原因"，使得本原则极具操作性，尽显大师风范。同时，本原则还揭示了内聚性和耦合生，基本途径就是提高内聚性；如果一个类承担的职责过多，那么这些职责就会相互依赖，一个职责的变化可能会影响另一个职责的履行。其实OOD的实质，就是合理地进行类的职责分配。
开放封闭原则(Open-Closed principle)。"软件实体应该是可以扩展的，但是不可修改。"本原则紧紧围绕变化展开，变化来临时，如果不必改动软件实体裁的源代码，就能扩充它的行为，那么这个软件实体设计就是满足开放封闭原则的。如果说我们预测到某种变化，或者某种变化发生了，我们应当创建抽象类来隔离以后发生的同类变化。在Java中，这种抽象是指抽象基类或接口；在C++中，这各抽象是指抽象基类或纯抽象基类。当然，没有对所有情况都贴切的模型，我们必须对软件实体应该面对的变化做出选择。
Liskov替换原则(Liskov-Substituion Principle)。"子类型必须能够替换掉它们的基类型。"本原则和开放封闭原则关系密切，正是子类型的可替换性，才使得使用基类型模块无需修改就可扩充。Liskov替换原则从基于契约的设计演化而来，契约通过为每个方法声明"先验条件"和"后验条件"；定义子类时，必须遵守这些"先验条件"和"后验条件"。当前基于契的设计发展势头正劲，对实现"软件工厂"的"组装生产"梦想是一个有力的支持。
依赖倒置原则(Dependecy-Inversion Principle)。"抽象不应依赖于细节，细节应该依赖于抽象。"本原则几乎就是软件设计的正本清源之道。因为人解决问题的思考过程是先抽象后具体，从笼统到细节，所以我们先生产出的势必是抽象程度比较高的实体，而后才是更加细节化的实体。于是，"细节依赖于抽象"就意味着后来的依赖于先前的，这是自然而然的重用之道。而且，抽象的实体代表着笼而统之的认识，人们总是比较容易正确认识它们，而且本身也是不易变的，依赖于它们是安全的。依赖倒置原则适应了人类认识过程的规律，是面向对象设计的标志所在。
接口隔离原则(Interface-Segregation Principle)。"多个专用接口优于一个单一的通用接口。"本原则是单一职责原则用于接口设计的自然结果。一个接口应该保证，实现该接口的实例对象可以只呈现为单一的角色；这样，当某个客户程序的要求发生变化，而迫使接口发生改变时，影响到其他客户程序的可能生性小。
良性依赖原则。"不会在实际中造成危害的依赖关系，都是良性依赖。"通过分析不难发现，本原则的核心思想是"务实"，很好地揭示了极限编程(Extreme Programming)中"简单设计"各"重构"的理论基础。本原则可以帮助我们抵御"面向对象设计五大原则"以及设计模式的诱惑，以免陷入过度设计(Over-engineering)的尴尬境地，带来不必要的复杂性。