高内聚低耦合是写好Java类的核心标尺：类应专注单一职责、方法只做一件事、工具逻辑抽离；依赖需通过接口注入、避免硬编码和跨层调用；优先组合而非继承，按功能而非技术分包。
“高内聚低耦合”不是口号，是写好 Java 类最实在的标尺。它直指两个问题：一个类该管多少事？它和别的类该有多近？答案很明确——管好自己的一亩三分地，跟别人保持礼貌距离。
高内聚：一个类只专注做好一件事
内聚看的是类内部。如果一个类里既有用户注册逻辑、又有订单导出、还顺手做了日期格式化，那它就严重低内聚。这会导致修改注册流程时，一不小心把导出功能搞崩。
- 判断标准很简单：能用一句话说清这个类的职责吗？比如“封装用户基本信息与状态变更”或“解析并校验 JSON 请求体”
- 方法层面也要高内聚：每个方法只做单一动作，不混搭验证、处理、日志、发送通知
- 工具性逻辑（如字符串脱敏、时间转换）必须抽成独立工具类，别塞进业务类里
低耦合：减少类之间不必要的牵连
耦合看的是类之间。当一个类频繁 new 其他类、硬编码调用具体实现、或者方法参数里塞了七八个不同模块的对象，耦合就已经过重了。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 依赖要显式传递：通过构造函数注入接口，而不是在方法里直接 new JdbcTemplate 或 RedisTemplate
- 依赖类型要用抽象：Service 层依赖 UserRepository 接口，而不是 MySqlUserRepository 实现类
- 避免跨层调用：Controller 不该直接操作 DAO，也不该知道缓存用的是 Redis 还是 Caffeine
怎么落地？三个关键动作
光理解概念没用，得落到代码上：
立即学习“Java免费学习笔记（深入）”；
- 发现一个类有多个 if-else 分支按类型/格式/渠道做不同处理（比如 send("email") / send("sms")），说明它违反了单一职责，该拆成策略接口 + 多个实现类
- 单元测试时如果要 mock 超过 3 个协作对象，大概率是这个类承担了太多角色，需要解耦
- 包结构按功能分层（如 order、payment、notification），而不是按技术分（如 controller、service、dao），让职责边界更自然可见
多组合，少继承
继承容易悄悄拉高耦合：子类一旦 extends 父类，就绑定了它的字段、方法签名甚至部分实现。父类一动，子类可能无声崩溃。更稳妥的方式是“组合”——把所需能力作为成员变量引入，比如 NotificationService 持有一个 NotificationSender 接口实例，运行时再注入 EmailSender 或 SmsSender。
