Избежание шаблонов в интерфейсах Java - PullRequest
Новая
       50

Избежание шаблонов в интерфейсах Java

0 голосов
/ 26 сентября 2018

Я пытаюсь создать хранилище значений ключей с помощью хранимых процедур, и я обнаружил, что перечисления пригодятся для определения вещей.Я бы хотел, чтобы БД была перечислением таблиц, а таблица связана с перечислением операций и перечислением регионов.Проблема в том, что перечисления не могут расширять абстрактные классы, поэтому я должен использовать интерфейсы.Поэтому у меня много перечислений, и каждый из них должен реализовывать один и тот же код (определить одни и те же поля, написать один и тот же конструктор для заполнения этих полей и переопределить методы получения и методы, использующие эти поля).Вот пример такого перечисления: 

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: Добавлено пояснениенемного раскрыть абзац и привести в порядок примеры

Ответы [ 2 ]

0 голосов
/ 26 сентября 2018

Вы разрабатываете класс Бога, который знает все и способен на что угодно? Шаблон посетителя может разделить задачи на части и собрать их для выполнения.

0 голосов
/ 26 сентября 2018

Что не так с использованием родительского класса для этого?Вместо интерфейса Operation, введите: 

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

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

... и возьмите его оттуда.

В отличие от интерфейсов, классы могут иметь состояние.В приведенном выше примере getCode будет использовать указанную реализацию, но вы можете переопределить ее, если хотите (вы можете добавить final в качестве ключевого слова, чтобы остановить это), и метод example ДОЛЖЕН бытьреализуется подклассами.Это похоже на простой void example(); в интерфейсе (в интерфейсах все объявления методов по умолчанию являются публичными и абстрактными, в классах вы должны добавить эти ключевые слова).

Если это не может быть суперклассэто не очень хорошая идея;общее представление о том, что интерфейсы действительно не должны иметь состояния.Если вы настаиваете на наличии интерфейсов с отслеживанием состояния, вы более или менее привержены грязным хакерам.

...