解耦数组长度的关键在于避免硬编码：用命名常量替代字面量、将长度作为参数传递、封装扩容逻辑、通过多态隐藏容量差异，使系统灵活可变。
Java 数组长度本身是固定属性，但如何使用它，直接决定业务逻辑是否被“钉死”在某个具体数值上。解耦的关键不是避免用数组，而是不让业务规则依赖硬编码的长度值。
用命名常量代替字面量
把长度从代码里“提出来”，变成有语义的常量，是解耦的第一步。它让业务意图清晰，也方便统一修改。
- ❌ 错误写法：
int[] scores = new int[5];—— “5”是什么？最多几门课？几个评分维度？没人知道 - ✅ 正确写法：
private static final int MAX_SUBJECTS = 5;，然后int[] scores = new int[MAX_SUBJECTS]; - 后续需求变更为支持8门课时，只需改一处常量，所有相关逻辑（初始化、遍历、校验）自动适配
把长度作为参数传递
方法内部不自己决定容量，而是由调用方根据上下文传入。这样同一段数组操作逻辑，就能复用于不同规模的场景。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 比如一个批量处理用户数据的方法：
processUsers(User[] users, int validCount) - validCount 表示实际有效元素个数，而不是数组总长 —— 避免遍历到默认值（如 null 或 0）引发误判
- 调用方可以传入长度为100的数组，但只填了20个真实用户，方法只处理前20个
封装边界操作，隐藏扩容细节
一旦业务需要“看起来能变长”，就该把扩容逻辑收进工具类或专用容器里，而不是散落在各处调用 System.arraycopy 或 Arrays.copyOf。
- 提供类似
ArrayUtils.grow(int[] original, int minCapacity)的方法，内部统一处理复制与校验 - 业务代码只管“我要加一个元素”，不用关心“现在长度够不够”“要不要新建数组”“索引怎么算”
- 未来若换成
ArrayList或其他动态结构，只需替换工具方法实现，调用点完全不动
配合多态，让长度差异“消失”在接口后
当不同业务场景对容量要求不同时，与其在数组长度上做条件分支，不如用多态把差异隔离。
- 定义
DataBatch接口，含size()和get(int index)方法 - 小批量场景实现为固定数组包装类，大批量场景实现为分页加载的代理类
- 上层业务只依赖接口，完全感知不到底层是“长度10的数组”还是“按需拉取的流式数据”
不复杂但容易忽略：数组长度本身不可变，但围绕它的设计方式，决定了系统是僵化还是灵活。真正解耦，是从写第一个 new int[...] 开始就带着“它以后可能变”的意识。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
