设计 - 替代不允许的抽象静态方法答案

【问题标题】：Design - Alternative to not allowed abstract static method设计 - 替代不允许的抽象静态方法
【发布时间】：2013-03-24 21:30:31
【问题描述】：

我有一个抽象类，它包含一个静态方法来检查字符串是否适合特定类型，分别是 AbstractType 的实现。如果字符串适合某个类型，则会通过将字符串传递给构造函数来创建该类型类的对象。

不幸的是，不允许定义静态的抽象方法。谁能推荐一个替代设计？

提前致谢！

public abstract class AbstractType {

   public abstract static boolean isOfThisType(String str); // not possible

   ...

}

public class TypeA extends AbstractType {

   public static boolean isOfThisType(String str) {
   ...
   }

   ...

}

public class TypeB extends AbstractType {

   public static boolean isOfThisType(String str) {
   ...
   }

   ...

}

【问题讨论】：

标签： java inheritance static abstract

【解决方案1】：

是的，不要让它成为静态方法。如果它需要是多态的，不要让它成为静态的。

由于您的所有类都将实现静态方法，因此每个类都会影响您的抽象方法的实现。为抽象类提供默认实现并让子类对其进行遮蔽。

【讨论】：

【解决方案2】：

SPI 加载一个接口，该接口具有该方法，并且可以按需构建预期的类型。

public interface MyType { /* your actual implementation */ }

public interface MyTypeChecker
{
    boolean isType(String value);
    MyType getType(String value);
}

public class MyTypeFactory
{
    public /* static */ MyType getType(String value)
    {
        MyType loaded = null;

        for (MyTypeChecker checker : ServiceLoader.load(MyTypeChecker.class))
        {
            if (checker.isType(value))
            {
                loaded = checker.getType(value);
                break;
            }
        }

        return loaded;
    }
}

Factory 是否为static 在很大程度上无关紧要，尽管它往往更方便。取决于设计的其余部分确实决定了它的静态性质。就个人而言，我更喜欢尽可能避免使用static，因为它往往会导致代码耦合。

如果您愿意，那么您可以存储服务加载的实例以供将来重用（每次调用ServiceLoader.load 都会实例化一个新对象）。这还允许工厂通过简单地添加具有已定义 SPI 文件的新 JAR 或将新类型添加到主 JAR 中的 SPI 文件来扩展新类型。

【讨论】：