Здравствуйте, Быдлокодер, Вы писали:

Б>Интересно, а кто на практике использовал strongly typed domain modeling в реальном проекте? Какие результаты и выводы?
Я использую, но у меня не физика, нет необходимости складывать/делить и исполнять прочую арифметику.
Зато есть объекты, для которых есть целочисленные идентификаторы (uintXX_t в основном).
И у одного и того же объекта может быть больше одного идентификатора, в зависимости от того, кому он передаётся.
вот и есть у меня:

using session_id_t = StrongTypedef<..., uint32_t>;
using nsapi_t = StrongTypedef<..., uint8_t>;
using teid_t = StrongTypedef<..., uint32_t>;
using eps_bearer_id_t = StrongTypedef<..., uint32_t>;
using qci_t = StrongTypedef<..., uint8_t>;
using nsapi_t = StrongTypedef<..., uint8_t>;
using qdisc_id_t = StrongTypedef<..., uint32_t>;
// ну и ещё с десяток-полтора подобного

Результат — код лучше, ловил несоответствие формальных и фактических параметров ф-ций по типу не раз. Прямо во время написания кода редактор показывает, что такой вызов не получится.
Лучше всего проявляло себя во время рефакторингов модели. Без использования StrongTypedef я бы просто боялся делать изменения тех масштабов, которые я делал.

Кроме того, упрощаются некоторые виды анализов кода. Например, я легко могу найти все API, работающие с данным типом, да и вообще все места его использования.

Для каких-то типов я вводил специальные форматтеры для записи в журнал. Например, если Wireshark показывает тип как шестнатиричное 8-хциферное число с ведущими нулями, то мне в журнале удобно его видеть ровно так же, и я переопределяю желаемый формат в одном месте, затем просто использую `{}` где нужно, и в выводе программы я увижу "0000beda", без необходимости выписывать форматную строку в каждом месте. До того, как я ввёл строгие типы, одни и те же значения печатались то как десятичные, то как шестнадцатиричные.

Было такое, что для решения одной проблемы, когда мне нужно было анализировать много выхлопа программы, я оборачивал вывод в декоратор типа `---0000beda---` для более простого парсинга скриптом, и добавлял в журнал коды для выделения этих значений цветом, для более удобного поиска глазами. И то, и другое делалось в одном месте. Если бы нужно было найти и попатчить все места использования этого типа, я бы просто этого делать не стал.

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

Здравствуйте, Быдлокодер, Вы писали:

Б>Интересно, а кто на практике использовал strongly typed domain modeling в реальном проекте? Какие результаты и выводы?
Я использую, но у меня не физика, нет необходимости складывать/делить и исполнять прочую арифметику.
Зато есть объекты, для которых есть целочисленные идентификаторы (uintXX_t в основном).
И у одного и того же объекта может быть больше одного идентификатора, в зависимости от того, кому он передаётся.
вот и есть у меня:

using session_id_t = StrongTypedef<..., uint32_t>;
using nsapi_t = StrongTypedef<..., uint8_t>;
using teid_t = StrongTypedef<..., uint32_t>;
using eps_bearer_id_t = StrongTypedef<..., uint32_t>;
using qci_t = StrongTypedef<..., uint8_t>;
using nsapi_t = StrongTypedef<..., uint8_t>;
using qdisc_id_t = StrongTypedef<..., uint32_t>;
// ну и ещё с десяток-полтора подобного

Результат — код лучше, ловил несоответствие формальных и фактических параметров ф-ций по типу не раз. Прямо во время написания кода редактор показывает, что такой вызов не получится.
Лучше всего проявляло себя во время рефакторингов модели. Без использования StrongTypedef я бы просто боялся делать изменения тех масштабов, которые я делал.

Кроме того, упрощаются некоторые виды анализов кода. Например, я легко могу найти все API, работающие с данным типом, да и вообще все места его использования.

Для каких-то типов я вводил специальные форматтеры для записи в журнал. Например, если Wireshark показывает тип как шестнатиричное 8-хциферное число с ведущими нулями, то мне в журнале удобно его видеть ровно так же, и я переопределяю желаемый формат в одном месте, затем просто использую `{}` где нужно, и в выводе программы я увижу "0000beda", без необходимости выписывать форматную строку в каждом месте. До того, как я ввёл строгие типы, одни и те же значения печатались то как десятичные, то как шестнадцатиричные.

Было такое, что для решения одной проблемы, когда мне нужно было анализировать много выхлопа программы, я оборачивал вывод в декоратор типа `---0000beda---` для более простого парсинга скриптом, и добавлял в журнал коды для выделения этих значений цветом, для более удобного поиска глазами. И то, и другое делалось в одном месте. Если бы нужно было найти и попатчить все места использования этого типа, я бы просто этого делать не стал.

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