Свойство класса Java, которое может поддерживать разные типы

Question

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

В настоящее время мой класс Field является массивом String для хранения всех значений.

Мой класс выглядит следующим образом:

public class Field implements Serializable { 
    private UUID key; 
    private String name; 
    private ArrayList<String> values; 
    private Integer maxValues; 
    private ValueType type; 
    private String code; 

    public enum ValueType { 
     INT, 
     VARCHAR, 
     DATE, 
     BOOLEAN 
    } 

    public void addValue(String value){ 
     if (this.values.size() < this.maxValues){ 
      this.values.add(value); 
     } 
    } 

    public ArrayList<String> getValues(){ 
     return this.values; 
    } 
} 

Я хотел бы хранить String, Integer, поплавки и даты, я имею в виду, я мог бы ввести и проверить значения, когда они вводятся и имеют отдельные методы для получения как правильные типы.

public ArrayList<Integer> getIntegerValues(){ 

    ArrayList<Integer> integerValues = new ArrayList<Integer>(); 


    values.forEach(
     (v) -> { 

      Integer intValue = Integer.parseInt(v); 

      integerValues.add(intValue); 

     } 
    ); 

    return integerValues; 
} 

Я полагаю, что это будет работать, но он не чувствует себя как отличное решение, так как при использовании этого класса вы должны выбрать правильную функцию для получения типов. Было бы хорошо, если бы была только одна функция, чтобы вернуть правильную версию.

Есть ли у кого-нибудь идеи, как я могу написать это лучше.

Answer 1

Я не был на 100% доволен либо ответом, ни чувством, как правильный путь решения этой проблемы, в обоих направлениях были проблемы.Однако я понял, что оба ответа вместе дадут хорошее решение, поэтому благодаря обоим.

Ваш конкретный класс определит значения для общего значения. Это удовлетворяет открытому замкнутому принципу.

public interface FieldType<T> { 
    void addValue(T value); 
    ArrayList<T> getValues(); 
} 

public abstract class Field<T> implements FieldType<T>, Serializable { 
    private UUID key; 
    private String name; 
    protected ArrayList<T> values; 
    private Integer maxValues; 
    private String code; 

    public abstract void addValues(); 

    public ArrayList<T> getValues(){ 
     return this.values; 
    } 
} 

public class FloatField extends Field<Float> { 

    @Override 
    public void addValue(Float value) { 
     this.values.add(value); 
    } 

    @Override 
    public ArrayList<Float> getValues() { 
     return this.values; 
    } 
} 

Answer 2

Вот пример того, как можно использовать дженерики:

public class Field<T> implements Serializable { 
    private UUID key; 
    private String name; 
    private ArrayList<T> values; 
    private Integer maxValues; 
    private String code; 

    public void addValue(T value) { 
     if (this.values.size() < this.maxValues){ 
      this.values.add(value); 
     } 
    } 

    public ArrayList<T> getValues(){ 
     return this.values; 
    } 
} 

Answer 3

Больше как другой точки зрения: вы должны прийти к выводу, что дженерики не поможет вам здесь - вы все равно должны не используйте перечисление для таких вещей.

Проблема с перечислениями: они очень полезны для «моделей», которые имеют очень небольшой шанс на изменение в будущем. Потому что обычно происходит: для каждого перечисления, которое у вас есть, вы будете создавать переключатель; чтобы реализовать различное поведение для ваших разных констант перечисления. Это может показаться не такой проблемой, но это ... когда вы понимаете, что вам нужно добавить еще один тип. Затем вам нужно найти все эти ключи и решить, как обрабатывать новую константу enum.

Вместо этого ваша конструкция должна управляться Open/Closed principle: открыть для изменения; но закрыт для модификации. В ОО, что чаще всего проявляется в использовании абстрактных классов, как

public abstract class ValueType { 
    ... which has some ABSTRACT methods 
    ... and probably some FINAL methods 

абстрактные методы, где вы реализуете это поведение, которое должно быть различным для различных дочерних классов; и FINAL-методы - это те, которые «исправляют» это поведение, которые должны быть одинаковыми для каждого экземпляра этих классов.

И затем вы идете вперед и создаете определенные подклассы, например IntValue extends ValueType и так далее.

И почему это лучше? Очень просто: добавление нового типа ValueType означает ... создание нового подкласса - без необходимости касаться любого существующего кода. Таким образом, такой дизайн составляет open для изменения (добавление новых типов!), Но закрыт для модификации (поскольку добавление нового типа ничего не меняет в других существующих классах).