小让の码场研磨设计模式
定义
设计模式：是指在软件开发中，经过验证的，用于解决在特定环境下、重复出现的、特定问题的解决方案。
- 特定问题：说明设计模式不是什么万能灵药，并不能解决任何问题，通常一个设计模式仅仅用于解决某个或某类特定的问题。因此不要迷信设计模式，也不要泛滥使用设计模式。
- 重复出现：只有这些特定问题“重复出现”，那么为这些问题总结解决方案才是有意义的行为。当这些问题再次出现时，就可以复用这些解决方案，而不用从头来寻求解决办法。
- 特定环境下：任何问题的出现都是有场景的，不能脱离环境去讨论问题的解决办法，因为就算不同环境下，就算是相同的问题，解决办法也不一定是一样的。
- 经过验证：每个人都可以总结一下用于解决在特定环境下、重复出现的、特定问题的解决方案，但并不是每个人总结的解决方案都算的上是设计模式，这些解决方案应该要有足够的应用来验证，并得到大家的认可，只有经过验证的解决方案才算得上是设计模式。
理解/认知
- 设计模式是解决某些问题的办法。要理解和掌握设计模式，其中心就在于对这些办法的理解和掌握，然后进一步深化这些办法所体现的思想层面上，将设计模式所体现的思考方式进行吸收和消化，融入到自己的思维中。
- 设计模式不是凭空想象出来的，是经验的积累和总结。从理论上来说，设计模式并不一定是最优秀的解决方案，有可能存在比设计模式更优秀的解决方案，也就是说设计模式是相对优秀的，没有最优，只有更优。
三个阶段
基本入门级
要求能够正确理解和掌握每个设计模式的基本知识，能够识别在什么场景下、出现了什么样的问题、采用何种方案来解决它，并能够在实际的程序设计和开发中套用相应的设计模式。
基本掌握级
除了具备基本入门级的要求外，还要求能够结合实际的应用场景，对设计模式进行变形使用。事实上，在实际开发中，经常会碰到与标准设计模式的应用场景有一些不一样的情况，此时要合理地使用设计模式，就需要对它们做适当地变形，而不是僵硬地套用。当然进行变形地前提是要能准确深入地理解和把握设计模式的本质，万变不离其宗，只有把握住本质，才能够确保正确变形使用而不是误用。
深入理解和掌握级
除了具备基本掌握级的要求外，更重要的是：
Important
要从思想上和方法上吸收设计模式的精髓，并融入到自己的思路中，在进行软件分析和设计的时候，能随意地、自然而然地应用，就如同自己思维的一部分。
对于这三个阶段，简单点来说就是，基本入门级就是套用使用，相当于能够依葫芦画瓢，很机械；基本掌握级就是能够变形使用，比基本入门级灵活一些，会适当变形使用；深入理解和掌握级才算是真正将设计模式的精髓吸收了，是从思想和方法的层面去理解和掌握设计模式，就犹如武功练到最高境界，“无招胜有招”。要像达到这个境界，没有足够的开发和设计经验，没有足够深入的思考，是不太可能达到的。
如何学习？🚀
- 首先要调整好心态，不要指望一蹴而就，不可浮躁。学习和掌握设计模式需要一个过程，不同阶段看这些设计模式会有不同的领悟和感受，有点像人生三重境界：看山是山，看山不是山，看山还是山。
- 方法论：要想真正理解和掌握设计模式，必须要上升到一定的难度和深度（比如说看源码，spring、mybatis...在这些项目中对设计模式运用的可以说非常巧妙），让你看完后思考，思考后应用，然后再看、再思考、再应用，如此反复，方能成就。
- 学习设计模式的几个步骤：
- 第一步：准确理解每个设计模式的功能、基本结构、标准实现，了解适合使用它的场景以及使用之后的效果；
- 第二步：实际的开发中，尝试去使用这些设计模式，并反复思考和总结是否使用得当，是否需要做一些变化。
- 第三步：再回头去看设计模式的理论，有了实际的模式应用经验再看设计模式，会有不同的感悟，一边看一边结合着应用经验来思考。比如：设计模式的本质功能是什么？它是如何实现的？这种实现方式还可以在什么地方应用？如何才能把这个设计模式和具体的应用结合起来？这个设计模式的出发点是什么？等等。可以有很多考虑的点，从不同的角度对设计模式进行思考。
- 第四步：多次重复学习设计模式的第二步和第三步。也就是在实际开发中使用，然后结合理论思考，然后再应用，再思考...如此循环，反复多次，直至达到对设计模式基本掌握的级别。简而言之，就是要使理论和实际相结合，理论指导实践，实践反过来加深对理论的理解，如此反复，成螺旋式上升。
Important
我亦无他， 惟手熟尔
事实上，到了基本掌握设计模式的水平后，只有一个建议，那就是反复地、深入地思考，别无他法。到了思想的层面，就得靠 " 悟 " 了。
七大设计原则
常见的面向对象设计原则包括七个，这些原则并不是孤立存在的，它们相互依赖，相互补充。
| 名称 | 简介 | 重要性 |
|---|---|---|
| 开闭原则（Open-Closed Principle，OCP） | 一个软件实体（如类、模块和函数）应该对扩展开放，对修改封闭。 | ⭐⭐⭐⭐⭐ |
| 依赖倒置原则（Dependence Inversion Principle，DIP） | 要面向抽象（接口）编程，不要面向实现编程。 | ⭐⭐⭐⭐⭐ |
| 单一职责原则（Single Responsibility Principle，SRP） | 类的职责要单一，不要存在多于一个导致类变更的原因。 | ⭐⭐⭐⭐ |
| 接口隔离原则（Interface Segregation Principle，ISP） | 使用多个专门的接口来取代单一的总接口，客户端不应该依赖它不需要的接口。 | ⭐⭐ |
| 迪米特法则（Law Of Demeter，LOD） | 一个类对于其他类知道的越少越好 & 只与你的直接朋友交流，不跟“陌生人”说话。 | ⭐⭐⭐ |
| 里氏替换原则（Liskov Substitution Principle，LSP） | 一个软件实体如果适用于一个父类，那么一定适用于其子类，程序中所有使用父类对象的地方必须能透明地使用其子类对象进行替换，并且保证原来程序的逻辑行为不变以及正确性不被破坏。 | ⭐⭐⭐⭐ |
| 合成复用原则（Composite Reuse Principle，CRP） | 尽量使用对象聚合（has-a）/组合（contains-a）而不是继承（is-a）关系达到软件复用的目的。 | ⭐⭐⭐⭐ |
23 种设计模式
Note
简单工厂模式(Simple Factory)，创建型模式，但是由于违反 " 开闭原则 "，因此并不属于 "GoF" 提出的 23 种经典设计模式！
| 名称 | 类型 | 定义 | 图片 |
|---|---|---|---|
| 策略模式（Strategy） | 行为型 | 定义一组算法，将每个算法都封装起来，并且使它们之间可以相互替换 |  |