高内聚低耦合是写好java类的核心标尺:类应专注单一职责、方法只做一件事、工具逻辑抽离;依赖需通过接口注入、避免硬编码和跨层调用;优先组合而非继承,按功能而非技术分包。

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










