抽象类中的保护方法使用场景探讨

先说一个核心判断：抽象类中的 protected 方法，本质上是在“可见性”上做了一次精准的取舍——既不让外部代码随意调用，又把逻辑的控制权留给子类。说白了，它就是在封装性和可扩展性之间，找到的那个恰到好处的平衡点。

那么，在实际开发中，protected 方法到底什么时候该登场？

需要子类共享基础逻辑，但禁止外部调用时

抽象类里要是有一段通用流程——比如初始化校验、日志记录、资源预加载——希望所有子类都走一遍，但又不希望被其他代码直接调用。这种场景，就是 protected 方法的天然主场。

• 举个例子：抽象类 DataSource 里有一个 protected void validateConfig()，子类在 connect() 之前统一调用它。外部代码呢？想通过 dataSource.validateConfig() 来调用？不行，编译器直接拒绝。
• 对比一下：用 public 会暴露不该暴露的 API；用 private 又直接把子类堵死。protected 刚好卡在中间，既防了外部误用，又给子类留了后门。

配合模板方法模式，构建可定制的流程

模板方法模式大家都熟：抽象类定好主流程的骨架，把其中某些步骤交给子类去实现。而那些由父类控制的“中间步骤”，最适合标记为 protected。子类想改动时，可以覆写；不想动，直接用父类的默认实现就行。

• 比如 abstract class ReportGenerator 定义了一个 final void generate() { prepare(); render(); export(); }。其中的 prepare() 和 export() 都是 protected 具体方法。子类如果需要对接不同数据源或输出格式，覆写这两个方法即可，主流程一点不受影响。
• 这样一来，主流程的稳定性保住了，子类想要干预的空间也留下了，封装边界依然清晰。

避免直接暴露属性，改用受保护方法间接访问

抽象类里头经常要维护一些关键状态——比如配置参数、缓存数据、上下文对象。很多新手喜欢直接声明成 protected String apiKey;，结果子类拿到这个字段后随意赋值，没有任何约束。这不是设计，是埋坑。

• 反例就不多说了，直接看正例：用一个 protected 的 getter 方法来做访问控制，比如 protected String getApiKey() { return this.apiKey; }。或者提供一个受保护的 setter，内部加上校验逻辑，比如 protected void setRetryCount(int count) { if (count > 0) this.retry = count; }。
• 这条路子最大的好处是：未来如果想加日志、加缓存、加校验，直接在方法内部改，外部完全感知不到。

构造逻辑需要限制实例化范围时

抽象类的构造方法设为 protected，其实已经是一个行业共识了。核心目的很简单：只有子类才能调用父类的构造器完成初始化，外部代码想直接 new 抽象类？门都没有。

• 即便你的抽象类里一个抽象方法都没有，只要构造器是 protected，它就强行告诉别人——我是一个基类，请用继承来使用我。
• 反过来，如果构造器声明成 public，虽然编译器不会报错（毕竟抽象类本身就没法实例化），但语义上非常拧巴。IDE 和静态检查工具往往会直接给出警告。