说来惭愧，我虽然计算机科学专业科班出生，但是对面向对象编程的理解并不透彻。但在看到“如何写一手漂亮的模型：面向对象编程的设计原则综述”后，感觉收获不少，欣喜之余赶紧摘抄记录一下。

面向对象编程的设计原则

为了写出清晰的、高质量的、可维护并且可扩展的代码，面向对象编程（OOP）将是我们最佳的选择。

对象类型

因为我们要围绕对象来建立代码，所以区分它们的不同责任和变化是有用的。一般来说，面向对象的编程有三种类型的对象。

实体对象

这类对象通常对应着问题空间中的一些现实实体。比如我们要建立一个角色扮演游戏（RPG），那么简单的 Hero 类就是一个实体对象。

这类对象通常包含关于它们自身的属性（例如 health 或 mana），这些属性根据具体的规则都是可修改的。

控制对象（Control Object）

控制对象（有时候也称作管理对象）主要负责与其它对象的协调，这是一些管理并调用其它对象的对象。我们上面的 RPG 案例中有一个很棒的例子，Fight 类控制两个英雄，并让它们对战。

在这种类中，为对战封装编程逻辑可以给我们提供多个好处：其中之一就是动作的可扩展性。我们可以很容易地将参与战斗的英雄传递给非玩家角色（NPC），这样它们就能利用相同的 API。我们还可以很容易地继承这个类，并复写一些功能来满足新的需要。

边界对象（Boundary Object）

这些是处在系统边缘的对象。任何一个从其它系统获取输入或者给其它系统产生输出的对象都可以被归类为边界对象，无论那个系统是用户，互联网或者是数据库。

这些边界对象负责向系统内部或者外部传递信息。例如对要接收的用户指令，我们需要一个边界对象来将键盘输入（比如一个空格键）转换为一个可识别的域事件（例如角色的跳跃）。

Bonus：值对象（Value Object）

价值对象代表的是域（domain）中的一个简单值。它们无法改变，不恒一。

如果将它们结合在我们的游戏中，Money 类或者 Damage 类就表示这种对象。上述的对象让我们容易地区分、寻找和调试相关功能，然而仅使用基础的整形数组或者整数却无法实现这些功能。

它们可以归类为实体对象的子类别。

关键设计原则

设计原则是软件设计中的规则，过去这些年里已经证明它们是有价值的。严格地遵循这些原则有助于软件达到一流的质量。

抽象（Abstraction）

抽象就是将一个概念在一定的语境中简化为原始本质的一种思想。它允许我们拆解一个概念来更好的理解它。

上面的游戏案例阐述了抽象，让我们来看一下 Fight 类是如何构建的。我们以尽可能简单的方式使用它，即在实例化的过程中给它两个英雄作为参数，然后调用 fight() 方法。不多也不少，就这些。

封装

封装可以被认为是将某些东西放在一个类以内，并限制了它向外部展现的信息。在软件中，限制对内部对象和属性的访问有助于保证数据的完整性。

将内部编程逻辑封装成黑盒子，我们的类将更容易管理，因为我们知道哪部分可以被其它系统使用，哪些不行。这意味着我们在保留公共部分并且保证不破坏任何东西的同时能够重用内部逻辑。此外，我们从外部使用封装功能变得更加简单，因为需要考虑的事情也更少。

分解

分解就是把一个对象分割为多个更小的独立部分，这些独立的部分更易于理解、维护和编程。

试想我们现在希望 Hero 类能结合更多的 RPG 特征，例如 buffs，资产，装备，角色属性。

解决方案就是将 Hero 对象分解为多个更小的对象，每个小对象可承担一些功能。

下面是三种分解关系：

关联：在两个组成部分之间定义一个松弛的关系。两个组成部分不互相依赖，但是可以一起工作。例如 Hero 对象和 Zone 对象。
聚合：在整体和部分之间定义一个弱「包含」关系。这种关系比较弱，因为部分可以在没有整体的时候存在。例如 HeroInventory（英雄财产）和 Item（条目）。HeroInventory 可以有很多 Items，而且一个 Items 也可以属于任何 HeroInventory（例如交易条目）。
组成：一个强「包含」关系，其中整体和部分不能彼此分离。部分不能被共享，因为整体要依赖于这些特定的部分。例如 Hero（英雄）和 HeroAttributes（英雄属性）。

