本章内容：

• 什么是面向对象的程序设计
• 如何定义不同对象之间的关系
• 抽象的重要性以及如何在设计中使用抽象

（面向对象的程序设计不同于面向过程，本章将讨论对象之间的不同关系，包括创建面向对象程序时会遇到的问题，抽象原则如何与对象联系起来）

3.1 过程化的思考方式

•  过程化语言（如C）将代码分割为小块，每小块完成单一的任务
• 所有代码都会集中在main()中，难以阅读；且大型应用程序中 ，很少有线性事件序列

3.2 面向对象思想

•  相较于面向过程将程序分割为若干任务；面向对象OOP的基本观念是将其分割为自然对象的模型

3.2.1 类

• 类只是简单的封装了用来定义对象分类的信息
• 对象是类的一个实例

3.2.2 组件

• 如遇复杂对象时，面向对象思想是将其分解为更小的组件（每个组件还有更更小的组件）
• 组件与类的本质上类似，但组件更小、更具体、更灵活

3.2.3 属性

• 类属性被所有的类成员共享，而类的所有对象体现不同属性值的对象属性
• 属性用来描述对象的特征，将一个对象与其他对象区分开

3.2.4 行为

• 不同于属性回答 “为什么这个对象与众不同”，行为回答 “对象做什么”

3.2.5 综上

• 通过上面这些概念，OOP是一种更灵活的软件思考方法

 3.3 两个误区

 3.3.1 过度使用对象

•  有时候，变量就只是变量
• 对象是用来帮助程序员管理代码的，如果只是为了使代码 “更像面向对象” 而将不应该是对象事物当作对象，过度的使用对象，那么就本末倒置了

 3.3.2 过于通用的对象

•  过于通用的万金油对象，根本无法代表具体事物

 3.4 对象之间的关系

 3.4.1 “有一个” 关系

• “有一个” 关系 / 聚合关系的模式是：A有一个B，或A包含B
• 在这种类型关系中，可以认为某个对象是另一个对象的一部分（如A对象有一个B组件）

 3.4.2 “是一个” 关系（继承）

• “是一个” 关系 / 聚合关系的模式是：A是一个B，或A实际上与B非常相似
• “是一个” 关系是面向对象编程最基本的概念，又称：子类subclass、扩展extending、继承inheriting
• 当类之间具有 “是一个”关系时，可将常用功能放进超类（superclass，一个可以被其他类拓展的类），以便所需的改动可以在一个地方完成，将来的子类可以自由的获取这些共享功能

•  继承技术
  • 子类可以在超类的基础上添加功能 / 属性
  • 子类可以完全替换或重写超类的行为 / 属性
  • （但注意：不要把替换属性的概念 和 子类具有不同属性值的概念 混淆）
• 多态性与代码重用
  • 多态性指具有标准属性和行为的对象可以互换使用
  • 代码重用，将已有类拓展，并添加新功能

 3.4.3 Not-a 关系

• 考虑类之间的关系时，应考虑类之间是否真的存在关系
• 如下的关系虽然作为概念集或层次结构是有意义的，但在代码中并不能代表有意义的关系

•  避免不必要子类的最好办法就是，先给出一个大概设计，为每个类和子类写出计划设置的属性和行为

 3.4.4 层次结构

•  面向对象层次结构可以模拟多层关系
• 在代码中，需要平衡现实关系及共享功能关系（现实中紧密关联的两件事物，可能没有共享功能，因而在代码中没有任何关系）
• 优秀的面向对象层次结构（由需求决定设计）：
  • 类之间存在有意义的功能关系
  • 将共同功能放到超类，从而支持代码重用
  • 避免子类过多重写超类的功能，除非超类是一个抽象类

 3.4.5 多重继承

•  在多重继承中，一个类可以有多个超类
• 多重继承的缺点：
  • 用图形表示多重继承十分复杂，多层继承会破坏清晰的层次结构（类层次结构的目的是使代码关系更清晰，而在多重继承中，类可以有多个彼此没有关系的超类，这使得即便是简单的类层次也会变得复杂）
  • 多重继承的实现很复杂，因此应避免引入多重继承 

 3.4.6 混入类

• C++中，混入类（mix-in）的语法类似与多重继承，但语义完全不同，也更好理解
• 混入类代表另一种类之间的关系，可以理解为一种分享关系
• 混入类回答 “这个类还可以做什么” 问题
• 混入类常用于用户界面，混入类没有庞大的层次结构，因此不会出现功能的交叉混乱

 3.5 抽象

•  抽象是将实现与访问方式分离的概念，也是面向对象设计的基础

 3.5.1 接口与实现

• 抽象的关键是：有效分离接口与实现。接口是其他用户使用代码的方式；实现是用来完成任务的代码
• 在C中，描述库函数的头文件是接口；在面向对象编程中，类的接口是公有属性及行为的集合
• 优秀的接口应只包含公有行为，类的属性和变量绝不应该是公有的，但可以通过共有行为公开（Get / Set）

 3.5.2 决定公开的接口

• 公有 public
  • 其他代码可以访问
• 保护 protected
  • 其他代码不可以访问，但子类可以访问
• 私有 private
  • 均不可以访问

•  设计接口：
  • 考虑用户
    • 如果接口仅仅只是自己用，可以灵活设计（但难保某一天别人也会用）
    • 设计给其他程序员使用的接口，需要将接口看成是几乎不可改变的
    • 如果用户是外部客户，则接口中使用的术语必须是客户能接受的
  • 考虑目的
    • 应用程序编程接口API：更接近于刻在石头上的法律，设计API时主要考虑使用的难度和灵活性
    • 工具类或库：重点考虑通用性
    • 子系统接口：首要考虑子系统的主要目的是什么，再考虑具体用法，将接口与实现分离
    • 组件接口：（同子系统接口）考虑每个类的主要目的，不公开对目的没有贡献的功能
  • 考虑未来
    • 设计接口时还需要考虑将来的需求，可能需要使用插件架构，从而留出拓展空间，如果将来的用途不明，不要设计包含一切的日志类（这样会使设计、实现、公有接口复杂化）
  •  好的抽象意味着接口只有公有行为，类定义的接口文件是稳定的，不会改变
  • 考虑用其他类配合主接口，不建议单一类的抽象
  • 将属性转化为行为，不要让外部代码直接操作类的数据