简体   繁体   English

在构造函数中使用重写方法的替代方法,Java

[英]Alternatives to using overridden methods in constructors, Java

In a Java project I am coding I have ended up using methods that are overridden in constructors. 在我编写的Java项目中,我最终使用了在构造函数中重写的方法。 Something like: 就像是:

class SuperClass {
    SuperClass() {
        intialise();
    }

    protected void initialise() {
        //Do some stuff common to all subclasses
        methodA();
        methodB();
    }

    protected abstract void methodA();

    protected abstract void methodB();
}

class SubClass1() {
    SubClass() {
        super();
    }
    protected void methodA() { //Do something }
    protected void methodB() { //Do something }

}

class SubClass2() {
    SubClass() {
        super();
    }
    protected void methodA() { //Do something else }
    protected void methodB() { //Do something else}

}

I now realise, that although in my case it works fine, it is somewhat dangerous since SubClass methods are called on an object that has currently only been constructed as a SuperClass object (something that may be overlooked when new classes that extend SuperClass are added in the future). 我现在意识到,虽然在我的情况下它工作正常,但是有点危险,因为SubClass方法在一个目前只被构造为SuperClass对象的对象上调用(当扩展SuperClass的新类被添加时,可能会忽略这一点)未来)。 It also wouldn't work in c++ due to differences in how objects are created. 由于对象的创建方式不同,它在c ++中也不起作用。

The only way I can think to get round this is to move the initialise method call down to the concrete classes constructor: 我能想到的唯一方法就是将initialise方法调用向下移动到具体的类构造函数:

   class SuperClass {
    SuperClass() {            
    }

    protected void initialise() {
        methodA();
        methodB();
    }

    protected abstract void methodA();

    protected abstract void methodB();
}

class SubClass1() {
    SubClass() {
        super();
        initialise();
    }
    protected void methodA() { //Do something }
    protected void methodB() { //Do something }

}...

Is this the common way to over come this issue? 这是解决这个问题的常用方法吗? It seems a shame (and easy to forget) that all further classes that extend SuperClass need to remember to call initialise(). 扩展SuperClass的所有其他类需要记住调用initialise()似乎是一种耻辱(并且容易忘记)。

I also found myself doing something similar in a more complicated situational that uses a Factory Method in a constructor, which is overridden in subclasses to decide which concrete class to implement. 我还发现自己在更复杂的情境中做了类似的事情,它在构造函数中使用了Factory方法,在子类中重写它以决定实现哪个具体类。 The only other way I can think to get round this and keep the design pattern as is, is to perhaps construct in a two phase process; 我能想到的唯一另一种方法是将这种设计模式保持原样,或许可以构建一个两阶段的过程; ie construct with the bare minimum, and then call a second method to finish off the job. 即用最小的构造,然后调用第二种方法来完成工作。

Objects that need initialization as complex as this would really need to be created through factory methods. 需要初始化的对象实际上需要通过工厂方法创建。 You do mention a factory, but being called from a constructor, so that doesn't sound like the straightforward approach, either. 你确实提到了一个工厂,但是从构造函数中调用,所以这听起来也不像是简单的方法。 If you simply had a factory in the base class, publicly invisible constructors, and a mechanism to decide which concrete class to return, that factory would easily enforce the initialization policy. 如果你只是在基类中有一个工厂,公共不可见的构造函数,以及一个决定返回哪个具体类的机制,那么工厂将很容易地执行初始化策略。

This is really not a good idea as your Subclass will not be properly constructed when its methodA() and methodB() are called. 这实际上不是一个好主意,因为当调用其methodA()和methodB()时,您的子类将无法正确构造。 That would be very confusing for people extending the class. 对于扩展课程的人来说,这将是非常混乱的。 Recommend you use an abstract init() instead, as suggested by dlev in his/her comment. 建议您使用抽象的init() ,如dlev在他/她的评论中所建议的那样。

I wonder if you're making things more complicated than they need to be. 我想知道你是否让事情变得比他们需要的更复杂。

In your example, the stuff done by each implementation of methodA could be moved to the constructor of the class that does the implementation. 在您的示例中,methodA的每个实现所完成的工作可以移动到执行该实现的类的构造函数中。 So instead of using SubClass::methodA, just move the logic into the SubClass constructor. 因此,不要使用SubClass :: methodA,只需将逻辑移动到SubClass构造函数中。

If you do this you gain clarity at the expense of some potentially hard to understand control over the order the various initialization bits get executed. 如果你这样做,你可以获得清晰,代价是可能难以理解对各种初始化位执行顺序的控制。

Bruce Eckel在他的“Thinking in Java”中提出的建议是使你的methodA()和类SuperClass的方法B()最终或私有(隐式最终),因此它们可以从超类构造函数访问,尽管没有派生类会有访问这些方法,因此,不会有任何危险的覆盖 - 任何派生类中声明的类似签名的任何方法都只是新方法。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM