让 Java 再次伟大！

一个值得与 IntelliJ IDEA 配套的现代 Java 脚手架，你的专属生产力工具。

时光飞逝，项目新增功能越来越多，你也创建了更多返回特定字段的 DTO 对象。你可能觉得这很正常——项目越大类文件不就越多吗？很不幸，项目越大类文件越多的定义不包括 DTO 类型的文件。我们有一种专业术语来形容项目中存在过量的 DTO 文件，叫做 **DTO 爆炸**。

这种方法看似很完美，实际却有一个重要缺陷：当你的 package.json 等依赖定义文件发生变化时，当前的 Layer 极其下属都会失效。也就是说，无论你是增加还是删除任何一个小依赖，那所有的依赖项都需要重新安装。在一个大项目中，任何细微的改动都触发成千上万的依赖重新解析与安装的成本实在太大了；好在任何成熟的构建工具，都提供一个基本功能叫「增量构建」。

本章介绍的分页解决方案实际还有两个小问题需要解决。这两个暂留给有兴趣的同学思考。若分数表中出现分数相同的玩家，分页时可能会产生什么问题？产生的这个问题怎么解决？你可以把你的想法和答案写在评论区，或者留言希望看到正确答案，我将会在后续的时间公布。我是 Chuck1sn，一个长期致力于现代 Jvm 生态推广的开发者。关注我的账号，第一时间收到文章推送。

相比之下，JOOQ 作为一款现代 ORM 框架，通过类型安全的 SQL、流畅的 API 设计、强大的动态 SQL 支持以及丰富的性能优化选项，提供了更加高效和灵活的持久层解决方案。SQL 与代码的分离使得开发者在编写和维护 SQL 时需要频繁切换上下文，增加了开发的复杂性。虽然 MyBatis 提供了一些基本的类型处理功能，但在复杂的业务场景中，这种类型不安全的设计仍然是一个明显的缺陷。性能优化是软件开发中的重要课题，JOOQ 提供了丰富的性能优化选项，使得开发者可以在处理大量数据时，保持较高的性能。

多年来，Maven 一直是 Java 项目的默认构建工具，它的依赖管理和项目结构标准化为开发者带来了极大的便利。虽然 Maven 在过去十几年中为 Java 开发者提供了可靠的服务，但随着项目复杂度的增加和技术的不断演进，Gradle 作为一种更现代化、灵活的构建工具，已经展现出了明显的优势。从构建脚本的灵活性、构建性能的提升、依赖管理的强大功能，到与现代化开发流程的集成，Gradle 都表现得更加出色。显然，Gradle 的语法更加简洁，且更接近编程语言，这使得开发者可以更容易地编写和维护构建脚本。

JOOQ 作为一个现代数据库操作框架，凭借其类型安全的 SQL、自动化代码生成、SQL 优先的设计理念以及丰富的现代特性，相对于 MyBatis 具有显著的优势。JOOQ 不仅提高了开发效率和代码的可维护性，还提供了更强大的功能和更灵活的 SQL 操作方式。在现代开发中，JOOQ 无疑是一个更先进、更高效的选择。对于那些追求代码质量、开发效率和现代特性的开发者来说，JOOQ 是一个不可忽视的强大工具。

ORM（Object-Relational Mapping，对象关系映射）是一种编程技术，用于在面向对象编程语言中实现对象与关系数据库之间的映射。ORM 的核心思想是将数据库中的表、行和列映射为程序中的类、对象和属性，从而让开发者能够以面向对象的方式操作数据库，而无需直接编写 SQL 语句。JPA ORM 和 JOOQ 是两种不同的数据库操作框架，它们的设计理念和适用场景各不相同。JPA ORM 通过将数据库操作抽象为对象操作，提高了开发效率和代码的可维护性，但在某些复杂的查询场景下可能存在性能问题。

Java 21 带来了许多令人兴奋的新特性，这些特性不仅提高了开发效率，还使得代码更加简洁和易读。虽然并非所有新特性都适用于每一个项目，但了解它们并考虑在适当的时候采用它们，将使你在业务开发中保持竞争力。如果你还在使用 Java 8，是时候考虑升级到 Java 21 了！不仅能够享受到最新的语言特性，还能获得性能上的提升和安全性的改进。

