Corda State Evolution - обнуляемые свойства по умолчанию - PullRequest
Новая
       13

Corda State Evolution - обнуляемые свойства по умолчанию

0 голосов
/ 10 июля 2019

В Corda добавление новых свойств к состояниям (эволюция состояний) требует, чтобы новые свойства обнулялись, чтобы оставаться обратно совместимыми с предыдущими версиями состояния. 

data class Version1DummyState(
    override val participants: List<AbstractParty>
) : ContractState

data class Version2DummyState(
    override val participants: List<AbstractParty>,
    val myNewProperty: String? = null
) : ContractState

Поскольку Kotlin также поддерживает свойства со значениями по умолчанию, я хотел бы знать, почему эволюция состояния ограничена свойствами только значений, допускающих nullable , но не свойствами, не допускающими значения NULL, при условии, что эти свойства имеют значение по умолчанию значение? 

data class Version2DumyState(
    override val participants: List<AbstractParty>,
    val myNewProperty: String = "Hello, world."
) : ContractState

Мое обоснование для запроса этого пришло от просмотра образца неявного обновления, в котором состояние обязательства обновляется, чтобы позволить должнику не выполнять свои обязательства. true и false точно представляют, выполнил ли должник дефолт, а null - нет. Возможность обновления со значением по умолчанию false кажется более естественной, чем использование пустых полей.

1 Ответ

2 голосов
/ 11 июля 2019

Я думаю, что вы можете сделать это, пометив конструктор @JvmOverloads следующим образом: 

data class DummyState @JvmOverloads constructor(
    override val participants: List<AbstractParty>,
    val myNewProperty: String = "blah"
) : ContractState

(не вводите номера версий в имена классов состояний)

@JvmOverloads делает "старые" конструкторы видимыми для механизма десериализации для сопоставления.

Но, вероятно, здесь лучше указать строку кода:

val inDefault: Boolean get() = myNewProperty ?: false

или

fun priceOr(default: Amount<Currency> = 0.USD) get() = price ?: default

если вы действительно этого хотите.

Обратная совместимость и значения по умолчанию должны рассматриваться довольно осторожно. Распространенной ошибкой является использование значения по умолчанию ноль / пустая строка / ложь для вновь вводимых полей, даже если эти значения семантически значимы для приложения. То есть знание того, что в старом сообщении не указано что-то, является ценной информацией, которую нельзя потерять или заменить хрупкими дозорными значениями. Рассмотрим новое поле «цена». Цены не могут быть отрицательными, поэтому, возможно, разработчик устанавливает значение по умолчанию, равное нулю. Но ценить что-то как бесплатное - это значимая вещь - возможно, не в сегодняшнем бизнес-сценарии, а, возможно, завтра? Теперь у вас есть проблема.

Система типов и синтаксис Котлина очень хорошо справляются с отсутствующими значениями. Заменить стандартное значение на месте использования с помощью оператора ?: так просто, что я бы беспокоился о том, чтобы установить соглашение о постоянном предоставлении стандартного значения на строительной площадке, которому следуют младшие разработчики, не зная о возможных последствиях. Явное разоблачение того факта, что по умолчанию может быть заменено, заставляет людей задуматься о том, действительно ли это логично.

...