Поведение, специфичное для типа Java, с обобщениями - PullRequest
Новая
       28

Поведение, специфичное для типа Java, с обобщениями

4 голосов
/ 07 марта 2019

Проблема заключается в следующем:

Существуют сущности Box, Boxvalue, Boxstrategy, а затем в качестве примера "IntegerBoxStrategy". Концепция довольно проста, я бы хотел добавить в этот блок разные типы. Иногда в этом боксе будет целое число, иногда строка. Я хочу иметь возможность выполнять конкретное преобразование между этими типами (таким образом, специфичное для типа поведение -> отсюда и мой подход к стратегии. Для каждого типа потребуется конкретная стратегия преобразования), и эти типы можно указывать с помощью ENUM.

Так что после того, как много гуглил (хотя я вполне уверен, что этот вопрос может быть помечен как дубликат, и скажу, что я не достаточно гуглил;)) я пробую такой подход: https://www.javaspecialists.eu/archive/Issue123.html

Краткое изложение этого подхода: они используют стратегию для реализации налоговой стратегии для налогоплательщиков. UML будет легче понять: UML class diagram for first link Хотя в моем случае у меня был бы только один «налогоплательщик», он же BoxType.

fyi: этот вопрос действительно похож: Условное поведение, основанное на конкретном типе для универсального класса , хотя -> я хочу иметь возможность переключаться между своими BoxValues ​​и преобразовывать «true» в «1». Но я думаю, что подход ответа может быть полезным, идентификация типа во время выполнения. Который в моем случае будет использоваться для сопоставления стратегий с их соответствующими «поддерживаемыми типами».

Проблема с первой ссылкой заключается в том, что в каждой конкретной реализации стратегии у меня будет огромный переход. (образец кода позже)

Мой вопрос не является чем-то вроде «решите это для меня, пожалуйста», а скорее как указание мне в общем направлении. Если бы можно было привести простой пример того, как это можно сделать, когда вам не нужно обновлять каждую конкретную реализацию стратегии, когда вы поддерживаете новый «boxvaluetype», я был бы очень рад. Если возможно, я бы хотел, чтобы реализация или подход были максимально чистыми в соответствии с принципами GRASP. 

 public interface typeStrategy {
    boolean canChangeToType(Object myvalue,ValueType type);
    boolean correctType(Object myvalue);
}

class BoolTypeStrategy implements typeStrategy{

    @Override
    public boolean canChangeToType(Object myvalue, ValueType type) {
        if (correctType(myvalue))
            throw new IllegalArgumentException("your initial value should be a boolean!");
        switch (type){
            case INT:
                return true;
            case STRING:
                return true;
            default:
                return false;
        }
    }

    @Override
    public boolean correctType(Object myvalue) {
        if (!(myvalue instanceof Boolean))
            return false;
        return true;
    }
}

В этом примере этот ValueType - мой Enum. 

public class BoxValue<T> {
    private T value;
    private typeStrategy mystrategy;


    public BoxValue(T value, typeStrategy strategy) {
        this.value = value;
        this.mystrategy = strategy;
    }

    public T getValue() {
        return value;
    }

    public boolean canChangeToType(ValueType type){
        return mystrategy.canChangeToType(value, type);
    }
}

Как видите, огромные коммутаторы решают проблему. Так какие шаблоны проектирования, какие предложения рекомендуются для решения этой проблемы? (к вашему сведению: я бы хотел решить эту проблему в Java 8, так как я знаю, что в Java10 + есть эти странные типы "var")

...