0

我正在尝试使用存储过程构建键值存储，并且发现枚举在定义事物时非常方便。我希望数据库成为表的枚举，并且表与操作枚举和区域枚举相关联。问题是枚举不能扩展抽象类，所以我必须使用接口。所以我有很多枚举，每个枚举都必须实现相同的代码（定义相同的字段，编写相同的构造函数来填充这些字段，并覆盖使用这些字段的 getter 和方法）。这是此类枚举的示例：

interface Operation<VAL, PARAM>
{
    int code();
    Serdes<PARAM> pSerdes();
    VAL apply(VAL val, byte[] pbytes);
}

...

// Job, Param, & Ticket are protobuf classes
public enum JobOp implements Operation<Job, Param>
{
    AddTicket(0, (job, param) -> ...),
    RemoveTicket(1, (job, param) -> ...),
    CompleteTicket(2, (job, param) -> ...);

    private final int code;
    private final Serdes<Param> pSerdes = new ProtoSerdes<>(Param.PARSER);
    private final BiFunction<Job, Param, Job> proc;
    JobOp(int code, BiFunction<Job, Param, Job> proc)
    {
        this.code = code
        this.proc = proc
    }

    @Override
    public int code() { return code; }
    @Override
    public Serdes<Param> pSerdes() { return pSerdes; }
    @Override
    public Job apply(Job val, byte[] pbytes)
    {
        final Param param = pSerdes.fromBytes(pbytes);
        return proc.apply(val, param);
    }
}

我想避免所有重复的样板文件并尽可能尊重 DRY，所以我开始使用内部类来表示字段：

interface Operation<VAL, PARAM>
{
    default int code() { return imp().code; }
    default Serdes<PARAM> pSerdes() { return imp().pSerdes; }
    default VAL apply(VAL val, byte[] pbytes) { return imp().apply(val, pbytes); }
    // Reduce the number of fields and getters to implement to one: imp
    Imp<VAL, PARAM> imp();

    class Imp<VAL, PARAM>
    {
        public final int code;
        public final Serdes<PARAM> pSerdes;
        private final BiFunction<V, P, V> proc;

        Imp(int code, Serdes<PARAM> pSerdes, BiFunction<V, P, V> proc)
        {
            this.code = code;
            this.pSerdes = pSerdes;
            this.proc = proc;
        }

        VAL apply(VAL val, byte[] pbytes)
        {
            PARAM param = pSerdes.fromBytes(pbytes);
            return proc.apply(val, param);
        }
    }
}

...

// Job, Param, & Ticket are protobuf classes
public enum JobOp implements Operation<Job, Param>
{
    AddTicket(0, (job, param) -> ...),
    RemoveTicket(1, (job, param) -> ...),
    CompleteTicket(2, (job, param) -> ...);

    private final Serdes<Param> pSerdes = new ProtoSerdes<(Param.PARSER);
    private final Operation.Imp<Job, Param> imp;
    JobOp(int code, BiFunction<Job, Param, Job> proc)
    {
        imp = new Imp(code, pSerdes, proc);
    }

    @Override
    public Imp<Job, Param> imp() { return imp; }
}

这有助于减少样板文件，但我对 Java 还很陌生，担心这可能是一种反模式。它还公开了一个我不想成为接口一部分的变量，并添加了可能会损害性能的额外级别的函数调用。我想到的一种保持公共接口清洁的解决方案是将字段对象保持在静态 WeakHashMap 中，并在接口实例上键入：

interface Operation<VAL, PARAM>
{
    default int code() { return imp(this).code; }
    default Serdes<PARAM> pSerdes() { return imp(this).pSerdes; }
    default VAL apply(VAL val, byte[] pbytes) { return imp(this).apply(val, pbytes); }
    final Map<Operation, Imp> imps = new WeakHashMap<>();
    @SuppressWarnings("unchecked")
    static <V, P> Imp<V, P> imp(Operation<V, P> op) { return imps.get(op); }
    static <V, P> void bind(Operation<V, P> op, Imp<V, P> imp) { imps.put(op, imp); }

    class Imp<VAL, PARAM>
    {
        public final int code;
        public final Serdes<PARAM> pSerdes;
        private final BiFunction<V, P, V> proc;

        Imp(int code, Serdes<PARAM> pSerdes, BiFunction<V, P, V> proc)
        {
            this.code = code;
            this.pSerdes = pSerdes;
            this.proc = proc;
        }

        VAL apply(VAL val, byte[] pbytes)
        {
            PARAM param = pSerdes.fromBytes(pbytes);
            return proc.apply(val, param);
        }
    }
}

...

// Job, Param, & Ticket are protobuf classes
public enum JobOp implements Operation<Job, Param>
{
    AddTicket(0, (job, param) -> ...),
    RemoveTicket(1, (job, param) -> ...),
    CompleteTicket(2, (job, param) -> ...);

    private final Serdes<Param> pSerdes = new ProtoSerdes<(Param.PARSER);
    JobOp(int code, BiFunction<Job, Param, Job> proc)
    {
        Operation.bind(this, new Imp(code, pSerdes, proc));
    }
}

这个想法的灵感来自 Python 的属性，但它存在一些问题：

1）它并没有完全摆脱公共接口的污染，它只是稍微混淆了它。

2) 它可能会导致更大的性能损失。

3) 它隐式地要求实现者在构造函数中绑定一个 Fields 对象。

有没有更好的方法来做到这一点？上述两种解决方案是否比我指出的问题更严重（性能下降和代码不干净）？我试图遵守得墨忒耳法则，但这感觉可能会在以后引起一些耦合问题。

编辑：在适当的地方添加了“最终”

编辑 2：增加了对开头段落的说明并稍微清理了示例

4

2 回答 2

1

为此使用父类有什么问题？而不是接口操作，有：

public abstract class Operation<VAL, PARAM> {
    private int code;

    public int getCode() { return code; }
    public abstract void example();
}

...并从那里拿走它。

与接口不同，类可以有状态。在上面的示例中，getCode将使用声明的实现，但您可以根据需要覆盖它（您可以添加final关键字来停止它），并且该方法example 必须由子类实现。它类似于接口中的普通void example();（在接口中，默认情况下所有方法声明都是公共和抽象的，在类中您必须添加这些关键字）。

如果它不能是超类，这不是一个好主意；一般的概念是接口真的不应该有状态。如果您坚持使用有状态接口，那么您或多或少地致力于肮脏的黑客攻击。

于 2018-09-26T00:46:41.707 回答
0

你是在设计一个什么都知道，什么都能执行的神级吗？
访问者模式可以将任务分成多个部分并组装它们以执行。

于 2018-09-26T07:12:54.903 回答