面向对象思想

• Java 编程思想 第四版
• 面向对象设计的 SOLID 原则
• 看懂 UML 类图和时序图
• UML 系列——时序图（顺序图）sequence diagram
• 面向对象编程三大特性 ------ 封装、继承、多态
• 跳出面向对象思想(一) 继承
• 跳出面向对象思想(二) 多态
• 跳出面向对象思想(三) 封装

一些面向对象思想和原则。

1. S.O.L.I.D

S.O.L.I.D 是面向对象设计和编程 (OOD&OOP) 中几个重要编码原则 (Programming Priciple) 的首字母缩写。

1.1. 1. 单一责任原则

当需要修改某个类的时候原因有且只有一个。换句话说就是让一个类只做一种类型责任，当这个类需要承当其他类型的责任的时候，就需要分解这个类。

1.2. 2. 开放封闭原则

软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。

1.3. 3. 里氏替换原则

当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有 is-a 关系。

1.4. 4. 接口分离原则

不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。

1.5. 5. 依赖倒置原则

1. 高层模块不应该依赖于低层模块，二者都应该依赖于抽象
2. 抽象不应该依赖于细节，细节应该依赖于抽象

2. 其他常见原则

除了上述的经典原则，在实际开发中还有下面这些常见的设计原则。

2.1. 1. 迪米特法则

迪米特法则又叫作最少知道原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解，不和陌生人说话。

2.2. 2. 合成复用原则

尽量使用对象组合，而不是继承来达到复用的目的。

2.3. 3. 共同封闭原则

一起修改的类，应该组合在一起（同一个包里）。如果必须修改应用程序里的代码，我们希望所有的修改都发生在一个包里（修改关闭），而不是遍布在很多包里。

2.4. 4. 稳定抽象原则

最稳定的包应该是最抽象的包，不稳定的包应该是具体的包，即包的抽象程度跟它的稳定性成正比。

2.5. 5. 稳定依赖原则

包之间的依赖关系都应该是稳定方向依赖的，包要依赖的包要比自己更具有稳定性。

3. 封装、继承、多态

封装、继承、多态是面向对象的三大特性。

3.1. 1. 封装

利用抽象数据类型将数据和基于数据的操作封装在一起，使其构成一个不可分割的独立实体，数据被保护在抽象数据类型的内部，尽可能地隐藏内部的细节，只保留一些对外接口使之与外部发生联系。用户是无需知道对象内部的细节，但可以通过该对象对外的提供的接口来访问该对象。

封装有三大好处：

1. 良好的封装能够减少耦合。
2. 类内部的结构可以自由修改。
3. 可以对成员进行更精确的控制。
4. 隐藏信息，实现细节。

以下 Person 类封装 name、gender、age 等属性，外界只能通过 get() 方法获取一个 Person 对象的 name 属性和 gender 属性，而无法获取 age 属性，但是 age 属性可以供 work() 方法使用。

注意到 gender 属性使用 int 数据类型进行存储，封装使得用户注意不到这种实现细节。并且在需要修改使用的数据类型时，也可以在不影响客户端代码的情况下进行。

public class Person {
    private String name;
    private int gender;
    private int age;

    public String getName() {
        return name;
    }

    public String getGender() {
        return gender == 0 ? "man" : "woman";
    }

    public void work() {
        if(18 <= age && age <= 50) {
            System.out.println(name + " is working very hard!");
        } else {
            System.out.println(name + " can't work!");
        }
    }
}

3.2. 2. 继承

继承实现了 is-a 关系，例如 Cat 和 Animal 就是一种 is-a 关系，因此可以将 Cat 继承自 Animal，从而获得 Animal 非 private 的属性和方法。

Cat 可以当做 Animal 来使用，也就是可以使用 Animal 引用 Cat 对象，这种子类转换为父类称为 向上转型 。

继承应该遵循里氏替换原则：当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有 is-a 关系。

Animal animal = new Cat();

3.3. 3. 多态

