《 javasprict 设计模式与开发实践 》 [GoF设计模式](https://blog.csdn.net/weixin_42607437/article/details/114482907) [趣学设计模式](https://kaiwu.lagou.com/course/courseInfo.htm?courseId=710#/detail/pc?id=6861) >[info] ## 学习设计模式 1. 我们需要先搞清楚**设计模式能解决哪些范围的问题**后，才能正确使用设计模式。**设计模式解决**的是**可复用**的设计问题，而类似可`靠性设计、性能设计、安全性设计、可服务性设计`等都**不是设计模式能够解决的** 2. 设计模式从不同项目中总结出来的通用经验，是为了帮助我们快速理解现有的系统，并从中找出共性规律，**如果没有足够的经验或者思考，反而容易引入错误的设计，造成更多的麻烦** 3. **好的设计从来不是看用的模式有多少，而是看如何合理利用模式的设计思想，以及如何利用模式解决真实的问题**。 1-3 [趣学设计模式](https://kaiwu.lagou.com/course/courseInfo.htm?courseId=710#/detail/pc?id=6861) >[info] ## 杂七杂八 1. **一个程序只做一件事，并做得很好**,**代码之间的相互影响越多，软件越复杂**。比如，A 依赖 B，B 依赖 C……一直这样循环下去，程序就会变得非常复杂，也就是我们编程中常说的，如果一个类文件写了上万行代码，那么代码逻辑将会非常难理解。 2. 减少代码复杂度，**通过减少硬编码来控制代码量**，对于技术复杂度来说，要想在整体上保持简单性，需要**在设计时就做好技术选型**，降低实现复杂度而言，可以使用**统一的代码规范** 3. 把软件设计成独立组件并能随意地组合，才能真正应对更多变化的需求，不要做**定制功能驱动**开发比如，用户需要一个“上传文件的红色按钮”，你就实现了一个叫“红色上传按钮功能”的组件，过几天变为需要一个“上传文件的绿色按钮”时，你再修改代码满足要求……这不是组合设计，而是直接映射设计，看似用户是需要“上传”这个功能，但实际上用户隐藏了对“不同颜色”的需求，解决思路 * **解耦**，代码与代码之间的依赖关系越多，程序就越复杂，只有将大程序拆分成小程序，才能让人容易理解它们彼此之间的关系。也就是我们常说的在设计时应尽量分离接口与实现，程序间应该耦合在某个规范与标准上，而不是耦合在具体代码实现逻辑上 * **模块化，可替换的一致性** 总结**高内聚、低耦合原则：模块内部尽量聚合以保持功能的一致性，模块外部尽量通过标准去耦合** 1-3[趣学设计模式](https://kaiwu.lagou.com/course/courseInfo.htm?courseId=710#/detail/pc?id=6861) >[danger] ##### 参考文档中比较好的语句 * 代码质量既是设计出来的，也是迭代优化出来的。换句话说，无论是前期的产品需求分析、架构设计，还是后期的详细代码设计与编码，都离不开良好的设计。（趣学设计模式）