Docker 是一种容器服务，为了方便理解你可以认为他是一个轻量级的虚拟机。通过 Docker 创建的容器，在宿主机上共享硬件资源和底层系统与接口，同时又能提供互相隔离的应用程序环境。这是怎么做到的？由于 Linux 一切资源皆文件，所以只要简单的使用命名空间即可实现进程之间的隔离。

JOOQ 就是 SQL，当你在使用 JOOQ 的时候，你就是在使用 SQL；一切你能够在 SQL 标准下实现的操作，几乎都能在 JOOQ 以相同的方式实现。记住这句话，你就理解了整个JOOQ 的设计思想。使用 JOOQ，通过其对 SQL 标准的全面支持，外加将 SQL 运行时异常提前到编译时的类型安全机制， 将会帮你重新拿起 SQL 这个超级武器横扫一切需求。以上所有代码都可以在Github仓库中找到。如果你觉得教程有帮助，求顺手给一个Star。

数据库交互时，总是从 DSLContext 开始的。就是插入数据的方法——这有点像 JPA 的 Entity，将面向对象编程语言中的对象模型与关系数据库中的数据模型进行了映射。是一个 POJO 用以承载我们的数据，它也是通过 JooqCodeGen 插件自动生成的。这都是自动的——当对象在数据库里已经存在时，再调用。代表的数据库状态可能不是最新的，因为别的线程可能在你之后改变了数据库状态。是一个数据库表的对象，它是通过 JooqCodeGen 插件自动生成的。

这些编码哲学和你用什么语言和框架无关，任何单元测试都是靠这种思维写出来的。更多的单元测试内容待我后续整理好后发出。大家喜欢的话不妨购买一个MJGA 脚手架的 Pro 版本。

程序首先是写给人读的，然后顺便让机器能够运行。而编写编程的第一步就是命名，单元测试也一样。

虽然最终选择了使用 spring data 来操作 hbase，但这并不代表其他的方式都不好。每种工具都有自己的特点和不足，结合自己的实际情况做出选择才是最明智的做法。

当线程 A 持有独占锁 a，并尝试去获取独占锁 b 的同时，线程 B 持有独占锁 b ，并尝试获取独占锁 a 的情况下，就会发生 AB 两个线程由于互相持有对方需要的锁，而发生的阻塞现象，我们称为死锁。下面用一个非常简单的死锁示例来帮助你理解死锁的定义。// 线程a});// 线程b});try {System.out.println("线程a尝试获取integer.class");try {System.out.println("线程b尝试获取String.class")

建造者设计模式是将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示的一种手段。建造者设计模式是创建者模式之一。建造者模式往往用来和工厂设计模式做类比，因为这两种设计模式在设计思路上有很相似的地方。不过需要注意的是，搞清楚这两者的区别非常重要。当理解了两种设计模式对应的问题场景，以及分别用来解决什么样的问题以后，才算真正掌握了建造者设计模式。more。

适配器设计模式理解与运用上都比较简单。值得注意的是：适配器设计模式乍看起来与装饰器设计模式，但是这两个设计模式对应处理的是完全不同的问题。装饰器设计模式的重点在于动态的为对象添加责任，并且被装饰对象的结构，接口必需与组件相同，并且在装饰过程中，被装饰对象与组建的接口不能发生变化。而适配器设计模式的重点在于将不匹配的接口通过封装，将被适配对象的接口改变成为所期望的接口。

通过将“请求”封装成命令对象，来将操作的请求者与操作的执行者解耦，以便使用不同的请求队列或者日志来参数化其他对象，命令模式也支持可撤销的操作。命令设计模式通过一个中间人/件将请求封装为统一的命令，达到了与命令的执行者之间实现解耦的目的。这样的设计使得中间人的代码尽可能的简单，并且能够与任意的对象组合。完整的命令设计模式还拥有 undo，撤销上一次命令的功能。你可以试着自己来实现这个功能来加深对命令设计模式的理解。

本篇文章的总结很简单，你需要做的就是回顾一下上面所提到过的装饰器设计模式的特性，并尝试理解它。装饰器和被装饰对象具有相同的超类型。装饰器并非一定要是抽象类，也可以是一个接口。你可以用一个或多个装饰器包装一个被装饰对象。装饰器和被装饰对象都用有同样的超类型。对于客户端来说，使用装饰器和被装饰对象，都应该拥有一样的体验。装饰者可以在所委托被装饰者的行为之前、或之后，加上自己的行为。对象可以动态的，任何时候被你的装饰器所装饰。

