构造函数应仅用于初始化必要状态，避免业务逻辑；推荐使用静态工厂方法、构建器模式和依赖注入来提升可维护性与测试性。
构造函数滥用在Java开发中很常见，容易导致代码难以维护、测试困难以及违反单一职责原则。要避免这类问题，关键是从设计层面规范对象的创建方式，并合理使用替代方案。
限制构造函数的职责
构造函数应只负责初始化对象的必要状态，不做实际业务逻辑处理。比如避免在构造函数中启动线程、读写文件或连接数据库。
例如，不要这样写：
new UserService() 会直接连接数据库应该把连接数据库的操作提取到独立的方法中，由调用方显式控制。这样更利于测试和解耦。
立即学习“Java免费学习笔记（深入）”；
- 构造函数只做字段赋值和基本校验
- 复杂初始化逻辑封装成独立方法
- 避免在构造中抛出非必要异常
使用静态工厂方法代替公有构造函数
静态工厂方法能提供更具可读性的创建方式，并且可以缓存实例、返回子类型，提升灵活性。
比如 Boolean.valueOf(boolean) 比 new Boolean(boolean) 更高效，还能复用常量实例。
- 命名清晰，如
fromString()、newInstance() - 可以返回已有实例，减少对象创建开销
- 便于后续替换为 builder 或依赖注入
考虑使用构建器（Builder）模式
当构造参数较多，尤其是存在可选参数时，使用构建器能显著提升代码可读性和安全性。
Android SDK 中的 AlertDialog.Builder 就是典型例子。
- 避免出现大量重叠构造函数
- 支持链式调用，代码更清晰
- 可以在 build() 阶段统一校验参数
依赖注入替代手动 new
过度使用 new 会导致硬编码依赖，不利于模块替换和单元测试。
使用 Spring 或 Dagger 等框架管理对象生命周期，让容器负责构造。
- 降低类之间的耦合度
- 方便 mock 依赖进行测试
- 集中管理复杂对象图
基本上就这些。合理控制构造函数的职责范围，结合静态工厂、构建器和依赖注入，能有效避免构造函数滥用带来的问题。不复杂但容易忽略。
