Информация об изменениях

Сообщение Re: The Big OOPs: Anatomy of a Thirty-five-year Mistake от 18.09.2025 11:12

Изменено 18.09.2025 11:13 SaZ

Re: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, σ, Вы писали:

σ>...

σ>Смотрел несколько дней назад, уже всего точно не помню, но вот некоторые моменты:
σ>
  • Инкапсуляцию придумали когда делали симуляцию поведения распределённых систем. В этом случае инкапсуляция — адекватная модель для предметной области. Но оопе-сектанты пропагандируют что для всех областей.
    σ>...

    Свежий пример из моей практики, про инкапсуляцию. На текущем проекте мы разрабатываем stateless ui фреймворк поверх ImGui для собственных нужд и благодаря этому не требовалось инкапсуляции, например есть struct TextWidgetContent{ std::string text; } и в коде просто меняешь текст на нужный, без вызова каких либо функций и уведомлений и на следующем фрейме текст обновится. У подхода есть свои плюсы и минусы, но в целом оказалось удобно.
    А потом начали вылазить проблемы. Изначально была публичная переменная m_enabled, которая определяла можно ли взаимодействовать с виджетом. Потом функционал начал расширяться. Например, нужно проверить, можно ли перейти к виджету через табуляцию, ну и написали метод типа
    bool is_tab_stoppable() const
    {
      return m_enabled && m_tab_stoppable;
    }

    Но поленились причесать код, и где-то состояние проверялось через этот геттер (инкапсуляция), а где-то напрямую флаги. А потом добавили ещё одно состояние — m_is_focusable. В геттер его сразу вписали, а вот в нескольких местах, где не было инкапсуляции и напрямую проверялись значения полей — забыли. И потом периодически фиксили баги. Понятно, что можно было прокликать каждую переменную, найти места где она используется (благо Решарпер хорошо с этим справляется) и заменить на тот или иной геттер. Но мелкие баги из-за этого вылазили в течение месяца. А если бы сразу всё заворачивали в геттеры — таких вопросов бы не возникло.
  • Re: The Big OOPs: Anatomy of a Thirty-five-year Mistake
    Здравствуйте, σ, Вы писали:

    x>...

    x>Смотрел несколько дней назад, уже всего точно не помню, но вот некоторые моменты:
    x>Инкапсуляцию придумали когда делали симуляцию поведения распределённых систем. В этом случае инкапсуляция — адекватная модель для предметной области. Но оопе-сектанты пропагандируют что для всех областей.
    x>...

    Свежий пример из моей практики, про инкапсуляцию. На текущем проекте мы разрабатываем stateless ui фреймворк поверх ImGui для собственных нужд и благодаря этому не требовалось инкапсуляции, например есть struct TextWidgetContent{ std::string text; } и в коде просто меняешь текст на нужный, без вызова каких либо функций и уведомлений и на следующем фрейме текст обновится. У подхода есть свои плюсы и минусы, но в целом оказалось удобно.
    А потом начали вылазить проблемы. Изначально была публичная переменная m_enabled, которая определяла можно ли взаимодействовать с виджетом. Потом функционал начал расширяться. Например, нужно проверить, можно ли перейти к виджету через табуляцию, ну и написали метод типа
    bool is_tab_stoppable() const
    {
      return m_enabled && m_tab_stoppable;
    }

    Но поленились причесать код, и где-то состояние проверялось через этот геттер (инкапсуляция), а где-то напрямую флаги. А потом добавили ещё одно состояние — m_is_focusable. В геттер его сразу вписали, а вот в нескольких местах, где не было инкапсуляции и напрямую проверялись значения полей — забыли. И потом периодически фиксили баги. Понятно, что можно было прокликать каждую переменную, найти места где она используется (благо Решарпер хорошо с этим справляется) и заменить на тот или иной геттер. Но мелкие баги из-за этого вылазили в течение месяца. А если бы сразу всё заворачивали в геттеры — таких вопросов бы не возникло.