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