Дизайн и архитектура в ФП. Часть 3

[utyv]

Поправьте меня если я ошибаюсь. После того как мы реализовали объект через Map, компилятор уже не знает какие свойства есть у того или иного объекта. Для обобщенных сценариев это не проблема. Но если мы напишем сценарий для определенного вида объектов, и обратимся к свойству, которого у этого объекта нет, то это будет ран-тайм ошибка. Которая в нашей архитектуре будет молчаливо обработана отменой сценария.

Т.е. архитектура ослабляет преимущества статического языка.

[graninas]

Вы не ошибаетесь, кое-что мы теряем. Поправлю только, что не архитектура ослабляет, а дизайн, — мы ведь говорим о модели обработки данных в одной конкретной подсистеме, а не о всей взаимосвязи компонентов.

Однако почему у определенного вида объектов не будет нужного свойства? Куда оно денется? Или на этапе создания данного объекта мы не проверили, что все нужные свойства на месте?

[utyv]

Однако почему у определенного вида объектов не будет нужного свойства?

Программисты ошибаются. В программу вносятся изменения.

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

[graninas]

Вы правы, решение не самое идеальное. Я бы даже сказал, что PropertyMap лично для меня ощущается как плохой код. И я встречал мнение, что такие структуры нужно избегать. В общем-то, согласен с этим, и в третьей версии логики подобная «динамичность» сведена к минимуму.

[nickolaym]

Поправочка.
Должно быть progression op = iterate (`op` 2) без 1 в конце.

[graninas]

Спасибо за внимательное чтение! Исправил.