不管写的质量是好是坏【坚持】这件事确实是很困难的。最初的想法是通过写博客来督促自己，让自己把这个学习的过程记录下来，之前都只逛园子，很多东西记录到云笔记。但是云笔记和博客相比缺少一样东西，那就是分享，当别人发现有不对的地方可以指正，带来的点赞啊评论啊会进行正向激励，这样下次学习写东西的时候更有动力(不要说是最大的动力，最大的动力应该是源于自身的充实)。通过这样的正向反馈对自己的学习热情和学习态度都有很大的帮助，当没人反馈的时候也要坚持，因为我们要明白最大的收获是我们自己。
不过写博客确实费时间，一篇文章得花个2-5小时不等(对于我而言)。首先自己得先领会看懂才能写出来让别人看懂，其次自己得画图、写代码、测试等等，最后通篇写完得注意前后叙述逻辑排版顺序以及专业用词的准确性。当然这个是循序渐进的，我也是初次尝试，很多东西有待提高，学习知识嘛不寒碜。并且通过写的方式，首先学习一遍，写的过程再分析一遍，最后自己阅读调整，这样下来不仅加强了知识的记忆并且对细节的理解也更深刻。至于哪里深刻，这个东西只能自己体会了，很玄学。就像我在学习设计模式的过程中对于之前有些不太理解的设计仿若醍醐灌顶，因为之前接触过的系统可能到最后都没扩展过，所以有些模式并没有发挥它的价值，但是至少我知道了这个地方原来这样设计是为了扩展为了有一个更好的设计。
之前的文章开始写没有经验，应该给一个目录方便阅读或者把demo代码地址放出来。后面写了几篇才发现，最后想难得改，也不破坏最初的样子就一直写完了。所以在这里对模式进行一个总结吧分类，同时也相当于一个目录，方便查找对应文章。
设计模式书：
设计模式基础
抽象
封装
多态
继承
设计模式原则
设计原则名称
设计原则简介
遵循原则的设计模式
单一职责原则
(Single Responsibility Principle, SRP)
类的职责要单一，不能将太多的职责放在一个类中
Head First设计模式——适配器模式
Head First设计模式——组合模式
开闭原则
(Open-Closed Principle, OCP)
软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能
Head First设计模式——观察者模式
里氏代换原则
(Liskov Substitution Principle, LSP)
在软件系统中，一个可以接受基类对象的地方必然可以接受一个子类对象
基本原则
依赖倒转原则
(Dependency Inversion Principle, DIP)
要针对抽象层编程，而不要针对具体类编程
Head First设计模式——策略模式
Head First设计模式——装饰者模式
接口隔离原则
(Interface Segregation Principle, ISP)
使用多个专门的接口来取代一个统一的接口
基本原则
合成复用原则
(Composite Reuse Principle, CRP)
在系统中应该尽量多使用组合和聚合关联关系，尽量少使用甚
至不使用继承关系
Head First设计模式——策略模式
迪米特法则
(Law of Demeter, LoD)
一个软件实体对其他实体的引用越少越好，或者说如果两个类不必彼此直接通信，
那么这两个类就不应当发生直接的相互作用，而是通过引入一个第三者发生间接交互
Head First设计模式——外观模式
设计模式分类（分类的目的是帮助我们记忆，通过比较不同分类让我们对模式有清晰的概念）
创建型（创建模式涉及到将对象实例化，这类模式提供一个方法，将客户从所需要实例化的对象解耦）
单例模式(Singleton)
生成器模式(Builder)
原型模式(Prototype)
抽象工厂模式(Abstract Factory)
工厂方法模式(Factory Method)
行为型（只要是行为模式，都涉及到类和对象如何交互分配职责）