问题产生

很多时候，我们在系统中使用的对象有且仅仅需要一个，如果大量的实例化反而会产生性能问题或其他的不必要的麻烦。在我们的日常使用中有很多单例情况，比如说 windows 操作系统的资源管理器，有且只有一个资源管理器可以被使用。

如何设计该类，使其只能产生一个实例？我们必须保证这个类不能有多余的实例。

我们都知道在进行类的实例的时候，必须使用类构造器来进行，如果我们将类构造器设置为私有（private），禁止外部进行实例化时，便可以很方便的解决该问题。

懒汉模式

我们将构造器私有化，在类的内部进行实例，并且进行返回。这样便形成了我们的单例，确保了类中间只有一个实例。

class Singleton private constructor() {
    companion object {
        private var instance: Singleton? = null
        fun getInstance(): Singleton {
            if (instance == null) {
                instance = Singleton()
            }
            return instance!!
        }
    }
}

这样我们的类就形成了一个单例。

如上的写法是单例模式中的懒汉模式，为什么叫懒汉模式，因为该对象在使用的时候才会初始化。

线程安全的懒汉模式

但是上述的写法存在一定的问题。当线程 A 访问该方法时，代码执行到 getInstance 还没有进行判断或者实例化的时候，线程 B 也开始进行访问该方法。那么此时线程A就会进行一次实例化，线程 B 也会进行一次实例化。此刻就会出现问题，单例不再单例，两个线程创建的实例并不是同一个实例。

为了解决上述问题，我们可以对 getInstance() 进行加锁。确保同一时刻只能由一个线程访问getInstance 方法。这样便解决了线程同步问题。

class Singleton private constructor() {
    companion object {
        private var instance: Singleton? = null
        @Synchronized
        fun getInstance(): Singleton {
            if (instance == null) {
                instance = Singleton()
            }
            return instance!!
        }
    }
}

通过 @Synchronized 标记该方法为一个同步方法。

双检查锁

通过 @Synchronized 注解解决了多线程访问问题，但是随之而来的又出现了性能问题。如果线程 A 在执行 getInstance 方法的时候，线程 B 就必须等待。反之亦然。如果是一个高并发系统，那么就会带来巨大的性能损耗，总是有一堆线程在等待中。

面对上述的问题，那么就应该做出新的改变。公共写是危险操作，而公共读确实安全的。所以我们在进行创建的时候加锁，而不是在整个方法上。

class Singleton private constructor() {
    companion object {
        private var instance: Singleton? = null

        fun getInstance(): Singleton {
            if (instance == null) {
                synchronized(Singleton::class.java) {
                    if (instance == null) {
                        instance = Singleton()
                    }
                }
            }
            return instance!!
        }
    }
}

这里在加锁前和加锁后都进行了判断，通过这样的双检测来解决了功能上单例问题和性能上问题。

如果加锁后不检查会发生什么？

如果加锁后不检查，那么假设两个线程 A、B 同时进入了 getInstance 并且都执行到加锁前，如果不进行判断，那么只要其中一个线程申请了加锁，那么另外一个就要等待，当前一个释放锁后，后面的就会加锁继续实例化。此时又会产生两个不同的实例。而加锁后判断就避免了这样问题。

然而在 kotlin 中提供了更简单实现方式，通过 by lazy 来实现双检查锁。

class Singleton private constructor() {
    companion object {
        val instance: Singleton by lazy(mode = LazyThreadSafetyMode.SYNCHRONIZED) { Singleton() }
    }
}

饿汉模式

对于单例的另一个模式那就是饿汉模式。而饿汉模式的名字由来是因为饿了就需要吃，所以提前就都准备好(初始化)。因为已经提前都初始化好了，所以也不存在上述的线程安全问题。

object Singleton

总结

单例模式和其他创建型模式不同，单例更重要的是解决多次创建带来的性能上的问题。

工厂模式

要做一个 window 和 scrollBar,但是要有两种风格，传统风格(standard)和高级定制风格(custom)。如果按照之前我们的工厂模式来进行的话。

// 定义 window 和 scrollBar 的接口
interface Window {
    fun show(scrollBar: ScrollBar)
}

interface ScrollBar {
    fun scroll()
}

// 实现 标准窗口 和 标准滚动条
class StandardWindow : Window {
    override fun show(scrollBar: ScrollBar) {
        println("标准窗口 ${scrollBar.scroll()}")
    }

}