泛化

泛化可能是最重要的设计原则，即我们提取共享特征，并将它们结合到一起的过程。我们都知道函数和类的继承，这就是一种泛化。

做一个比较可能会将这个解释得更加清楚：尽管抽象通过隐藏非必需的细节减少了复杂性，但是泛化通过用一个单独构造体来替代多个执行类似功能的实体。

在给出的例子中，我们将常用的 Hero 类和 NPC 类泛化为一个共同的父类 Entity，并通过继承简化子类的构建。

这里，我们通过将它们的共同功能移动到基本类中来减少复杂性，而不是让 NPC 类和 Hero 类将所有的功能都实现两次。

组合

组合就是把多个对象结合为一个更复杂对象的过程。这种方法会创建对象的示例，并且使用它们的功能，而不是直接继承它。

使用组合原则的对象就被称作组合对象（composite object）。这种组合对象在要比所有组成部分都简单，这是非常重要的一点。当把多个类结合成一个类的时候，我们希望把抽象的层次提高一些，让对象更加简单。

组合对象的 API 必须隐藏它的内部模块，以及内部模块之间的交互。就像一个机械时钟，它有三个展示时间的指针，以及一个设置时间的旋钮，但是它内部包含很多运动的独立部件。

正如我所说的，组合要优于继承，这意味着我们应该努力将共用功能移动到一个独立的对象中，然后其它类就使用这个对象的功能，而不是将它隐藏在所继承的基本类中。

批判性思考

尽管这些设计原则是在数十年经验中形成的，但盲目地将这些原则应用到代码之前进行批判性思考是很重要的。

任何事情都是过犹不及！有时候这些原则可以走得很远，但是实际上有时会变成一些很难使用的东西。

作为一个工程师，我们需要根据独特的情境去批判地评价最好的方法，而不是盲目地遵从并应用任意的原则。

关注点的内聚、耦合和分离

内聚（Cohesion）

内聚代表的是模块内部责任的分明，或者是模块的复杂度。

如果我们的类只执行一个任务，而没有其它明确的目标，那么这个类就有着高度内聚性。另一方面，如果从某种程度而言它在做的事情并不清楚，或者具有多于一个的目标，那么它的内聚性就非常低。

我们希望代码具有较高的内聚性，如果发现它们有非常多的目标，或许我们应该将它们分割出来。

耦合

耦合获取的是连接不同类的复杂度。我们希望类与其它的类具有尽可能少、尽可能简单的联系，所以我们就可以在未来的事件中交换它们（例如改变网络框架）。

在很多编程语言中，这都是通过大量使用接口来实现的，它们抽象出处理特定逻辑的类，然后表征为一种适配层，每个类都可以嵌入其中。

分离关注点

分离关注点（SoC）是这样一种思想：软件系统必须被分割为功能上互不重叠的部分。或者说关注点必须分布在不同的地方，其中关注点表示能够为一个问题提供解决方案。

网页就是一个很好的例子，它具有三个层（信息层、表示层和行为层），这三个层被分为三个不同的地方（分别是 HTML，CSS，以及 JS）。

如果重新回顾一下我们的 RPG 例子，你会发现它在最开始具有很多关注点（应用 buffs 来计算袭击伤害、处理资产、装备条目，以及管理属性）。我们通过分解将那些关注点分割成更多的内聚类，它们抽象并封装了它们的细节。我们的 Hero 类现在仅仅作为一个组合对象，它比之前更加简单。

结语

对小规模的代码应用这些原则可能看起来很复杂。但是事实上，对于未来想要开发和维护的任何一个软件项目而言，这些规则都是必须的。在刚开始写这种代码会有些成本，但是从长期来看，它会回报以几倍增长。

这些原则保证我们的系统更加：

可扩展：高内聚使得不用关心不相关的功能就可以更容易地实现新模块。
可维护：低耦合保证一个模块的改变通常不会影响其它模块。高内聚保证一个系统需求的改变只需要更改尽可能少的类。
可重用：高内聚保证一个模块的功能是完整的，也是被妥善定义的。低耦合使得模块尽可能少地依赖系统的其它部分，这使得模块在其它软件中的重用变得更加容易。