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

单例模式(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原则也是一种归纳。这些原则本是并列关系，但实际又会觉得互相关联、交融。因为本身可能都是对同一件事情，不同角度的描述。

最近工作比较繁忙，没有太多时间学习和写笔记，忙里偷闲写下了这篇。 在大型Java项目中，通常会有多个主应用。主应用是指具有诸如public static void main程序入口，可以被java执行的模块。Maven概念中一个packing属性不为pom的pom文件对应一个模块，可以单独编译、测试和打包。与应用相对的概念是库，不包含程序入口，但可以提供特定功能和服务被其他应用调用。在一个项目中

最近在学习JVM的过程中，遇到了一个十分容易混淆的概念，字符串池。 有关字符串池的代码，运行结果始终没有和预期对应上。查询了大量资料无果后，在stackoverflow上发布了提问，提问链接。提问后的半天内（在此感叹下国际友人的钻研精神），有两位大佬和我就此问题进行了探讨。在交流中对这个概念的理解逐渐清晰。通过将这个事情记录下来，来理清自己的思路，并分享给更多人。 由于具体情况可能在不同JVM