Есть анекдот от Мамонова про старого гитариста.Выходит молодой гитарист и начинает играть и левой рукой и правой и вверх тормашками и за спиной и над головой. Выходит старый именитый гитарист, сел на стульчик и начинает на трех аккордах играть. Его спрашивают — «чего ж ты такой примитив гонишь? вон видишь молодой как скачет». «Вы понимаете», спокойно отвечает старый — «он еще ищет, а я уже нашел».
Способов сделать много, я как раз планировал в продолжение написать как сделать, что бы программист не заботился о списках в коде. Что-то типа
if Is_in_list(type_id, "список типов, ТЗ от 01.01.2016") then
do something;
end if;
В функции is_in_list() выдывать исключение и мгновенно оповещать разработчика или аналитика, даже если исключение возникло у другого пользователя. Так даже пользователю не надо будет звонить в поддержку, что бы разобраться. Поддержке или программисту придет сообщение
«При обработке 'список типов, ТЗ от 01.01.2016' возникло исключение в таком-то куске кода. Требуется либо добавить новый тип в список, либо внести изменения в код для особой обработки этого типа»
>Есть абстрактный тип данных «Договор» в виде интерфейса или абстрактного класса.
В ООП проблема остается, абстракция — это обобщение. Свойства договора на момент ТЗ фиксированы. Это очевидно. Вопрос — что будет в будущем? Появится новый тип договора и заказчик не гарантирует, что он будет попадать под старые свойства. Приведенный метод сразу будет сигнализировать во всех местах, где нужно обрабатывать новый тип. Как такое можно сделать на ООП — вопрос открытый? Какие есть идеи?
Я как раз против абстракций.
Надо Вам пару гигабайт кода кинуть, что бы Вы там в чужих абстракциях пару месяцев погуляли.
Главное, что бы принцип был понятен, а использовать assert или еще что-то другое — не важно. От перемены названия мало что меняется.
>Только зачем, если проблема в сообществе DDD давно решена более легкими в поддержке и изящными способами?
приведите пример
да банально, не спорю,
Есть анекдот от Мамонова про старого гитариста.Выходит молодой гитарист и начинает играть и левой рукой и правой и вверх тормашками и за спиной и над головой. Выходит старый именитый гитарист, сел на стульчик и начинает на трех аккордах играть. Его спрашивают — «чего ж ты такой примитив гонишь? вон видишь молодой как скачет». «Вы понимаете», спокойно отвечает старый — «он еще ищет, а я уже нашел».
В функции is_in_list() выдывать исключение и мгновенно оповещать разработчика или аналитика, даже если исключение возникло у другого пользователя. Так даже пользователю не надо будет звонить в поддержку, что бы разобраться. Поддержке или программисту придет сообщение
«При обработке 'список типов, ТЗ от 01.01.2016' возникло исключение в таком-то куске кода. Требуется либо добавить новый тип в список, либо внести изменения в код для особой обработки этого типа»
Выдавать ошибку, когда встретился незнакомый тип, «by design» не обеспечивает. По крайней мере на уровне языков такого не встречал.
В ООП проблема остается, абстракция — это обобщение. Свойства договора на момент ТЗ фиксированы. Это очевидно. Вопрос — что будет в будущем? Появится новый тип договора и заказчик не гарантирует, что он будет попадать под старые свойства. Приведенный метод сразу будет сигнализировать во всех местах, где нужно обрабатывать новый тип. Как такое можно сделать на ООП — вопрос открытый? Какие есть идеи?