Здравствуйте, ·, Вы писали:

AG>>Но у меня — универсальный узел и интерфейс к нему.
·>Нет, у тебя узел и иузел.

Напомню, что в терминологии C++ (в отличие от C# и Java) понятие интерфейс отсутствует.
Вместо него обычно применяется: абстрактный_класс:
https://www.tutorialspoint.com/cplusplus/cpp_interfaces.htm

AG>>Именно наличие программного интерфейса — позволяет уменьшить связанность (coupling) в проекте.
·>А конкретно в данном случае что именно уменьшается?

Показана идея применения абстрактного_класса C++ в качестве интерфейса.
Здесь (в приведенном примере) всё просто, поэтому избыточной связанности нет.

AG>>За счёт этого, получим упрощение архитектуры и уменьшение количества ошибок.
·>Введение новой сущности интерфейса не упрощает, а усложняет.

Конкретно здесь — упрощает понимание (даже если незначительно и увеличивает объём кода).

AG>>Конечно же, можно было обойтись и без интерфейса, однако так красивее и понятнее.
·>Эмоции. "Я так всегда делал и мне нравится"

Если быть точным, то делал я так не всегда.
Первые лет пять/шесть разработки на C++ я практически не применял абстрактные классы.
Но примерно с 2015-го понял, что такой подход упрощает понимание проекта.
Даже мне самому легче понять то, что я разработал несколько лет назад.
В литературе это именуют: best practices.

P.S. Мы не ждём, когда спроектируются новые узлы поезда/вагоны, а подготавливаем проект "рельсового пути" для существующих и новых поездов.
Вы же предлагаете проектировать новые рельсы, как только появятся новые вагоны.

Здравствуйте, ·, Вы писали:

AG>>Но у меня — универсальный узел и интерфейс к нему.
·>Нет, у тебя узел и иузел.

Напомню, что в терминологии C++ (в отличие от C# и Java) понятие интерфейс отсутствует.
Вместо него обычно применяется: абстрактный_класс:
https://www.tutorialspoint.com/cplusplus/cpp_interfaces.htm

AG>>Именно наличие программного интерфейса — позволяет уменьшить связанность (coupling) в проекте.
·>А конкретно в данном случае что именно уменьшается?

Показана идея применения абстрактного_класса C++ в качестве интерфейса.
Здесь (в приведенном примере) всё просто, поэтому избыточной связанности нет.

AG>>За счёт этого, получим упрощение архитектуры и уменьшение количества ошибок.
·>Введение новой сущности интерфейса не упрощает, а усложняет.

Конкретно здесь — упрощает понимание (даже если незначительно и увеличивает объём кода).

AG>>Конечно же, можно было обойтись и без интерфейса, однако так красивее и понятнее.
·>Эмоции. "Я так всегда делал и мне нравится"

Если быть точным, то делал я так не всегда.
Первые лет пять/шесть разработки на C++ я практически не применял абстрактные классы.
Но примерно с 2015-го понял, что такой подход упрощает понимание проекта.
Даже мне самому легче понять то, что я разработал несколько лет назад.
В литературе это именуют: best practices.

P.S. Мы не ждём, когда спроектируются новые узлы поезда/вагоны, а подготавливаем проект "рельсового пути" для существующих и новых поездов.
Вы же предлагаете проектировать новые рельсы, как только появятся новые вагоны.
YAGNI — если бы я предлагал проектировать поезд на магнитной подушке, для поездки по линии длиной 5 км, где вполне хватит обычного трамвая.