最近读了Martin Fowler关于IoC和DI的文章，觉得之前SpringBoot-IoC-DI写的还是太过狭隘。因此本篇对这个话题进行补充。 IoC 和 DI 的关系 在上一篇文章中，首段的描述似乎把DI定义为与IoC同级的概念，这种暗示是错误的。 而Spring Core完成了两个关键概念：IoC（Inversion of Control，控制反转）和DI（Dependency

桥接模式(Bridge Pattern)是一种结构型模式。它的主要作用是将抽象部分与实现部分分离，使它们可以独立变化。 场景 有一个形状Shape类，从它扩展出两个子类：长方形Rectangle和 圆形Circle。假设需要在另一个维度颜色Color上，对Shape再进行扩展细分。如果只有红色Red和蓝色Blue两种颜色，那么一共需要四个类覆盖所有的组合。 12345

创建型模式已经全部介绍完，接下来是结构型模式。 在以往的文中提过，结构型模式和行为型模式边界比较模糊。根据定义，结构型模式侧重于类和对象的组合以构建灵活且高效的结构，而行为型模式侧重于类和对象之间的通信和职责分配。但结构和行为本身就会相互影响，因此会存在模棱两可的分类。例如代理语义上是个行为，但是代理模式是结构模式；中介者组织了组件间的结构关系，但是中介者模式是行为模式。 结构模式和行为模式都

单例模式(Singleton)是一种创建型模式。目的是，确保类只有一个实例， 并提供一个访问该实例的全局节点。 会产生这样的需求，理由也十分自然：在全局范围内使用同一个对象或资源，方便统一配置与管理。典型的场景如：配置类、日志类、资源管理类（数据库连接池）等。 在SpringBoot常见的分层架构中，Controller层、Service层通常不需要多个实例，因其成员变量通常为对其他Serv

BeanFactory 12package org.springframework.beans.factorypublic interface BeanFactory The root interface for accessing a Spring bean container. 今天讲到Spring中最关键的概念BeanFactory。从注释中可以得到，beanFactory就是

近期，在Github上读到了关于源码学习的仓库，并跟着学习了Spring全家桶源码。这对设计模式的学习和程序设计是十分有帮助的，因为Spring源码中存在大量设计模式的优秀实践。但设计模式的广泛运用也导致Spring类之间关系复杂，源码阅读费力。 在学习过程中，发现自己对Spring中许多概念是模糊的。这可能是因为学习Spring时，都是从使用侧考虑，忽略了非常多底层细节。对于概念的认知，更多来

原型模式(Prototype)是创建型模式中最简单、最不重要的一个设计模式。说不重要不是因为用不到，而是在实践过程中通常使用了其他更简便的方法进行了替代。前两篇设计模式在撰写时文本量超过了预期，本篇尽量言简意赅。 场景 假设现在有个对象，需要根据这个对象中的属性，去创建新的同类对象。这么做的目的可能是重新创建对象过程复杂，直接从已有对象中复制相当于节省了许多步骤，可以快速获取大量同类对象。也可

本篇简单描述生成器模式(Builder)的结构和特征，并着重讨论为什么要使用生成器模式的思考。 场景 生成器模式是一种创建型模式，目的是创建一个对象。通常创建对象，可以通过new关键字调用构造函数，并在构造函数中传入需要的参数。这在对象结构简单时十分容易。但当类的成员变量变得众多类型复杂，且某些参数可以不是必输的时候，会变得复杂。在一些语言，例如Python中，可以通过提供方法的默认参数，避开

接下来就是介绍具体的比较经典的设计模式。 按照常规的分类方式，设计模式分为创建型模式、结构型模式和行为型模式。创建型模式关注对象的创建，结构型模式关注类/对象之间的关系，行为型模式关注对象之间的交互。 实际上，结构型模式和行为模式的边界很模糊。不同对象/类之间的关系限制了之间的交互模式，交互模式又依赖于对象之间的关系。总之，结构型模式关注系统的静态结构，用于构建对象和类之间的关系，而行为型模式

距离上一次写博客已经过去了三个多月，一直忙于工作。 上次说到，设计原则是使得代码拥有更好复用性和拓展性的指南针，是一种基于优秀代码的经验总结。既然是经验总结，不同学者必然存在着不同归纳角度。上次提到的封装变化、面向接口而不是面向实现、组合优于继承原则是一种归纳，这次要讲的SOLID原则也是一种归纳。这些原则本是并列关系，但实际又会觉得互相关联、交融。因为本身可能都是对同一件事情，不同角度的描述。