Вообще я против словоблудия, и если вы об этом же, то я с Вами согласен.)
В статье я дал простое мнемоническое правило, которого вполне хватает для новичков.
Никто не отказывается ни от объектов-помощников, ни от ограничений применимости любого правила (как мы знаем из формальной логики). Правила голову не заменят. Но, с моей точки зрения, приведённое правило — неплохой старт.
Кто может привести более простое, правильное и понятное для новичков — буду рад услышать и использовать в дальнейшем.
Подходит как методика разруливания времени существования контролов и нотификации об этом Окна. Если это единственное что вас смущало — тогда это и есть решение, да. )
С моей точки зрения, Вы вполне правы.
Всё зависит от риторики и от точки зрения, например, на человека как единую сущность или как композицию более простых элементов и узлов. То есть, ваше утверждение не противоречит моему, всё зависит от того как посмотреть и как что назвать. Вам ближе рассматривать поэлементно — не вопрос. )
Дело в том, что GUIController придётся знать, что творится внутри у Silo (потому что именно исходя из этой информации он создаёт интерфейс). Следовательно, изменяя что-то внутри Silo, придётся менять и GUIController.
Например, я захотел уникодовый Text: следовательно поменялся не только Silo, но и GUIController::AddButton().
Дополню: если бы сам класс при этом получался слишком большим, я бы делал объекты-помощники (точно также закрытые, с доступом через открытые функции-члены), которые включил бы в свой класс.
Single responsibility principle, на самом деле, звучит довольно разумно. И как бы напоминает апологетам строгой инкапсуляции вроде меня, что фанатизм плох в любом деле. )
С одной стороны, создавать излишние сцепления я лично считаю порочной практикой. С другой стороны, когда сложность объекта превышает некую субъективную отметку, функционал объекта следует разбивать на части. И в этом случае я лично использую объекты-помощники, которые включаю в свой класс. Разумеется, сами объекты-помощники также закрыты, как и их владелец. И взаимодействие точно также идёт только через открытые функции-члены.
Разумеется, я не претендую на Истину. И с самого начала говорю про субъективность моего подхода. Утверждаю лишь, что всё это неплохо срабатывает на практике. Поскольку я писал и с открытыми объектами, и со строгой инкапсуляцией, смею считать что мне есть с чем сравнивать. Чего и другим желаю.
А чего такого страшного? Если фреймворк позволяет, то вообще не проблема.
В случае всяких СиБилдеров и прочего, да, приходится учитывать время жизни контролов и порядок инициализации. Зато при каждом чихе и апдейте вы не правите вот такие вот интерфейсы
void MyEntity::UpdateFromUI(Combo *combo1, Combo *combo2, Button *button1, Button *button2, Button *button3, EditString *editor1);
На практике происходит вообще всё что угодно.
Например, в классе Бункер у меня находился алгоритм управления, который я отлаживал два месяца на реальном оборудовании. И у меня не было никакой возможности и желания всё это трогать. Так что пример очень даже реальный: слабое сцепление может сэкономить кучу времени, при всей кажущейся неканоничности подхода.
Понимаю, что отказ от открытых данных кажется необычным и рискованным. Он требует переосмысления самого процесса проектирования классов и их взаимодействия. Всё что я предлагаю — это попробовать. Вдруг, этот подход окажется на практике не таким и узкоспециализированным. )
Условная компиляция, конечно, не панацея. Я бы предложил решать конкретную задачу, а не делать решение на все случаи жизни. Всё вышеописанное — без фанатизма, конечно. habrahabr.ru/blogs/cpp/111120/#comment_3543799
Сортируют обычно в каком-то массиве, либо другом контейнере. Это должно явно указываться в задании. Постановка невнятная, тем более для того, кто претендует на какой-то уровень.
В статье я дал простое мнемоническое правило, которого вполне хватает для новичков.
Никто не отказывается ни от объектов-помощников, ни от ограничений применимости любого правила (как мы знаем из формальной логики). Правила голову не заменят. Но, с моей точки зрения, приведённое правило — неплохой старт.
Кто может привести более простое, правильное и понятное для новичков — буду рад услышать и использовать в дальнейшем.
Всё зависит от риторики и от точки зрения, например, на человека как единую сущность или как композицию более простых элементов и узлов. То есть, ваше утверждение не противоречит моему, всё зависит от того как посмотреть и как что назвать. Вам ближе рассматривать поэлементно — не вопрос. )
Например, я захотел уникодовый Text: следовательно поменялся не только Silo, но и GUIController::AddButton().
С одной стороны, создавать излишние сцепления я лично считаю порочной практикой. С другой стороны, когда сложность объекта превышает некую субъективную отметку, функционал объекта следует разбивать на части. И в этом случае я лично использую объекты-помощники, которые включаю в свой класс. Разумеется, сами объекты-помощники также закрыты, как и их владелец. И взаимодействие точно также идёт только через открытые функции-члены.
Разумеется, я не претендую на Истину. И с самого начала говорю про субъективность моего подхода. Утверждаю лишь, что всё это неплохо срабатывает на практике. Поскольку я писал и с открытыми объектами, и со строгой инкапсуляцией, смею считать что мне есть с чем сравнивать. Чего и другим желаю.
По поводу ТДД человек сказал лучше меня: habrahabr.ru/blogs/cpp/111120/#comment_3543916
В случае всяких СиБилдеров и прочего, да, приходится учитывать время жизни контролов и порядок инициализации. Зато при каждом чихе и апдейте вы не правите вот такие вот интерфейсы
void MyEntity::UpdateFromUI(Combo *combo1, Combo *combo2, Button *button1, Button *button2, Button *button3, EditString *editor1);
Например, в классе Бункер у меня находился алгоритм управления, который я отлаживал два месяца на реальном оборудовании. И у меня не было никакой возможности и желания всё это трогать. Так что пример очень даже реальный: слабое сцепление может сэкономить кучу времени, при всей кажущейся неканоничности подхода.
habrahabr.ru/blogs/cpp/111120/#comment_3543799