构造函数中的可重写方法调用有什么问题？

Question

我有一个 Wicket 页面类，它根据抽象方法的结果设置页面标题。

public abstract class BasicPage extends WebPage {

    public BasicPage() {
        add(new Label("title", getTitle()));
    }

    protected abstract String getTitle();

}

NetBeans 警告我消息“构造函数中可重写方法调用”，但它应该有什么问题呢？我能想到的唯一选择是将抽象方法的结果传递给子类中的超级构造函数。但如果有很多参数，这可能很难阅读。

Answer 1

关于从构造函数调用可重写方法

简单地说，这是错误的，因为它不必要地为许多错误带来了可能性。当调用@Override时，对象的状态可能不一致和/或不完整。

引用Effective Java 2nd Edition，第 17 条：继承的设计和文档，否则禁止：

类必须遵守一些限制才能允许继承。 构造函数不得直接或间接调用可重写的方法。如果违反此规则，将会导致程序失败。超类构造函数在子类构造函数之前运行，因此子类中的重写方法将在子类构造函数运行之前被调用。如果重写方法依赖于子类构造函数执行的任何初始化，则该方法将不会按预期运行。

下面举个例子来说明：

public class ConstructorCallsOverride {
    public static void main(String[] args) {

        abstract class Base {
            Base() {
                overrideMe();
            }
            abstract void overrideMe(); 
        }

        class Child extends Base {

            final int x;

            Child(int x) {
                this.x = x;
            }

            @Override
            void overrideMe() {
                System.out.println(x);
            }
        }
        new Child(42); // prints "0"
    }
}

这里，当Base构造函数调用overrideMe时，Child还没有完成对final int x的初始化>，并且该方法得到错误的值。这几乎肯定会导致错误和错误。

相关问题

• 从父类构造函数调用重写方法
• 派生类对象的状态基类构造函数调用 Java 中的重写方法
• 使用抽象 init( ) 抽象类的构造函数中的函数

另请参阅

• FindBugs - 从构造函数调用的字段方法的未初始化读取superclass

---

关于具有许多参数的对象构造

具有许多参数的构造函数可能会导致可读性较差，并且存在更好的替代方案。

下面引用了《Effective Java 第二版》第 2 条：面对许多构造函数参数时考虑构建器模式：

传统上，程序员使用伸缩构造函数模式，在该模式中，您提供一个仅具有必需参数的构造函数，另一个具有单个可选参数，第三个具有两个可选参数，依此类推。 ..

......伸缩构造函数模式本质上是这样的：

public class Telescope {
    final String name;
    final int levels;
    final boolean isAdjustable;

    public Telescope(String name) {
        this(name, 5);
    }
    public Telescope(String name, int levels) {
        this(name, levels, false);
    }
    public Telescope(String name, int levels, boolean isAdjustable) {       
        this.name = name;
        this.levels = levels;
        this.isAdjustable = isAdjustable;
    }
}

现在您可以执行以下任何操作：

new Telescope("X/1999");
new Telescope("X/1999", 13);
new Telescope("X/1999", 13, true);

但是，当前您不能仅设置 name 和 isAdjustable，然后离开默认的级别。您可以提供更多的构造函数重载，但显然，随着参数数量的增加，数量会爆炸，您甚至可能有多个 boolean 和 int 参数，这确实会导致把事情搞乱。

正如您所看到的，这不是一个写起来令人愉快的模式，使用起来更不愉快（“true”在这里意味着什么？13 是什么？）。

Bloch 建议使用构建器模式，它允许您编写如下所示的内容：

Telescope telly = new Telescope.Builder("X/1999").setAdjustable(true).build();

请注意，现在参数已命名，您可以按照您想要的任何顺序设置它们，并且可以跳过要保留默认值的参数价值观。这肯定比伸缩构造函数好得多，特别是当存在大量属于许多相同类型的参数时。

另请参阅

• Wikipedia/Builder 模式
• Effective Java 第二版，第 2 项：考虑构建器模式当面对很多构造函数参数时（网上摘录）

相关问题

• < a href="https://stackoverflow.com/questions/328496/when-would-you-use-the-builder-pattern">什么时候会使用构建器模式？
• 这是一个众所周知的设计模式吗？它的名字是什么？

Answer 2

下面是一个有助于理解这一点的示例：

public class Main {
    static abstract class A {
        abstract void foo();
        A() {
            System.out.println("Constructing A");
            foo();
        }
    }

    static class C extends A {
        C() { 
            System.out.println("Constructing C");
        }
        void foo() { 
            System.out.println("Using C"); 
        }
    }

    public static void main(String[] args) {
        C c = new C(); 
    }
}

如果运行此代码，您将得到以下输出：

Constructing A
Using C
Constructing C

看到了吗？ foo() 在 C 的构造函数运行之前使用 C。如果foo()要求C具有已定义的状态（即构造函数已完成），那么它将在C中遇到未定义的状态，并且事情可能会中断。由于您无法知道 A 中被覆盖的 foo() 期望什么，因此您会收到警告。

Answer 3