class StandardScrollBar : ScrollBar {
    override fun scroll() {
        println("标准滚动条")
    }
}

// 实现 定制化窗口 和 定制化滚动条
class CustomWindow : Window {
    override fun show(scrollBar: ScrollBar) {
        println("定制窗口 ${scrollBar.scroll()}")
    }

}

class CustomScrollBar : ScrollBar {
    override fun scroll() {
        println("定制滚动条")
    }
}

// 定制 window 工厂
interface WindowFactory {
    fun create(): Window
}

// 定制 scrollBar 工厂
interface ScrollBarFactory {
    fun create(): ScrollBar
}

// 产生 标准化窗口工厂
class StandardWindowFactory : WindowFactory {
    override fun create(): Window {
        return StandardWindow()
    }
}

// 产生 标准化滚动条工厂
class StandardScrollBarFactory : ScrollBarFactory {
    override fun create(): ScrollBar {
        return StandardScrollBar()
    }
}

// 产生 定制化窗口工厂
class CustomWindowFactory : WindowFactory {
    override fun create(): Window {
        return CustomWindow()
    }
}

// 产生 定制化滚动条工厂
class CustomScrollBarFactory : ScrollBarFactory {
    override fun create(): ScrollBar {
        return CustomScrollBar()
    }
}

fun main() {
    val windowFactory = StandardWindowFactory()
    val barFactory = StandardScrollBarFactory()
    val window = windowFactory.create()
    val bar = barFactory.create()
    window.show(bar)
}

进行这样的调整，表面看是完成了功能的设计，也将对象的产生者和使用者分离，同时扩展性增强。但是，也出现了新的问题。如果使用不正确，或者客户端调用时一不留神，客户端的代码将可能成为标准窗口中出现定制滚动条，或者定制窗口中是标准滚动条。

fun main() {
    val windowFactory = StandardWindowFactory()
    val barFactory = CustomScrollBarFactory()
    val window = windowFactory.create()
    val bar = barFactory.create()
    window.show(bar)
}

按照这个情况来说，生成的对象并不是匹配的。所以我们要进行优化。

工厂合并

如果将相同的工厂合并在一起，那就不会出现当前的这样情况。将相同风格的界面存放到一个工厂内，这样就不会出现上述的混搭的问题。通过同样的一个工厂生成相同的一系列

interface Factory {
    fun createBar(): ScrollBar
    fun createWindow(): Window
}

class CustomFactory : Factory {
    override fun createBar(): ScrollBar {
        return CustomScrollBar()
    }

    override fun createWindow(): Window {
        return CustomWindow()
    }
}

class StandardFactory:Factory {
    override fun createBar(): ScrollBar {
        return StandardScrollBar()
    }

    override fun createWindow(): Window {
        return StandardWindow()
    }
}

当工厂完成合并的时候，这样通过一个工厂就可以创造出一系列相关的类。

同时完成了在运行时完对工厂和具体类的依赖，而在编译时不会产生依赖，从而进一步进行了解耦。之前的工厂模式更像是抽象工厂模式的特例，每个工厂只生产一类型产品。

将对象的创建和使用过程分开，并且有时候创建一个对象并不只是单独的调用其类构造函数，我们可能需要进行很多初始化的设置，这样势必会出现代码重复的问题。以后进行修改时，需要多处修改，从而增加维护难度。

参数化工厂

有些地方也叫做个这个方法为简单工厂模式。该模式使得工厂方法可以创建多种产品。采用一个标识要被创建的对象种类,，通过标识来让工厂确定创造哪个类。

interface Product {
    fun show();
}

class MyProduct : Product {
    override fun show() {
        println("my product")
    }
}

class YourProduct : Product {
    override fun show() {
        println("your product")
    }
}

class OtherProduct : Product {
    override fun show() {
        println("other product")
    }
}

class ProductFactory {
    fun create(name: String): Product {
        return when (name) {
            "my" -> {
                MyProduct()
            }
            "your" -> {
                YourProduct()
            }
            else -> {
                OtherProduct()
            }
        }
    }
}

fun main() {
    val factory = ProductFactory()
    val product = factory.create("my")
    product.show()
}

那么如果之后需要继续增加或减少一个产品，那么就需要在 ProductFactory 中 when 语句进行更改。看似简单的操作，其实已经违反了我们的设计原则开闭原则，对修改应该是关闭的。所以说简单工厂模式是存在一定的缺陷的，并不能符合我们日后的扩展性。

工厂模式

