Борьба с ложными состояниями: взгляд из C++ на Rust-дилеммы и реактивный код
Хабр, привет! На днях наткнулся на отличную статью Никиты Тимофеенко «Вам не нужны bool и Option» . Автор со стороны Rust-разработки поднимает фундаментально правильный вопрос: кодировать состояния системы разрозненными флагами вроде succeeded: bool и failed: bool — это плохой тон, ведущий к трудноуловимым багам. Система типов должна делать некорректные состояния запрещенными на этапе компиляции. В C++ сообществе эта идея, разумеется, тоже не нова. Мы давно и успешно оборачиваем подобные вещи в std::variant , используя std::monostate как аналог отсутствия значения ( можно задать псевдоним, например AbsentResult ). Но читая статью и комментарии к ней, я поймал себя на мысли: мы, разработчики, слишком сильно увлеклись мощью современных компиляторов. Как только стандарты C++ (да и Rust) дали нам инструменты для зубодробительных compile-time проверок любых сущностей, мы начали пихать эти проверки везде, где нужно и не нужно. В этой статье я хочу показать, как правильное использование std::variant может... замаскировать серьезную ошибку проектирования архитектуры. Как увлечение построением лучшей системы типов отвлекает нас от фундаментальных вопросов проектирования систем. Мы разберем, как классические стейт-машины при поллинге (polling) заставляют нас писать тонны шаблонного кода ради проверок, которых в этой точке программы вообще не должно существовать .
https://habr.com/ru/articles/1106116/
#архитектура #проектирование #c++ #качество_кода #реактивное_программирование #variant #rust #система_типов #c++20 #стейтмашина