Цитата:
Короче, кому я все это рассказываю?
«... Да он издевается над нами! ...» (с)ктототам :о)
Цитата:
По всем канонам АТД.
???????????????????????????????!!!!!
Цитата:
"Видимый" (клиентам) стэйт может не иметь ничего общего с "внутренним".
"Внешняя" сущность может быть представлена комбинацией "внутренних".
Это ж основы компонентного программирования.
Это – подходы к реализации проектных решений! Не дай Бог с таких «основ» людей программированию учить!
Цитата:
В частности принцип "один интерфейс, множество реализаций". Потроха реализации не могут иметь отношение к интерфейсу по определению. "Просто методы" присутствуют в потрохах просто в силу того, что с ними удобнее/читабельнее реализовывать потроха в рамках конкретного языка (C++). "Не просто методы" присутствуют на уровне проектных решений.
VLAD!
То, что вы с таким жаром отстаиваете, есть просто достаточно частный (и довольно примитивный) способ понимания «интерфейса», аки набора функций для внешних пользователей. В рамках подходов, озвученных мной, Ваш случай - это когда всё множество актов взаимодействия ограничивается (АРХИТЕКТУРНО и СПЕЦИАЛЬНО!) по одной функции на «предоставляемую функциональность». Но в реальных системах сущности взаимодействуют сложными последовательностями обменов. В рамках, отстаиваемого Вами, подхода НЕТ формальных способов фиксации стадий (шагов) обмена между клиентами и серверами (в общем смысле этих слов). И нет поддержки ни со стороны языков, ни со стороны системы времени исполнения за правильностью хода такого взаимодействия! Ну разве что «поддерживается» ворохом диаграмм в доках сопровождения и соглашениями по наименованию «не просто методов»... Или Вы будете вынужденно изобретать «стэйтлесс» варианты взаимодействия... И чем это от не ООП вариантов реализаций отличаться будет? (потому я и упомянул «фортрановские подходы»).
А то, про что Вы описываете как «принцип "один интерфейс, множество реализаций"» - не есть сам принцип, а – языковый способ реализации. И он вынужденно «выпячен» на первые роли именно в силу давления подхода «один вызов функции(метода) – одна транзакция(получение результатов функциональности)». Именно в силу отсутствия поддержки и «слежения» за правильностью О_П_И_С_А_Н_Н_О_Г_О (НА ЯЗЫКЕ РЕАЛИЗАЦИИ) ПРОТОКОЛА обмена между сущностями («динамической» части описания)!
А будут у нас такие возможности – нам и док значительно меньше будет нужно – всё из текста программы будет автоматом выводиться! Это при традиционном понятии интерфейса, мы не можем оценить по тексту программы в нужной ли последовательности производится вызов тех или иных методов. А, при наличии формального описания протокола обмена, мы даже «скелеты» функций(методов) реализации протокола можем «заказывать» у среды разработки (а не просто «получение списка открытых методов и свойств»)!... Или – наоборот – требовать от среды анализа исходников на предмет соответствия протоколам...