针对上述问题，我们可以采取不同的方式去实现。来符合开闭原则。针对不同的 Product 采用不同的工厂方法。通过 Factory 接口来设定子类工厂。这样通过客户端的调用，便可以完成对象的产生。

interface Product {
    fun show();
}

interface Factory {
    fun create(): Product
}

class MyProduct : Product {
    override fun show() {
        println("my product")
    }
}

class MyProductFactory : Factory {
    override fun create(): Product {
        val product = MyProduct()
        // 其他初始化操作
        return product
    }
}

class YourProduct : Product {
    override fun show() {
        println("your product")
    }
}

class YourProductFactory : Factory {
    override fun create(): Product {
        val product = YourProduct()
        // 其他初始化操作
        return product
    }
}

class OtherProduct : Product {
    override fun show() {
        println("other product")
    }
}

class OtherProductFactory : Factory {
    override fun create(): Product {
        val product = OtherProduct()
        // 其他初始化操作
        return product
    }
}

fun main() {
    val factory = YourProductFactory()
    val product = factory.create()
    product.show()
}

UML

无论是参数化方法的工厂模式，还是通过单独的工厂去逐步生成，都做到了使用者和生产者的解耦。同时工厂模式还对开闭原则做了很好的完善。

动态的给一个对象添加一些额外的职责。就增加功能来说，Decorator模式现必生成子类更加灵活。–GOF 设计模式

该设计模式是让子类更加灵活，给某个对象而不是类添加功能。

坏代码

例如当前有一个流操作(Stream)，分别有文件流(FileStream)、内存流(NetStream),而我们分别要对这些流进行编码(Ascii7)和压缩(Compressing) 或者还要编码和压缩一起搞，如果我们按照正常思维来写的话，将会产生很多很多的类，UML如下：

如果按照这种思维，以后再给流继续添加功能，有着更多功能的组合，那么就会产生更多的类，并随着日后代码的扩展，子类会不断的膨胀。这些类除了部分功能不同外，基本代码都极其相似。

interface Stream {
    fun read(path: String)
}

open class FileStream : Stream {
    override fun read(path: String) {
        println("FileStream.read $path")
    }
}

open class MemoryStream : Stream {
    override fun read(path: String) {
        println("MemoryStream.read $path")
    }
}

class Ascii7FileStream : FileStream() {
    override fun read(path: String) {
        println("编码")
        super.read(path)
    }
}

class Ascii7MemoryStream : MemoryStream() {
    override fun read(path: String) {
        println("编码")
        super.read(path)
    }
}

class CompressingFileStream : FileStream() {
    override fun read(path: String) {
        println("压缩")
        super.read(path)
    }
}

class CompressingMemoryStream : MemoryStream() {
    override fun read(path: String) {
        println("压缩")
        super.read(path)
    }
}

class CompressingAscii7FileStream : FileStream() {
    override fun read(path: String) {
        println("压缩")
        println("编码")
        super.read(path)
    }
}

class CompressingAscii7MemoryStream : MemoryStream() {
    override fun read(path: String) {
        println("压缩")
        println("编码")
        super.read(path)
    }
}

划分职责

此时，可以看到类Ascii7FileStream 和 Ascii7MemoryStream 的 read 操作中编码操作是相同的，唯一的不同仅仅是流的读取，一个是从文件读取，一个是从内存读取。产生了代码的冗余，不断的重复。而针对不同点 20 行和 27 行也不是完全的不同。

稍微进行一下代码的修改，将继承改为组合。

class Ascii7FileStream {
    private lateinit var stream: FileStream

    override fun read(path: String) {
        println("编码")
        stream.read(path)
    }
}

class Ascii7MemoryStream {
    private lateinit var stream: MemoryStream

    override fun read(path: String) {
        println("编码")
        stream.read(path)
    }
}

经过修改的代码，发现针对 read 方法的不同点，此刻也成为了相同点。我们并没有修改了代码的功能，仍旧是原来的功能。而此刻 FileStream 和 MemoryStream 都有公共的父类，那么就可以接着进行修改，将编译时依赖，修改为运行时依赖。让代码在运行时在确定具体的类型(多态)。

class Ascii7FileStream(private var stream: Stream) {

    override fun read(path: String) {
        println("编码")
        stream.read(path)
    }
}

class Ascii7MemoryStream(private var stream: Stream) {

    override fun read(path: String) {
        println("编码")
        stream.read(path)
    }
}

