Прототип и ценный прототип против просто ценный прототип - PullRequest
Новая
       19

Прототип и ценный прототип против просто ценный прототип

1 голос
/ 14 апреля 2019

Это сложно объяснить.В процессе создания я создаю фреймворк / библиотеку, которая может взять Java-объект (в идеале - bean-компонент) и превратить его в GUI (различные классы адаптера превращают абстрактный объект UI в GUI для конкретной платформы), где игроки могутпросматривать и редактировать информацию.Это может звучать как дыра в безопасности, но проект, над которым я работаю, требует большого количества пользовательских настроек, и это идеально подходит для этого.Я решил пойти по этому пути довольно просто:

  1. Сканирование полей данного класса и итерация по
  2. Если с полем связаны связанный метод получения и / или установки, переноситев объект «Свойства», иначе оставьте поле таким, как оно есть
  3. Создайте «ClassStructure» из свойств, которые по сути являются прототипом JavaScript, но без конструкторов и других вещей.
  4. Использованиеэта структура для создания графического интерфейса с классом GUIAdapter. Однако затем он должен использовать эти свойства, чтобы получить их возвращаемые значения от данного объекта.

Хотя я не совсем уверен, как с этим справиться.Я дал себе 2 варианта:

  1. Отредактируйте интерфейс Properties, чтобы иметь метод getValue (), и требуется, чтобы объект передавался при создании ClassStructure.Это означает, что ClassStructure больше не является прототипом, а просто представляет собой методы получения картографических отображений для их возвращаемых значений.Это немного медленнее, так как вам придется заново создать ClassStructure для каждого объекта, для которого вы хотите создать меню.Однако, это уменьшает количество раздувания и означает, что мне не нужно создавать какие-либо другие классы для получения значений.

  2. Заставьте метод getValue () получить объект для получения значений.from и создайте своего рода класс ValuedClassStructure, который содержит все методы и поля И их соответствующие значения.Затем мне пришлось бы создать фабрику ValuedClassStructure, которая принимает ClassStructure и объект, сканирует все свойства, сопоставляет их со значениями объекта.Это ДОЛЖНО быть быстрее, так как ClassStructures кэшируется, поэтому генерировать ValuedClassStructures, скажем, для 30 String Objects, было бы так же просто, как вызывать каждый из методов получения.Тем не менее, это делает проект гораздо более раздутым (если судить по опыту, я ранее использовал этот подход, он стал очень похож на спагетти, и поэтому я переписываю), с большим количеством интерфейсов, реализаций и фабрик.

Объяснять довольно сложно, и, возможно, еще более сложно объяснить, поэтому я попытаюсь сделать это в примере с псевдокодом

Это вариант 1. Класс-структуры-Instance, а не для каждого класса, то есть они генерируются медленнее, потому что у нас не может быть много кэширования, но меньше классов и зависимостей друг от друга. 

interface ClassSearcher {
        ClassStructure ofClass(Class clazz, Object holderObject);
    }

    interface ClassStructure {
        Object getHolderObject();
        Set<Property> getProperties();
    }

    interface Property<V> {
        V getValue();
    }

Это вариант 2. ClassStructuresдля каждого класса ValuedStructures для каждого экземпляра.Чтобы сопоставить получатели со значениями, мы сначала создаем прототип ClassStructure, а затем создаем ValuedStructure из этого прототипа. 

interface ClassSearcher {
    ClassStructure ofClass(Class clazz);
    ValuedStructure getValues(ClassStructure structure, Object holder);
}

interface ClassStructure {
    Set<Property> getProperties();
}

interface Property<V> {
    V getValue(Object o);
}

interface ValuedStructure {
    Object getHolderObject();
    Set<ValuedProperty> getProperties();
}

interface ValuedProperty<V> {
    V getValue();
}

В настоящее время я склоняюсь к варианту 2, просто потому, что он быстрее и с осторожностьюмысль при написании означает, что он не станет слишком похож на спагетти.Тем не менее, мне интересно услышать, что говорят все остальные.Может быть вариант 3, который я полностью упустил из виду, и для этого потребовалась еще одна перспектива.Если кто-то хочет попытаться понять общую картину, все, что у меня сейчас есть, находится в https://github.com/knightzmc/jui Первоначальный проект - jui-core, переписанный - jui-core-new (будет переименован по окончании).

TL; DR: преобразование Java-бинов в GUI.должен создать подобный JavaScript прототип и затем отобразить возвращаемые значения получателя отдельно, или все сопоставления должны быть выполнены в одном классе?

Спасибо за помощь.

...