NPE2.0的博客

单例模式大概是所有设计模式里最简单、也是最容易被写错的一个——网上随便一搜就有五六种写法，简历上也几乎人人都会背"饿汉懒汉双重检测"这几个词。但真放到高并发场景下追问一句"这样写到底安不安全"，很多人就说不清楚了。这篇把这几种写法拆开揉碎，讲清楚它们各自在赌什么、又是靠什么兜底的。

模块一花了七篇讲设计原则和思想，从这篇开始正式进入 23 种设计模式的具体内容，第一站是创建型模式。创建对象这件事，语言层面一个new关键字就能搞定，可现实中围绕它却衍生出单例、工厂、建造者、原型四种模式。它们到底是在解决同一个问题的四个方面，还是四个互不相干的问题？这篇先把全家福拍一张，后面四篇再逐个展开细讲。

模块一从面向对象聊到设计原则，一直绕着"怎么组织代码"这个问题打转。这篇作为模块一的收官篇，把视野拉大到编程范式层面——面向对象、面向过程、函数式，这三者的边界到底划在哪。尤其是函数式编程，它里面说的"函数"，压根不是你平时里写的那个函数，这个误解不厘清，后面看 Stream、Lambda 这些语法会一直觉得别扭。

学完一堆设计模式之后，最容易踩的坑不是"不会用"，而是"用过头"——看哪段代码都想套个模式上去，结果代码没变好读，反而多了几层莫名其妙的抽象。另一个极端是完全不设计，几十行的 if-else 一路堆到底。这篇不讲某个具体模式，讲怎么在这两个极端之间找到那个平衡点。

自动驾驶、图像识别、高性能消息队列——这些系统难，难在技术本身有门槛，靠算法和领域积累才能啃下来，不是多拉几个人就能提速的。但更多人日常在做的，是另一种难：技术上没什么新鲜的，业务逻辑却盘根错节，代码量一大、参与的人一多，改一个小需求都得小心翼翼，生怕牵一发动全身。这篇不聊前者，聊后者——面对这种"不难但复杂"的系统，到底该从哪几个角度想问题。

业务开发天天在写的 Controller-Service-DAO 三层架构，是绝大多数人入行第一天就学会的标准套路。但如果我告诉你，这套写法在很多人眼里是反模式（anti-pattern），是彻头彻尾的面向过程编程，你是不是要愣一下——这不是最正统的 Java Web 开发方式吗？这篇就用一个账户扣款的真实需求，把这件事的来龙去脉讲清楚：到底哪里"面向过程"了，充血模型和 DDD 又是怎么解决这个问题的。

用 Java 写代码 ≠ 写的是面向对象风格代码。Utils满天飞、getter/setter 无脑生成、贫血模型——这些都是披着面向对象外皮的面向过程代码。这篇先打地基：OOP 是什么、四大特性各解决什么问题，再看几个"看着面向对象、实际面向过程"的反例。

"学设计模式有什么用？"这个问题我以前答不上来——直到写出被同事吐槽"看不懂"的代码、面试被追问"单例线程安全怎么保证"卡壳、看 Spring 源码被一堆绕晕，才明白设计模式不是背 23 个类图，而是一套让复杂代码"可读、可扩展、可维护"的方法论。这篇作为整个系列的导读，先不讲任何一个具体模式，把地图画出来：代码质量到底怎么评价、面向对象/设计原则/设计模式/编码规范/重构这五个概念到底是什么关系、23 种模式的全景分类长什么样。后面 31 篇按这张地图逐一展开。