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