多态分为编译时多态和运行时多态。编译时多态主要指方法的重装，运行时多态指程序中定义的对象引用所指向的具体类型在运行期间才确定。

多态有三个条件：1. 继承；2. 覆盖父类方法；3. 向上转型。

下面的代码中，乐器类（Instrument）有两个子类：Wind 和 Percussion，它们都覆盖了 play() 方法，并且在 main() 方法中使用父类 Instrument 来引用 Wind 和 Percussion 对象。在 Instrument 引用调用 play() 方法时，会执行实际引用对象所在类的 play() 方法，而不是 Instrument 类的方法。

public class Instrument {
    public void play() {
        System.out.println("Instument is playing...");
    }
}

public class Wind extends Instrument {
    public void play() {
        System.out.println("Wind is playing...");
    }
}

public class Percussion extends Instrument {
    public void play() {
        System.out.println("Percussion is playing...");
    }
}

public class Music {
    public static void main(String[] args) {
        List<Instrument> instruments = new ArrayList<>();
        instruments.add(new Wind());
        instruments.add(new Percussion());
        for(Instrument instrument : instruments) {
            instrument.play();
        }
    }
}

4. UML

4.1. 1. 类图

1.1 继承相关

继承有两种形式 : 泛化（generalize）和实现（realize），表现为 is-a 关系。

① 泛化关系 (generalization)

从具体类中继承

② 实现关系 (realize)

从抽象类或者接口中继承

1.2 整体和部分

① 聚合关系 (aggregation)

表示整体由部分组成，但是整体和部分不是强依赖的，整体不存在了部分还是会存在。以下表示 B 由 A 组成：

② 组合关系 (composition)

和聚合不同，组合中整体和部分是强依赖的，整体不存在了部分也不存在了。比如公司和部门，公司没了部门就不存在了。但是公司和员工就属于聚合关系了，因为公司没了员工还在。

1.3 相互联系

① 关联关系 (association)

表示不同类对象之间有关联，这是一种静态关系，与运行过程的状态无关，在最开始就可以确定。因此也可以用 1 对 1、多对 1、多对多这种关联关系来表示。比如学生和学校就是一种关联关系，一个学校可以有很多学生，但是一个学生只属于一个学校，因此这是一种多对一的关系，在运行开始之前就可以确定。

② 依赖关系 (dependency)

和关联关系不同的是 , 依赖关系是在运行过程中起作用的。一般依赖作为类的构造器或者方法的参数传入。双向依赖时一种不好的设计。

4.2. 2. 时序图

http://www.cnblogs.com/wolf-sun/p/UML-Sequence-diagram.html

2.1 定义

时序图描述了对象之间传递消息的时间顺序，它用来表示用例的行为顺序。它的主要作用是通过对象间的交互来描述用例（注意是对象），从而寻找类的操作。

2.2 赤壁之战时序图

从虚线从上往下表示时间的推进。

可见，通过时序图可以知道每个类具有以下操作：

publc class 刘备 {
   public void 应战 ();
}

publc class  孔明 {
  public void  拟定策略 ();
  public void  联合孙权 ();
  private void 借东风火攻 ();
}

public class 关羽 {
    public void  防守荊州 ();
}

public class 张飞 {
   public void  防守荆州前线 ();
}

public class 孙权 {
   public void  领兵相助 ();
}

2.3 活动图、时序图之间的关系

活动图示从用户的角度来描述用例；

时序图是从计算机的角度（对象间的交互）描述用例。

2.4 类图与时序图的关系

类图描述系统的静态结构，时序图描述系统的动态行为。

2.5 时序图的组成

① 对象

有三种表现形式

在画图时，应该遵循以下原则：

1. 把交互频繁的对象尽可能地靠拢。

2. 把初始化整个交互活动的对象（有时是一个参与者）放置在最左边。

② 生命线

生命线从对象的创建开始到对象销毁时终止

③ 消息

对象之间的交互式通过发送消息来实现的。

消息有 4 种类型：

1. 简单消息，不区分同步异步。

2. 同步消息，发送消息之后需要暂停活动来等待回应。

3. 异步消息，发送消息之后不需要等待。

4. 返回消息，可选。

④ 激活

生命线上的方框表示激活状态，其它时间处于休眠状态。

5. 面向对象程序设计

5.1. 继承

继承从代码复用的角度来说，特别好用，也特别容易被滥用和被错用。不恰当地使用继承导致的最大的一个特征就是高耦合。 在这里我要补充一点，耦合是一个特征，虽然大部分情况是缺陷的特征，但是当耦合成为需求的时候，耦合就不是缺陷了。耦合成为需求的例子在后面会提到。

可见，代码复用也是分类别的，如果当初只是出于代码复用的目的而不区分类别和场景，就采用继承是不恰当的。我们应当考虑以上3点要素看是否符合，才能决定是否使用继承。就目前大多数的开发任务来看，继承出现的场景不多，主要还是代码复用的场景比较多，然而通过组合去进行代码复用显得要比继承麻烦一些，因为组合要求你有更强的抽象能力，继承则比较符合直觉。然而从未来可能产生的需求变化和维护成本来看，使用组合其实是很值得的。另外，当你发现你的继承超过2层的时候，你就要好好考虑是否这个继承的方案了，第三层继承正是滥用的开端。确定有必要之后，再进行更多层次的继承。

5.2. 多态

多态在面向对象程序中的应用相当广泛，只要有继承的地方，或多或少都会用到多态。然而多态比起继承来，更容易被不明不白地使用，一切看起来都那么顺其自然。在客户程序员这边，一般是只要多态是可行方案的一种，到最后大部分都会采用多态的方案来解决问题。

然而多态正如它名字中所暗示的，它有非常大的潜在可能引入不属于对象初衷的逻辑，巨大的灵活性也导致客户程序员在面对问题的时候不太愿意采用其他相对更优的方案，比如IOP。在决定是否采用多态时，我们要有一个清晰的角色概念，做好角色细分，不要角色混乱。该是拦截器的，就给他制定一个拦截器接口，由另一个对象（逻辑上的另一个对象，当然也可以是自己）去实现接口里的方法集。不要让一个对象在逻辑上既是拦截器又是业务模块。这样才方便未来的维护。另外也要注意被覆重方法的作用，如果只是单纯为了提供父类所需要的中间数据的，一律都用IOP，这是比直接采用多态更优的方案。

IOP能够带来的好处当然不止文中写到的这些，它在其他场合也有非常好的应用，它最主要的好处就在于分离了定义和实现，并且能够带来更高的灵活性，灵活到既可以对语言过高的自由度有一个限制，也可以灵活到允许同一接口的不同实现能够合理地组合。在架构设计方面是个非常重要的思想。

5.3. 封装

为什么面向对象会如此流行？我想了一下业界关于这个谈论的最多的是以下几点：

• 它能够非常好地进行代码复用
• 它能够非常方便地应对复杂代码
• 在进行程序设计时，面向对象更加符合程序员的直觉

第一点在理论上确实成立，但实际上大家都懂，在面向对象的大背景下，写一段便于复用的代码比面向过程背景下难多了。关于第二点，你不觉得正是面向对象，才把工程变复杂的么？如果层次清晰，调用规范，无论面向对象还是面向过程，处理复杂业务都是一样好，等真的到了非常复杂的时候，对象间错综复杂的关系只会让你处理起来更加头疼，不如面向过程来得简洁。关于第三点，这其实是一个障眼法，因为无论面向什么的设计，最终落实下来，还是要面向过程的，面向对象只是在处理调用关系时符合直觉，在架构设计时，理清需求是第一步，理清调用关系是第二步，理清实现过程是第三步。面向对象让你在第二步时就产生了设计完成的错觉，只有再往下落地到实现过程的时候，你才会发现第二步中都有哪些错误。

所以综上所述，我的观点是：面向对象是在架构设计时非常好的思想，但如果只是简单映射到程序实现上来，引入的缺点会让我们得不偿失。