关于设计模式的闲聊时间

本文更像是一个记录文章，我希望记录下目前对设计模式的感觉，并希望能够保持持续更新。

2018年12月6日

先说说目前我对设计模式持有的状态以及学习的目的，排名不分先后，想到什么写什么（这样可能会显得很没有逻辑）

1. 知道有23种设计模式
2. 专门去了解过部分设计模式
   单例模式，工厂模式，装饰模式，代理模式
   没错，我就只专门去看了这四种设计模式而已
3. 在工作项目上只使用过单例模式和工厂模式，我所学习的其他两个模式并没有使用过，也许无意识的使用到过，但是自己意识不到那是已经被前人总结出来的设计模式。
4. 曾经想专门的好好学习一下设计模式，并希望借此提高我对项目的架构能力，但是学习了几个就没学了，即便购买了《大话设计模式》这种好评很多的书籍，我也没有坚持阅读并研究完毕。
5. 觉得设计模式是一个骗局，这里的骗局不是指设计模式本身是一场骗局（骗局这个词有些过分，应该用一个轻量级的词来形容，不过没想到用哪个轻量级的词，语文啊语文= =），而是觉得《大话设计模式》这本书中的东西是一场骗局，（没看过其他有关设计模式的书籍）原因如下：
   书中在讲解设计模式的时候，总会有一个小节专门用来介绍这种设计模式，并且添加相应的结构图。我上面提到的骗局，指的是这种结构图是一个骗局，如果按照这种结构图来对代码进行设计，得到的类会很多，我并不喜欢为了实现某个很普通的方法或者功能，而强行套用某种设计模式，除非当前这个情境非常非常用某个设计模式。
   再解释下骗局这个词，我觉得不需要按照这种结构图来实现某种设计模式，完全可以根据设计模式的概念进行设计。举个例子，大家都熟悉的单例模式，可能在你们的项目中会有类似这种形状的单例存在（很简陋的单例模式）：

public class Single {
    private static Single instance;
    private Single(){}
    public static Single getInstance() {
        if (instance == null) {
            instance = new Single();
        }
        return instance;
    }
}

但是单例模式的概念：单例模式，也叫单子模式，是一种常用的软件设计模式。在应用这个模式时，单例对象的类必须保证只有一个实例存在。许多时候整个系统只需要拥有一个的全局对象，这样有利于我们协调系统整体的行为。

参考维基百科：单例模式

但是我们可以灵活的把这种概念进行修改，比如单例对象的类必须保证只有一个实例，我们可以把这个类改成一个变量，或者其他什么东西，大结构、小分子之类的。
所以以下代码中的变量single，我也可以认为是单例模式。

public class Single {
    public static int single = 1;
}

我觉得能够跳出书中给定的结构图，或许设计模式的作者也不希望我们的思维局限在那些设计模式结构图上面。所以我一直很讨厌很多博客在讲设计模式的时候，就直接给一张很官方的结构图来说明一切，好像必须这样设计代码才是这种设计模式似的。可能很多人在接触设计模式的时候，通过结构图能够更好的了解设计模式是怎么设计的吧，虽然我不是很喜欢这个结构图，并几乎从来不研究结构图。
（顺便一说，最近看了下代理模式，看完之后，我内心就一个想法，这不就是面向对象吗。）

5. 最近又在研究设计模式，在了解完概念和看完例子之后，自己想出了一个场景并进行代码设计，在代码的设计过程中，发现类真的好多啊，参考上一条，所以我决定减少这个场景的类。如果类的数量到位了，会给人一种这个设计模式很标准的感觉，但是也会给我一种过度设计的感觉。所以我觉得，在某些场景，我使用了某种设计模式，如果按照结构图去进行设计，那么会给我一种过度设计的感觉（这句话是不是重复了），不按照结构图设计，别人可能会觉得我设计模式没学好，在瞎写什么的（虽然没人批评我的代码是否糟糕，因为根本就没人看）。如何让代码结构优雅又不显得臃肿，这可能是我毕生要研究的课题。

吹嘘时间：
接着上面所写的东西，大概唏嘘几句。每次我在看google工程师写的源码，或者著名的第三方框架源码的时候，都直接默认这些源码就是最优源码，默认这些源码既优雅又美丽，并希望自己设计和写出来的代码会给人这种感觉，或者给自己这种感觉。有些时候，看到优秀的源码，自己都忍不住惊叹，人脑真是个神奇的东西，居然可以实现结构那么复杂，又那么优雅的代码。（曾经因为看到优秀的源码直接对电脑屏幕上面的源码作揖= =），太巧妙了，明明程序员都没什么审美能力，但是设计的代码为啥那么优美。这可能就是编程的魅力吧。