高内聚低耦合的关键是用class封装单一职责、依赖注入、面向接口编程和优先组合。如拆分LoginManager为Validator/Client/Store/Controller；通过构造函数注入paymentService；约定charge方法契约；用组合替代继承，如Order持有logger而非继承日志类。
用 class 语法写高内聚低耦合的 JavaScript 代码，核心不是“用不用 class”，而是**用 class 封装明确职责、隐藏实现细节、依赖抽象而非具体实现**。class 本身不保证内聚或解耦，关键在设计思路。
职责单一：一个 class 只做一件事
高内聚的前提是每个类有清晰、窄小的边界。比如处理用户登录，不要把网络请求、表单校验、本地存储、UI 更新全塞进一个 LoginManager 类里。
更合理的拆分：
-
LoginFormValidator：只负责字段格式、必填项等校验逻辑 -
AuthApiClient：只封装登录 API 调用（含错误统一处理） -
SessionStore：只管 token 的存取与过期检查 -
LoginController：协调以上三者，但不包含它们的内部逻辑
这样每个类容易测试、复用，改校验规则不影响网络层。
立即学习“Java免费学习笔记（深入）”；
依赖注入：避免在 class 内部 new 具体实现
低耦合的关键是让类不“自己找依赖”，而是由外部传入。避免这样写：
class OrderProcessor {
constructor() {
this.paymentService = new StripePaymentService(); // ❌ 硬编码依赖
}
}改成依赖注入：
class OrderProcessor {
constructor(paymentService) { // ✅ 依赖作为参数传入
this.paymentService = paymentService;
}
}
<p>// 使用时才决定用哪个实现
const processor = new OrderProcessor(new AlipayPaymentService());
// 或
const processor = new OrderProcessor(new MockPaymentService()); // 方便测试这不仅解耦，还天然支持单元测试和多环境切换。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
面向接口编程：用约定代替具体类型
JavaScript 没有 interface 关键字，但可以用文档 + 运行时校验 + 类型工具（如 TypeScript）来模拟。重点是定义“行为契约”。
例如，所有支付服务都应有 charge(amount, options) 方法：
// 文档注明：任何 PaymentService 实现必须提供 charge 方法
class WechatPaymentService {
charge(amount, options) { /* ... */ }
}
<p>class FakePaymentService {
charge(amount, options) { return Promise.resolve({ success: true }); }
}</p><p>// OrderProcessor 不关心具体是谁，只调用 charge
this.paymentService.charge(this.orderAmount, this.orderOptions);只要符合契约，就能无缝替换——这才是低耦合的本质。
避免长继承链，优先组合
class 继承容易导致紧耦合（子类依赖父类实现细节）和脆弱基类问题。多数场景下，组合更灵活：
- 用
extends表达 “is-a” 关系（如AdminUser extends User） - 用字段持有其他实例表达 “has-a” 关系（如
this.logger = new ConsoleLogger()）
例如，给订单添加日志能力，不要继承 OrderWithLogging，而是在 Order 中注入 logger：
class Order {
constructor(logger) {
this.logger = logger || new NullLogger(); // 提供默认空实现
}
<p>place() {
this.logger.info('Order placed:', this.id);
// ...
}
}这样日志策略可随时更换，Order 类本身完全不知道日志怎么落地。
不复杂但容易忽略：class 是工具，内聚和耦合是设计结果。写的时候多问两个问题——这个方法属于这个类的“本职”吗？换掉它的一个依赖，我要改几处代码？答案越集中、越少，就越接近目标。
