【问题标题】:How can I restrict arguments of methods in abstract classes for subclasses that use them?对于使用它们的子类,如何限制抽象类中方法的参数?
【发布时间】:2017-01-04 02:47:01
【问题描述】:

我一直在尝试设计一组类来模拟经典 RPG。然而,我发现自己对如何解决这个问题感到困惑:如何在抽象类中强制使用角色类型(例如坦克、治疗师、DPS)特定的法术/设备等。下面的例子更好地表达了我的意思。

我有一个抽象的 PlayableCharacter 类,所有字符类型都继承自:

public abstract class PlayableCharacter {
    private Set<Spell> mSpells;

    ...

    public void addSpell(Spell spell) { 
        mSpells.add(spell);
    }
}

例如:

public class Healer extends PlayableCharacter {  ...  }
public class Tank extends PlayableCharacter {  ...  }

注意抽象类中Spell 的Set。我希望PlayableCharacter 的每个子类都可以使用它的addSpell 方法但限制Spell 的类型对应于PlayableCharacter 子类型。 例如我有这些Spell 类:

public abstract class Spell {  ...  }
public class HealerSpell extends Spell {  ...  }
public class TankSpell extends Spell {  ...  }

我只希望Healers使用HealerSpells和Tanks使用TankSpells等例如:

PlayableCharacter tank = new Tank();
tank.addSpell(new TankSpell());    // This is fine
tank.addSpell(new HealerSpell());  // I want to prevent this!

我想为PlayableCharacter 的每个子类赋予它自己的Set 和特定于子类的Spells,但这会产生很多代码重复。

我还尝试将PlayableCharacter.addSpell 标记为受保护,然后每个子类都必须实现这样的接口:

public interface Spellable<T extends Spell> {  void addClassSpell(T spell);  }

实现它的每个子类都会调用super.addSpell(spell);,但这会导致更多的代码重复,并且没有什么会迫使这些实现调用super。

我的策略在某些方面存在根本缺陷吗?有什么建议吗?随着我添加更多特定于角色类型的装备、特性等,我觉得这个问题会越来越严重。

【问题讨论】:

    标签: java oop inheritance polymorphism


    【解决方案1】:

    我不会那样做(通过类型继承)。最好为法术本身添加特性,因为它是一个法术,只能由某个角色施放。此外,特定法术只能对特定角色类型施放。这些规则属于一个法术,而不是一个角色。

    拼写规则可以在运行时通过单独的类或cast() 方法或其他方法中的拼写类本身进行检查。

    【讨论】:

      【解决方案2】:

      到目前为止,你所拥有的一切都很好

      其余的东西,多想策略模式而不是超级调用

      因此抽象类可以具有执行 step1、step2、step3 和可能的父实现的算法

      子类可以覆盖它,但只能覆盖不同的部分

      当你调用算法时,它会执行所有步骤

      如果一切都变得太大,步骤本身可能是具有逻辑的不同类

      【讨论】:

        【解决方案3】:

        也许让每个可玩角色的子类存储允许的子法术的类(或类)。然后做一个 if(spell instance of allowedSpell) ...

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2020-02-28
          • 2022-12-17
          • 2015-12-26
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多