如何让孩子爱上设计模式 —— 1.面向对象相关概述

2017-01-13 本文已影响287人 coder_pig

标签：设计模式初涉

描述性文字：

本节描述的是面向对象的相关概述，有以下三点：
面向对象的三大特性，类与类的六种关系以及面向对象的七大原则

面向对象的三大特性

封装（Encapsulation）

不需要知道对象具体实现细节，通过共有方法暴露对象的功能

继承（Inheritance）

使用已经存在的类作为基础类（父类），在此基础上建立新类（子类），
子类既可以复用父类的功能，也能进行扩展，从而提高了代码的复用。
另外，Java不像C++一样可以同时继承多个父类，只能够树形的继承，比如：
Animal -> Person -> Man，或者通过 接口和内部类 实现多继承！

多态（Polymorphism）

一个类实例的相同方法在不同情形下有不同的表现形式，一般有两种

编译时多态(OverLoading) —— 方法重载
运行时多态(OverRidding) —— 继承 + 方法重写 + 父类引用指向子类对象

关于这个运行时多态，可能有些不理解，举个例子：

class 小弟() {
    fun do() {
        println("搞事情")
    }
}

class 递茶小弟 : 小弟() {
    override fun do() {
        println("给大佬递茶")
    }
}

这个时候问题来了，如果有这样两行代码：

小弟 A = new 递茶小弟()
A.do()

问：调用的是do后打印的是"搞事情"还是"给大佬递茶"？
答：

，new后面是什么类型，动态类型就是什么类型。

类与类的关系

记忆口诀：鸡湿衣冠剧组(继承，实现，依赖，关联，聚合，组合)
前面两个继承和实现基本都知道，而后面的四个只是 语义层次 的区别，
两个类的相关程度，依赖 < 关联 < 聚合 < 组合
在此之前，相信很多朋友都没接触过UML类图，可能会看不懂，这个是类和接口

1.继承/泛化（Generalization）

一个是父类，一个是子类，用 空心三角箭头的实线 表示
从子类指向父类，或子接口指向父接口。

2.实现（Realization）

一个类实现接口，重写相关方法，用 空心三角箭头的虚线 表示

3.依赖（Dependency）

举个栗子：

class 递茶小弟 {
    fun 递茶() { 
        println("给大佬递茶")
    }
}

class 大佬 {
    fun main() {
        口渴()
    }
    
    fun 口渴() {
        递茶小弟 A = new 递茶小弟()
        A.递茶()
    }
}

大佬口渴了想喝茶，递茶小弟，而递茶小弟只是被当作递茶工具，
没什么卵用，递完茶小弟就可以走了（不持有引用）

具体表现：局部变量、函数参数、返回值

UML图(用实心带箭头虚线表示，从使用类指向依赖类)：

4.关联（Association）

举个栗子：

class 保镖小弟 {
    fun 护驾() {
        println("保护大佬")
    }
}

class 大佬 {
    private 保镖小弟 A = new 保镖小弟();
    fun main() {
        if(被人怼了) {
            A.护驾()
        }
    }
}

大佬一般身边有保镖小弟，这种小弟当然是要随叫随到的，所以要
保持联系（持有引用），比起递茶小弟，和大佬间的关系会强一些，
一个大佬可以有多个保镖小弟，而一个保镖小弟可能有多个大佬(25仔)。

具体表现：成员变量
UML图(实心箭头的实线表示，箭头指向被关联类，另外这个可以双向，一对多或多对多)：

5.聚合（Aggregation）

和关联一样是通过成员变量来表现的，不过关联是处于同一层次的，而聚合则
是 整体和局部 层次的，比如：社团和小弟，另外即使没有了社团，
小弟们依旧可以到别的地方搞事情。用 空心菱形加实线箭头 表示。

6.组合（Composition）

和聚合类似，只是程度更加强烈，共生死，组合类负责被组合类的生命周期，比如：
社团和大佬，如果没了社团，大佬也就就不能存在了。
用 实心菱形加实线箭头表示 表示。

最后捋一捋，根据这些关系列个大UML图吧：

面向对象七大基本原则

1.单一职责原则(Single Responsibility Principle)

每一个类应该专注于做一件事情。
即：高内聚，低耦合

2.开闭原则（Open Close Principle）

一个对象对扩展开放，对修改关闭。
即：对类的改动是通过增加代码进行的，而不是修改现有代码

3.里氏替换原则（Liskov Substitution Principle）

在任何父类出现的地方都可以用它的子类来替代。

4.依赖倒置原则（Dependence Inversion Principle）

要依赖于抽象，不要依赖于具体实现。

5.接口隔离原则（Interface Segregation Principle）

应当为客户端提供尽可能小的单独的接口，而不是提供大的总的接口。

6.迪米特原则（Law Of Demeter）

一个对象应当尽量少地与其他对象之间发生相互作用，使得系统功能模块相对独立。

7.组合/聚合复用原则（Composite/Aggregate Reuse Principle）

尽量使用合成/聚合的方式，而不是使用继承

注释性文字：

本文只是对相关概念过了一遍，理解理解，没有涉及具体
的代码实现细节，如若想查看更多内容可移步到工匠若水
的博客查看：

设计模式之面向对象与类基础特征概念
 设计模式之面向对象七大基本原则

或者翻阅《Android源码设计模式解析和实战》一书查看相关内容。

修改日志：

2017.1.23 部分内容修改