用原型实例指定创建对象的种类，并通过拷贝这些原型创建包含了原对象中所有信息的新的对象。原型设计模式在某种条件下，是一种非常危险的，难以驾驭的设计模式。使用应该慎之又慎。more原型模式常常和其他设计模式搭配使用。注意深浅拷贝的区别。鉴于 Cloneable 糟糕的设计，对于任何自定义类，如果你没有充足的把握，请不要实现 Cloneable 接口。凡是实现了 Cloneable 接口的自定义类，一定要给用户提供安全的 clone 实现。

工程师思维是技术和艺术的结合。但技术天生的标准化与自动化属性会让艺术所占的比重越来越大。未来也许就像《死亡搁浅》中基于开罗尔粒子的 3D 打印技术一样，你只需要提供创意和设计，剩下的交给全自动化的基础设施去实现。未来是更加多元化的社会。像「销售」、「行政」、「会计」、「翻译」、「管理」这些单一的词汇不再适用于定义一个人的职业。这些标签会进入历史的长河而新的称谓会被创造出来。也许将来有一天，再次看到这些旧称时可能会感觉像「打字员」一样亲切和复古吧。

既然 Spring securtiy 的核心是 Filter chains，那我们只需要定义一个符合 security 标准的 filter ，再把自己的 chain 加入到 VirtualFilterChain 里面，就可以自定义身份验证的认证逻辑了。more之前提到过，大部分身份认证相关的过滤器都继承了 AbstractAuthenticationProcessingFilter。但是这一次我们让接下来的自定义过滤器不选择继承它，而是继承 OncePerRequestFilter。

明确我们要测试的目标是登录功能，所以只要启动 Spring Mvc 的依赖范围就可以了，其他层面的依赖可以用「打桩」来解决。进行单元测试会启动整个 Spring Boot 容器，并引入整个项目的。所以只需要隔离启动 Spring Mvc 环境，即可完成登录功能的测试了。

工厂设计模式是将拥有共性的产品抽象封装到工厂类中统一进行管理和创建，以达到降低使用者与产品之间的耦合度的目的一种手段。工厂设计模式是创建者模式之一，且从结构上被划分为三大类。三种不同的结构类型，分别对应处理不同的问题。more简单工厂模式工厂方法模式抽象工厂模式工厂设计模式分为三类。简单工厂，工厂方法，抽象工厂。简单工厂模式适合用于项目需求简单，产品很少并且几乎没有扩展可能性的情况。工厂方法模式适合用于产品簇单一，但却经常发生改变的情况。

Java 的内部类种类较多，语法比较复杂，用法也不尽相同。由于篇幅所限，本篇文章只对实际项目开发中用的较多的普通内部类与匿名内部类做一定介绍。内部类概括下来，可以分类为以下五种内部类。内部类嵌套内部类局部内部类接口内部类匿名内部类内部类通常用来解决“多重继承”的问题。当你希望隐藏一个类的实现，减少工程中.java 文件数量，或者这个类不想被扩展时，你可以通过匿名内部类来创建一个类的对象。java 虽然无法直接在语法层面上支持闭包，但是可以通过内部类来模拟一个闭包的程序结构。

我们来探讨一下 security 为什么要费尽周折，通过一长串的聚合和依赖把权限校验这个处理流程传递这么长的路径来实现？为什么不在一开始就是 make el Express and return el.value() 搞定所有的事情？我想这是因为 security 是一个 architect first 的设计产物。架构优先的设计，高扩展性都特别的重要。

security 加载的每种过滤器都有自己的使命和职责，其中负责表单登陆的是 UsernamePasswordAuthenticationFilter。security 中大部分和身份认证相关的过滤器都继承自 AbstractAuthenticationProcessingFilter，UsernamePasswordAuthenticationFilter 也不例外。

通过上面的示例，我们可以发现这又是一个利用组合来解决问题的设计模式。很显然组合要比继承更适合于扩展与维护。在之前的文章中，策略设计模式和状态设计模式非常相似，甚至他们的 uml 图都是一样的。那么为何状态设计模式要单独拿出来讲呢？这是因为策略设计模式的使用目的在于对象主动地去控制算法或者行为，而状态设计模式更倾向于定义好一组在客户端对象里可以互相转换的状态。