在构造函数中调用可重写的方法允许子类破坏代码，因此您不能保证它不再有效。这就是您收到警告的原因。

在您的示例中，如果子类重写 getTitle() 并返回 null 会发生什么？

要“修复”此问题，您可以使用 工厂方法 而不是构造函数，这是一种常见模式对象实例化。

Answer 4

下面的示例揭示了在超级构造函数中调用可重写方法时可能发生的逻辑问题。

class A {

    protected int minWeeklySalary;
    protected int maxWeeklySalary;

    protected static final int MIN = 1000;
    protected static final int MAX = 2000;

    public A() {
        setSalaryRange();
    }

    protected void setSalaryRange() {
        throw new RuntimeException("not implemented");
    }

    public void pr() {
        System.out.println("minWeeklySalary: " + minWeeklySalary);
        System.out.println("maxWeeklySalary: " + maxWeeklySalary);
    }
}

class B extends A {

    private int factor = 1;

    public B(int _factor) {
        this.factor = _factor;
    }

    @Override
    protected void setSalaryRange() {
        this.minWeeklySalary = MIN * this.factor;
        this.maxWeeklySalary = MAX * this.factor;
    }
}

public static void main(String[] args) {
    B b = new B(2);
    b.pr();
}

结果实际上是：

minWeeklySalary: 0

maxWeeklySalary: 0

这是因为类 B 的构造函数首先调用类 A 的构造函数，其中执行 B 中的可重写方法。但是在方法内部我们使用了实例变量factor，它尚未初始化（因为A的构造函数尚未完成），因此factor是0而不是1并且绝对不是 2（程序员可能认为会是这样）。想象一下，如果计算逻辑扭曲十倍，那么追踪错误会有多困难。

我希望这会对某人有所帮助。

Answer 5

如果您在构造函数中调用子类重写的方法，则意味着如果您在构造函数和方法之间逻辑划分初始化，则不太可能引用尚不存在的变量。

查看此示例链接 http://www.javapractices.com/topic /TopicAction.do?Id=215

Answer 6

我当然同意在某些情况下最好不要从构造函数中调用某些方法。

让它们私有消除了所有疑虑：“你不能通过” 。

但是，如果您确实想让事情保持开放怎么办？

正如我试图解释的那样，不仅仅是访问修饰符才是真正的问题此处。说实话，private 是一个明显的阻碍，而 protected 通常仍然会允许（有害的）解决方法。

更一般的建议：

• 不要从构造函数启动线程
• 不要从构造函数读取文件
• 不要从构造函数调用 API 或服务 不要
• 从构造函数加载数据库中的数据 不要
• 解析 json 或 xml 文档从你的构造函数

不要直接从你的构造函数中这样做。这包括从构造函数调用的私有/受保护函数执行任何这些操作。

从构造函数中调用 start() 方法肯定是一个危险信号。

相反，您应该提供 public init()、start() 或 connect() 方法。并将责任留给消费者。

简单地说，您想要将“准备”时刻与“点火”时刻分开。

• 如果构造函数可以扩展，那么它就不会自燃。
• 如果它自燃，那么它就有在完全建造之前被发射的风险。
• 毕竟，有一天可以在子类的构造函数中添加更多准备工作。并且您无法控制超类构造函数的执行顺序。

PS：考虑实现 Closeable 与之相关的接口。

Answer 7

在Wicket的具体情况下：这就是我问Wicket的原因
开发人员在构建组件的框架生命周期中添加对显式两阶段组件初始化过程的支持，即

1. 构建 - 通过构造函数
2. 初始化 - 通过 onInitilize（在虚拟方法工作时构建之后！）

对于是否有必要或是否有必要进行了相当激烈的争论不是（恕我直言，这完全是必要的），因为此链接演示了 http://apache-wicket.1842946.n4.nabble.com/VOTE-WICKET-3218-Component-onInitialize-is-broken-for-Pages-td3341090i20.html< /a>)

好消息是，Wicket 的优秀开发人员最终引入了两阶段初始化（以使最棒的 Java UI 框架变得更加棒！），因此使用 Wicket，您可以在 onInitialize 方法中完成所有构建后初始化如果您覆盖它，框架会自动调用它 - 此时在组件生命周期中，其构造函数已完成其工作，因此虚拟方法按预期工作。

Answer 8

我想对于 Wicket 来说，最好在 onInitialize() 中调用 add 方法（参见 组件生命周期) :

public abstract class BasicPage extends WebPage {

    public BasicPage() {
    }

    @Override
    public void onInitialize() {
        add(new Label("title", getTitle()));
    }

    protected abstract String getTitle();
}

Answer 9

可重写的方法应包含在构造函数上调用它们的文档。继承者应该考虑到这一点，并且只使用重写来更改超类上分配的值的验证，并且始终调用超类方法来更改实际值（如果它是setter）。

我确实在构造函数上使用了很多可重写的方法，并且没有导致程序失败。这是因为我确实遵循这个原则 - 覆盖仅允许检查值，或者可能用子类上不同的合适值替换它。通常，重写的方法是不使用子类的内部状态的值检查器，但允许更改允许的值。