Средства и методы разработки

Суть: класс-бог VS брокер и сотня взаимодействующих топиков. 

А почему не нужное количество классов-богов, чье взаимодействие

не производится каким-то отдельным механизмом, а просто через факт совместного использования данных?

На полке стоит книга Н.Вирт "Алгоритмы+Структуры данных".

Создай "рельеф данных", посели на нем "богов", зачем тут брокер?

И чем топики сами себе не боги?

fk0 много говорил о событийном программировании. Да, брокеры == событийность. И есть системы, которые действительно

нужно строить событийными.

Но у меня - не заходит. Потому что ТЗ само собой пишется под "пятерку состояний" черного ящика.

"При вот таком сочетании входов, в таком состоянии, чешем в такое состояние и даем такие выходы". Как это поверх событийности делать?

Явно не то.

Второе, компоненты (топики) == инкапсуляция данных. Типа, гуд. В прошлом году Евгений давал тут ссылку на отличную статью https://habr.com/ru/post/451982/,

показывающую что для эмбедда это _немножко не так_.

Инкапсуляция данных нужна для копиразма, но порождает конфликты сферы видимости.

Разрешимые, конечно, но на кой черт их создавать самому себе?

Тоже мимо.

Третье, "унификация взаимодействий". Подлая, осознанная инфоцыганская диверсия.

Без комментариев.

Четвертое, юнит-тестирование. Тут тостующего явно подзанесло. Один юнит теституется точно также как и сотня.

Пятое, "христоматийный" пример типа-боинга :) Лютый треш. Проектирование снизу вверх наискосок, с натягиванием совы на картонный ящик от телевизора.

Пример почти законченного сетевого сервиса ни разу не равен ЗАКОНЧЕННОЙ системе управления! Даже в контексте анализа архитектуры.

Тем более, что лично я увидел в примере именно СТРУКТУРУ ДАННЫХ. Классическую. Из книжки дедушки Николаса.

Стандарт "кодирования для дронов" у него? А у нас есть Шатыло! Для танков :о)

Доклад закончен, спасибо за внимание :)