《Effective Java》，第一条，用静态工厂方法代替构造器

在创建类时，若需要初始化多个参数，重叠构造器模式可行，但仍不利于客户端编写，且难以阅读；JavaBeans模式可行，但是会使得类可能处于不一致状态。而构建器Builder能够较好的处理多参数情况。Builder模式在创建类时，需要创建构建器，有性能开销；且代码也比较冗长。《EJ》推荐一般在有4个以上时用它，毕竟谁会为了几个家具请师傅呢？如果将来有添加参数的可能，一开始就使用构建器更好。

静态工厂方法将 “实例创建逻辑” 封装在方法内部，若未来需要修改 “是否返回单例”（如改为池化实例、按需创建），只需修改方法实现，无需改变对外暴露的 API（方法名、参数、返回值），现有调用代码无需调整。单例的核心是 “唯一实例的访问入口”，而直接暴露变量，本质是 “把实例当工具类的静态变量用”，无法引导开发者形成 “通过统一入口获取实例” 的习惯。是 “行为入口”，天然传递 “获取实例” 的动作

主要针对工具类，即仅包含静态方法和静态域的类。

《Effective Java》第五条的核心思想是：类不应自行创建其依赖的资源（如数据库连接、网络服务、配置信息等），而应通过外部传入（即 “依赖注入”）的方式获取，以提高灵活性、可测试性和复用性。很多类在实现时会 “硬编码” 依赖资源，例如在类内部直接创建数据库连接、实例化特定服务等。这种做法存在三个严重问题：硬编码的本质是 **“类自己创建依赖”，而测试需要的是“替换依赖为测试替身（如 Moc

ps：BigInteger类中certainty值主要用于素数的生成，但是随机大素数判断成本极高，使用的是一种算法，certainty用于2^(-certainty)，2^(-certainty)表示不是素数的概率，因此certainty越大，是素数的概率越大。1. 用户只知道会返回EnumSet的子类，但是并不用考虑有多少个子类、使用哪一个子类。2. 服务侧在对EnumSet更新迭代时，不管是添