一直以来，设计模式是一个令人头疼的课题，记得之前在A公司做智能客服项目时，刚开始只是一个小项目，不管什么设计模式，系统架构，全程直接上手敲业务代码，两三天时间就把所有的代码敲完上线使用，结果谁也没想到突然项目大起来了，十几个业务部门的业务一拥而上，开始招人，上手业务，结果。。。大家都是苦力干嘛，拼命加班，拼命填坑，十几个人的代码乱七八糟，大量重复业务，重复代码，单简单的一样表单业务查询就有三四不同的版本，新来的员工也在抱怨没学到任何技术，倒学会怎么跟业务吵架，那日子实在是不忍直视。。。
设计模式是什么？这个是老生常谈的问题了，它并不是教人如何设计用户界面，怎么学习编程语言，也不是告诉你什么是面向对象数据库等方法。设计模式是一套可以被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。在软件设计过程中可以设计成解决一些不断重复的业务，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路(比如太极拳套路等)，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。这样做的目的是为了提高代码的可重用性、代码的可读性，程序的可维护性和代码的可靠性。
通过学习理解设计模式有以下三个收获：
- 提高编程思维：可以提高我们的编程思维能力、编程理解能力和设计程序的能力。
- 程序设计标准化：可以让我们的程序设计更加标准化、代码编写工程化、提高开发效率、从而缩短软件的开发周期
- 代码易于理解：好的设计模式可以使代码设计的可重用性高、可读性强、可靠性高。代码结构更灵活、易于维护。
总的来说，设计模式只是一个引导。在实际的软件开发中，我们必须根据系统架构的应用程序特点恰当选择合适的设计模式。对于简单的程序，简单的业务场景，只需要一个简单的数据结构就可以解决的业务，没必要在上面花太多时间，简单的事情简单处理。但对于大型项目的开发或框架设计，用设计模式来设计代码，那肯定是上上策，必须选择设计模式。
对于每个标准来说，都有自己的基本要素，我们要了解明白设计模式的基本要素，这样我们就可以跟设计者有共同语言交流，设计模式通常有几个基本要素，比如：模式名称、别名、动机、问题、解决方案、效果、结构、模式角色、合作关系、实现方法、适用性、已知应用、例程、模式扩展和相关模式等，其中著名的GoF列举其中的四大要素：
- 模式名称：这只是一个代记词，就跟我们的人名一样，便于记忆，一个好的名称可以通过名称了解模式的问题、解决方案和效果，也可以帮忙我们思考，便于我们与其他人交流设计思路及设计结果，取一个恰当的模式名就跟我们平时写代码取一个好的方法及类一样，不是那么容易
- 问题(or 使用场景)：问题是描述我们在何时什么场景使用这个模式，它必须解释了设计问题(场景)或问题(场景)存在的前因后果，也可能描述了特定场景的设计思路、一种设计必须基于一个或多个问题 or 场景而设计的，这部分是设计模式中不可或缺的条件
- 解决方案：有了问题，就要有解决方案，我们了解到的模式就类似一个模板，解决某个问题或场景的模板，那么模板就有具体的设计或实现方式。解决方案就是针对这个问题 or 场景的一种设计组成部分，可以用于多种场合，它的思路并不只针对于特定的问题而设计或实现的，可以使用同类或相似的问题场景，而是提供设计问题的抽象描述和怎么用一个具有一般语义的元素组合(java语言中的类或对象组合)来解决这个问题。
- 效果：有了问题，有解决方案，当然要有解决方案的效果，总不能说我这个解决方案很厉害，但对于这个问题，效果不好，这不是扯淡吗？效果一般都是从两个方面来描述：优点、缺点。模式效果描述了模式应用的效果及使用模式应权衡的问题，对于评价一个设计选择和理解使用模式的代价及好处是非常有意义的，软件的大多数比较关注对时间和空间的衡量，也是表达了语言和实现问题效果。这对系统的灵活性、扩充性或可移植性有一定的影响。
以上是我个人对于重温设计模式的看法，当然每个人思考问题的方式不一样，出发点不同，会产生对于设计模式的理解不一样，一个人设计出来的程序对于另一个人来说只是基本思路，基本构造部分而已，有时间大家可以一起交流探讨。