避免抽象静态方法(或覆盖静态方法)的设计模式

Bai*_*ker 5 java oop static-methods design-patterns abstract

我知道静态方法不能被抽象,也不能被覆盖,只能被隐藏(在这种情况下,后期绑定不会发生).关于这一点,我正在努力用一种合乎逻辑的方式来表达以下关系:

public abstract class Spell {
    protected int power;

    public Spell(int power) {
        this.power = power;
    }

    public int getPower() { return power; }

    // I know this is impossible, but please bare with me
    public abstract static int getMaxPower();
}

public class AttackSpell extends Spell {
    public AttackSpell(int power) {
        super(power);
    }

    public static int getMaxPower() { return 50; }
}

public class HealSpell extends Spell {
    public HealSpell(int power) {
        super(power);
    }

    public static int getMaxPower() { return 30; }
}
Run Code Online (Sandbox Code Playgroud)

在这个人为的例子中,最大功率是我希望每个法术都知道的属性(并且每个子类Spell都有一个适用于其自身所有实例的单独最大功率).在其他SO线程中,针对这种不可能情况的建议解决方案是制作getMaxPower()实例方法.但是,我不认为这是有道理的,因为幂是实例细节,在实例化之前知道是有用的(例如,构造一个从幂1到该法术最大幂的法术实例数组).

我看到的一个解决方案是为每个法术创建一个工厂(或者对所有法术都更通用),它有一个实例方法getMaxPower(),它知道它实例化的法术的最大力量属性.但是,这对我来说似乎也不是最佳的,因为:

  1. 知道自己的属性对每个法术更有意义
  2. 这使得Spell的子类无视实现细节(即,它的构造函数无法检查提供的功率是否超过其最大功率)

工厂模式是正确的方法吗?如果是这样,它的逻辑理由是什么?如果没有,是否有更适合这个问题的模式?

Ton*_*son 3

我的第一个想法是断开生成法术与法术的连接。

有一个类描述具有功率范围的法术系列,然后使用它来创建该范围内的法术集合,通过构造函数传递功率等。

然后,您可以考虑某种类型的数据文件,从而节省大量的硬编码。