此时，Ascii7FIleStream 和 Ascii7MemoryStream 已经变得完全一样，此刻我们也不再需要两个类，只需要一个类 Ascii7Stream。同理，针对压缩类也可以合并为一个类 CompressingStream。

class Ascii7Stream(private var stream: Stream) {

    override fun read(path: String) {
        println("编码")
        stream.read(path)
    }
}

class CompressingStream(private var stream: Stream) {

    override fun read(path: String) {
        println("压缩")
        stream.read(path)
    }
}

组合加继承

此时，细心的朋友肯定发现了，你既没有继承父类或者抽象类，也实现接口，你怎么方法前面还是 override 啊！是啊，这个情况在 kotlin 上是语法错误的。所以就要把 override 去掉吗？当然也不可以，我们既然是实现 Stream 的功能，那就意味着要遵循 Stream 的规范。仍旧需要去实现 Stream 流的接口。

class Ascii7Stream(private var stream: Stream) : Stream {

    override fun read(path: String) {
        println("编码")
        stream.read(path)
    }
}

组合是为了更好的完成功能，将编译时依赖成为运行时依赖；而继承则是为第一点是符合 kotlin 语法、第二则是为了满足 Stream 的规范。

运行一下

fun main() {
    val fileStream = FileStream()
    val ascii7Stream = Ascii7Stream(fileStream)
    ascii7Stream.read("123")
    val memoryStream = MemoryStream()
    val compressingStream = CompressingStream(memoryStream)
    compressingStream.read("456")
}
// 编码
// FileStream.read 123
// 压缩
// MemoryStream.read 456

简单运行一下，可以发现编码和压缩都完成了，那么编码加密操作呢？其实我们也已经实现了。

    val fileStream = FileStream()
    val ascii7Stream = Ascii7Stream(fileStream)
    val compressingStream = CompressingStream(ascii7Stream)
    compressingStream.read("456")

只需要将上一步完成的 Stream 在进行新的操作即可。这样意味着 CompressingAscii7...这一系列的类就不需要再进行实现了。

现在再看我们的代码

interface Stream {
    fun read(path: String)
}

open class FileStream : Stream {
    override fun read(path: String) {
        println("FileStream.read $path")
    }
}

open class MemoryStream : Stream {
    override fun read(path: String) {
        println("MemoryStream.read $path")
    }
}

class Ascii7Stream(private var stream: Stream) : Stream {

    override fun read(path: String) {
        println("编码")
        stream.read(path)
    }
}

class CompressingStream(private var stream: Stream) : Stream {

    override fun read(path: String) {
        println("压缩")
        stream.read(path)
    }
}

相比于第一个版本的代码 59 行，9个类或者接口，而现在我们仅仅需要31行，5个类或者接口，无论函数还是类都相较于之前减少近一半，而且和之前完成的功能一样。

让代码变得更美一些

仔细观察代码，发现 CompressingStream和 Ascii7Stream 都有公共的属性(stream) ,我们可以将他们抽取到一个公共父类。

abstract class StreamDecorator(protected var stream: Stream) : Stream {
    override fun read(path: String) {
        stream.read(path)
    }
}

新写一个 abstract 类，让 CompressingStream 和 Ascii7Stream 去继承新的 StreamDecorator 类。通过装饰类，将代码结构分割开来。以后扩展，只需要继承 StreaDecorator 即可。

依赖倒置原则 (DIP)

高层模块(稳定)不应该依赖于低层模块(变化)，二者都应该依赖于抽象(稳定)。

抽象(稳定)不应该依赖于实现细节(变化)，实现细节(变化)应该依赖于抽象(稳定)。

例如：

class A 依赖 class B ,此时的 class A 为高层模块，class B 为低层模块。如果要进行修改使 class A 依赖 class C ， 那么必须要修改 class A 的源码。此时，就发生了高层模块依赖低层模块。如果使用一个公共的接口 interface D 抽象 class B 和 class C , 那么 class A 就可以依赖 interface D ,高层模块不依赖于低层模块。如果使 class A 也抽象一个抽象接口 interface IA，那么，只需要了解 interface IA 和 interface D 之间的关系即可，无需关心实现细节。此刻，便完成了高层模块和低层模块都依赖于接口，同时也完成了抽象不依赖于实现细节，实现细节依赖于抽象。

我们采用抽象接口定义好规则规范，而不需要关系具体实现，提高了设计的稳定性。

我们定义了两个类，一个为 Movie 另一个为 Television,通过 Television.play() 方法进行内容播放。

class Movie {
    fun show() {
        println("这是电影")
    }
}

class Television {

    fun play(movie: Movie) {
        movie.show()
    }

}

fun main() {
    val television = Television()
    val movie = Movie()
    television.play(movie) // 这是电影
}

目前来看没有问题，那么如果现在电视剧要播放动画呢？我们需要重新建立一个类 Cartoon，并且修改 play() 方法 和 main 函数。

此刻说明在设计上有问题，我们的高层模块(Television)依赖底层模块(Movie)。

如果先将 Movie 和 Cartoon 进行抽象，使 Television 不去依赖具体实现，而去依赖接口。

interface ITVContent {
    fun show()
}

class Movie : ITVContent {
    override fun show() {
        println("这是电影")
    }
}

class Cartoon : ITVContent {
    override fun show() {
        println("这是卡通")
    }
}

class Television {

    fun play(tv: ITVContent) {
        tv.show()
    }

}

fun main() {
    val television = Television()
    val cartoon = Cartoon()
    television.play(cartoon)
}

经过修改后，Television不在依赖任何一个具体的类，而是依赖他们的抽象接口，以后无论增加播放什么，例如添加一个广告 Ad.class 只需要添加新的类，并且实现 ITVContent 接口，就可以完成新的播放内容的更换。

如果要更换播放平台呢？不在电视上播放，而在电影院进行播放。

我们只需要添加一个 IPlayer 的接口，并且有未实现的 paly 方法。让 Television 和 Cinema 去实现即可。

interface IPlayer {
    fun play(content: ITVContent)
}

class Cinema : IPlayer {
    override fun play(content: ITVContent) {
        content.show()
    }
}

class Television : IPlayer {
    override fun play(content: ITVContent) {
        content.show()
    }
}

fun main() {
    val television = Television()
    val cinema = Cinema()

    val cartoon = Cartoon()
    television.play(cartoon)

    val movie = Movie()
    cinema.play(movie)
}

经过简单的修改，无论是 Television 还是 Cinema 都不在依赖具体的类，而是依赖抽象的接口，以后无论扩展什么播放方法和播放内容，都不需要对之前的类进行修改。同时也不存在抽象的依赖具体实现，而是具体实现全部依赖于抽象。完成了解耦问题，将变换进行了隔离。

开闭原则 (OCP)

对扩展开发，对修改封闭，类模块应该是可以扩展的，但是不可以修改。

什么叫做修改，什么叫做扩展？修改是指对已有的源代码进行修改，而扩展是对当前没有的类或者方法进行添加。

对于上述示例，第一次代码还没有进行修改的时候，代码就进行了修改，每次修改必须对源码进行修改来实现新的功能。最终的代码版本，进行新功能的添加只需要扩展新的类即可，无需对已有的代码进行修改。这样便实现了开闭原则。

单一职责原则(SRP)

不要存在多于一个导致类变更的原因，一个类只负责一项原则。每个类负责的职责不同，进行修改的时候不会对其他类造成影响或者改变。

里氏 Liskov 替换原则(LSP)

子类必须能够替换它们的基类，继承表达类型抽象。LSP 是继承复用的基石，只有子类可以替换父类，并且之前功能不受到影响时，父类才能真正的被复用。是对开闭原则的补充。

接口隔离原则(ISP)

类之间的依赖关系应该建立在最小的接口上。建立单一的接口，不要建立庞大臃肿的接口，接口中的方法尽量少，而不是去建立一个庞大的接口供依赖去使用。

其他原则

优先使用对象组合，而不是继承

继承表达的一种类属关系，例如 大熊猫🐼继承动物，动物继承于生物，这是表达了一种类属关系(is-a)。

继承在某种程度上破坏了封装性，子类父类耦合度较高。

例如子类无法继承多个父类，父类中的方法子类无条件拥有，从父类继承的方法不能在运行时进行改变。这些都时继承所带来的缺点或者不足。

而对象组合只要求被组合的对象具有良好的定义接口。

针对接口编程，而不是针对实现编程

不要将变量类型声明为具体某个类型，而是声明为接口；客服端无需知道对象的具体类型，只需要知道对象的接口；减少系统中各部分的依赖关系，从而实现“高内聚，低耦合”的设计。

接口标准化是软件开发的重要举措，面向接口设计可以使工程分工，代码解耦。

不同的设计模型对设计原则有着不同的依赖，设计原则指导的设计模式的进行。