模板方法模式在项目中会经常运用到，需要熟练掌握。模板方法模式结构清晰。一般在项目中常常将不易于变化的部分封装为模板方法。而将易于变化的部分定义为抽象方法。模板方法模式易于扩展。面对新增需求，只需要增加相应的模板抽象方法实现子类就可以了，符合了接口的开闭原则。在多个子类拥有相同的方法，并且这些方法逻辑相同时，可以考虑使用模版方法模式。在程序的主框架相同，细节不同的场合下，也比较适合使用这种模式。

随着单元测试代码的日积月累，大量的 Thread.sleep 使测试速度越来越慢，单个本地测试也许还可以忍受，但全面自动化测试时乌龟一般的运行速度能让你抓狂。在测试代码在并发状态下的执行状况时，由于对测试结果的期待，或许会需要某些 Reduce 线程在 Map 线程之后才运行。另外请不要使用测试基类。调用对象的方法时尽可能的使用注入的对象，利用组合解决问题。在学习优秀的单元测试设计之前，了解一下糟糕的设计是快速掌握设计诀窍的“捷径”。学习完了上述测试的坏味道再加上适当的实践，就可以编写出合格的单元测试的。

合理编写单元测试，可使团队工程师告别牛仔式编程，产出易维护的高质量代码。随着单元测试覆盖率的上升，项目会更加的健壮，团队的信心满满，充满斗志。

从 Http2 诞生距今，大量网站都完成了对它的支持工作。实践证明在某些网站上启用 Http2 的确可让性能提高 30%以上。但最好的办法是尽可能详细的测试启用 Http2 所带来的风险和收益之后，再做出决定。

使用 ORM 的代价就是你的心智负担很大。除了要学习很多注解以外，还有很多夸张的概念需要深入理解，才能够写出能正常运行的代码。那么，有没有一种简单的方法，可以通过 SQL 的方式，直接查询出这种嵌套的结果集， 然后扔给客户端进行处理呢？答案是有的。

迭代器和可迭代对象代表的迭代器设计模式是一种约定。生成器就是一个实现了@@iterator的迭代器。迭代器和生成器既可以是同步也可以是异步。node 中的闭包函数天生就是命令式的。

枚举是对客观事物的归纳与自然语言的抽象。这听起来似乎容易和类混淆，这是正常的。因为在大部分面向对象的语言里，枚举就是类。

是的，OIDC 也有两种常用类型：授权码许可类型与隐式许可类型。由于 OIDC 在 OAuth2.0 的基础上被设计出来，所以 OAuth2.0 的流程基本上就是 OIDC 的流程。在 OIDC 的流程中，相对 OAuth2.0 有 3 个变化。授权服务器 + 资源服务器 = 认证服务器。根据授权码获取的 token 中包含 id_token。用户详情可以使用 UserInfo 端点获取。

代理、装饰器、适配器都是结构型模式，体现的设计思想都差不多——通过对象的结构来管理实体间的关系。Proxy 不仅用来实现设计模式，也可以用来完成很多其他功能和编程范式。就像 js 中的闭包函数一样，模块导出天生就是单例。

生活中有很多授权的场景，比如：假设你有一辆车，你现在指派一名代驾司机来帮你把车开回家，这就是一种授权。因为你授予了代驾司机使用你的小汽车的权利。在软件领域，授权通常指用户对某软件授予访问受保护资源权限的行为。OAuth2 就是为了将这种行为标准化所设计出来的协议。接上例。显而易见，代驾司机需要车钥匙才能帮你将车开回家。当然你可以将车钥匙交给代驾司机，但是显然让代驾司机使用专用的「泊车钥匙」显然更加安全。在软件领域，你的账号密码就相当于车钥匙，令牌则类似泊车钥匙。当然，并不是所有企业都拥有泊车钥匙。

属于不同源的资源之间互相请求时会产生「跨域访问」的问题。各大浏览器通常基于「同源策略」对跨域访问进行处理。而 CORS 则提供了跨域资源共享的解决方案，使的同源策略能够通过 CORS 变得更加的灵活，以满足不同场景的需要。