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

AG>>>Но у меня — универсальный узел и интерфейс к нему.
AG>·>Нет, у тебя узел и иузел.
AG>Напомню, что в терминологии C++ (в отличие от C# и Java) понятие интерфейс отсутствует.
AG>Вместо него обычно применяется: абстрактный_класс:
AG>https://www.tutorialspoint.com/cplusplus/cpp_interfaces.htm
Не знаю зачем ты это всё рассказал, но это я и так прекрасно знаю. Если этот код переписать на C#/Javа суть не изменится.
Даже хуже. В плюсах и так уже есть пара h/cpp, а ты ещё и третью штутку создаёшь.

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

AG>Здесь (в приведенном примере) всё просто, поэтому избыточной связанности нет.
Ок. Т.е. и пользы от интерфейса (в приведённом примере) тоже нет (по крайней мере для устранения избыточной связности). ЧТД.

AG>>>За счёт этого, получим упрощение архитектуры и уменьшение количества ошибок.
AG>·>Введение новой сущности интерфейса не упрощает, а усложняет.
AG>Конкретно здесь — упрощает понимание (даже если незначительно и увеличивает объём кода).
Это субъективно. Просто делает код более привычным тебе лично. А объективное усложнение хотя бы по объёму кода точно есть. Плюс объективно появляется лишняя сущность в коде, которая требует поддержки.

AG>>>Конечно же, можно было обойтись и без интерфейса, однако так красивее и понятнее.
AG>·>Эмоции. "Я так всегда делал и мне нравится"
AG>Если быть точным, то делал я так не всегда.
AG>Первые лет пять/шесть разработки на C++ я практически не применял абстрактные классы.
AG>Но примерно с 2015-го понял, что такой подход упрощает понимание проекта.
AG>Даже мне самому легче понять то, что я разработал несколько лет назад.
Да. Я тоже таким был. А потом ещё пять-шесть лет опыта, научился пользоваться современными тулзами и начал понимать что надо _не_ делать.

AG>В литературе это именуют: best practices.
Не знаю конкретно какой код ты имеешь в виду, но в приведённом примере это именуется cargo cult.

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