Java类中集合与对象属性的Getter和Setter最佳实践探讨

先来看你给出的原始实现：

public class PartGroup { 
    private Part iPart; 
    private ArrayList<Part> iParttList; 

    public Part getPart() { return iPart; } 
    public void setPart( Part aPart ) { iPart = aPart; } 

    public ArrayList<Part> getParttList() { return iParttList; } 
    public void setParttList( ArrayList<Part> aParttList ) { iParttList = aParttList; } 
}

你的疑问很关键——要不要保留Setter，换成延迟初始化的Getter是否更合理？我们来拆解分析两种实现的问题，以及对应的最佳实践：

一、集合（iParttList）的设计问题 #

1. 原始Setter的风险 #

保留setParttList的最大问题是：外部调用方可以直接替换整个集合实例，完全绕过PartGroup对内部集合的任何约束。比如如果你的业务要求集合里不能有null元素，或者集合修改需要触发日志、状态更新等逻辑，外部直接传一个新集合进来，PartGroup根本无法控制这类操作。

2. 「仅保留Getter+延迟初始化」的问题 #

这种方式解决了集合为null的问题，但又引入了封装漏洞：直接返回集合引用意味着外部调用方可以随意增删、清空集合内容，PartGroup完全失去了对内部状态的控制权。比如外部调用getParttList().clear()，你的PartGroup内部集合就被清空了，但类本身一无所知——这违反了面向对象的封装原则。

3. 集合的最佳实践 #

根据业务需求，推荐两种方案：

• 方案A：完全封装集合，提供专属操作方法
  移除setParttList，不直接返回集合引用，而是返回不可变视图，再提供addPart、removePart这类方法控制集合修改：

  private List<Part> iPartList; // 用List接口而非具体实现类，提升灵活性
  
  public PartGroup() {
      // 提前初始化，避免延迟初始化的线程安全问题（单线程场景可改用延迟初始化）
      this.iPartList = new ArrayList<>();
  }
  
  public List<Part> getPartList() {
      // 返回不可变视图，外部只能读，不能直接修改
      return Collections.unmodifiableList(iPartList);
  }
  
  public void addPart(Part part) {
      // 添加合法性校验，比如不允许null
      if (part == null) {
          throw new IllegalArgumentException("Part cannot be null");
      }
      iPartList.add(part);
      // 可在此添加额外逻辑，比如触发事件、记录日志
  }
  
  public void removePart(Part part) {
      iPartList.remove(part);
  }
  

  这种方式让PartGroup完全掌控集合的生命周期和修改逻辑，安全性最高。

• 方案B：允许外部修改集合，但保留基础控制
  如果你确实需要外部直接操作集合，又不想完全失控，可以在Getter中返回集合副本：

  public List<Part> getPartList() {
      if (iPartList == null) {
          iPartList = new ArrayList<>();
      }
      // 返回副本，外部修改不会影响内部状态
      return new ArrayList<>(iPartList);
  }
  

  注意这种方式有性能开销，且外部修改后需调用Setter同步回去（如果需要），适合简单场景。

二、单个Part（iPart）的设计问题 #

1. 原始Setter的风险 #

如果Part是可变类（比如有Setter方法），即使保留Setter，外部调用getPart()后也能直接修改Part的内部状态，同样破坏封装。如果Part是不可变类，Setter的风险会小很多。

2. 延迟初始化Getter的问题 #

同样，如果Part是可变的，返回引用会让外部随意修改内部状态。延迟初始化本身没问题，但要考虑线程安全——多线程环境下可能出现多个线程同时创建Part实例的情况。

3. 单个Part的最佳实践 #

• 如果允许外部替换Part：保留Setter，但一定要加校验（比如不允许传入null）；若Part是可变类，考虑返回副本或把Part设计成不可变类。
• 如果不允许外部替换Part：移除Setter，只保留Getter，同样处理可变对象的引用问题。
• 延迟初始化：适合创建成本高的对象；若创建成本低，直接在构造函数初始化更简单、安全。

改进示例：

private Part iPart;

public Part getPart() {
    // 线程安全的延迟初始化（双重检查锁定）
    if (iPart == null) {
        synchronized (this) {
            if (iPart == null) {
                iPart = new Part();
            }
        }
    }
    // 若Part是可变类，返回副本：return new Part(iPart); 假设Part有拷贝构造函数
    return iPart;
}

public void setPart(Part aPart) {
    if (aPart == null) {
        throw new IllegalArgumentException("Part cannot be null");
    }
    this.iPart = aPart;
}

三、总结 #

• 要不要保留Setter？ 取决于业务需求：如果需要外部替换整个对象/集合，且能接受这种外部控制，就保留Setter（务必加合法性校验）；如果希望PartGroup完全掌控内部状态，就移除Setter，提供专门的操作方法。
• 永远不要直接返回可变对象/集合的引用：这是封装的大忌，要么返回不可变视图，要么返回副本，要么提供专属修改方法。
• 延迟初始化：适合创建成本高的对象，否则直接在构造函数初始化更简单、安全。

内容的提问来源于stack exchange，提问作者JanithOCoder