java - Java 不应该禁止在构造函数中使用抽象方法吗？

Question

我刚刚遇到了一个微妙的陷阱。考虑接下来的两类:

/**
 * Innocent-looking example that causes trouble. See {@link B}.
 *
 */
public abstract class A  {

    abstract String someStringLeftForExtensionsToSpecify();

    public A() {
        super();
        processString(someStringLeftForExtensionsToSpecify());
    }

    void processString(String string) {
        // do complicated things with string that are shared by all extensions
        // so this could should be here.
    }
}

/**
 * Looks innocent enough, but abstract method is used in {@link A}'s constructor before
 * property is set, even though it uses property.
 */
public class B extends A {

    private int property;

    public B(int property) {
        this.property = property;
    }

    public String someStringLeftForExtensionsToSpecify() {
        if (property == 13) {
            return "Unlucky";
        }
        return "Lucky";
    }
}

看来在 OOP 中，在构造函数中使用抽象方法应该是禁忌。 Java 不应该禁止这样做吗，就像它禁止使用“this”或非静态方法作为“super”的参数一样吗？我想知道这是否是众所周知的事情。

Answer 1

It seems that using an abstract method inside a constructor should be a no-no in OOP. Shouldn't Java forbid this, in the same way it forbids the use of "this" or non-static methods as arguments to "super"? I wonder if this is a well-known thing.

和

The question is about whether Java should forbid it (this compiles fine in Eclipse)

this 作为客户端方法的参数存在问题的原因是，客户端接收到对尚未完全构造的对象的引用存在重大风险，即当它处于不一致状态和/或其不变量不完整时。编译器警告 this 处于无效状态。

但是谁说从构造函数中调用非 final方法是危险的？如果您没有将 this 传递给该方法，那么它就不会接收对处于无效状态的对象的引用。

这会危险吗？这取决于。如果对可变或安全对象的引用可以被恶意客户端拦截，那么当然可以。但这与整个应用程序设计中的安全考虑有关，而不仅仅是构造函数。

在某些情况下，构造函数甚至可能需要调用可重写的非 final方法……因为多态性在面向对象编程中并不是禁忌。

您要解决的真正问题是可访问性。工程师不得将他不希望客户端访问的任何方法(无论是最终的还是非最终的)导出到 API 中。