Заметка: Компонентная философия и реализация - Философия программирования

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

V>>Нужен всего один метод.
AC>Т.е. взаимодействие через интерфейс может быть только однонаправленным?

1. даже если через каждый пин однонаправленно, то м/у компонентами может быть сколько-угодно-направленным:

  A        B
        external 
        function
----+   +-------+
    |   |       |
arg >---> x     |
    |   |       |
res <---< y=x^2 |
    |   |       |
----+   +-------+

2. ПО гибче, чем схемотехника: сигнатура метода пина может возвращать значение, то бишь нарисованные 2 пина могут быть заменены одним, функциональным. (Кстате, в ФП другого способа-то и нет, т.к. непосредственные циклические подключения компонент невозможны).

В примере компонент B — это внешний функциональный преобразователь для A. Но! Обратное тоже верно!!! Однако, в ФП функцией может быть только кто-то один из них, т.е. никакой тебе симметричности. )))
Потому что только poll схема вычислений, а реактивнй подход это push.

А в теле самих компонент ес-но удобно писать на каком-нить языке по свойствам близком к мейнстриму, используя обычные ф-ии.

V>>Это если смотреть на интерфейсы как на типы. А ты смотри на них как на экземпляры.
AC>Т.е. компонент может создавать/разрушать свои интерфейсы?

В эту область можно порассуждать, но я уже предлагал сделать графы объектов иммутабельными, а мутабельными оставить только данные.

V>>И тогда пусть их будет хоть сотни — это не мешает ни чему.
AC>Анализ/отладка системы?

Проще, чем в современном ООП, ведь внутри каждого компонента нет гонок как во время теста, так и во время работы.

V>>1. Обычно интерфейсы не самодостаточны, а взаимодействуют со многими другими интерфейсами, если посмотреть на протокол некоей системы целиком. И тут начинает вылазить кривизна интерфейсов как типов:
AC>Это баг старых вариантов КОП.
V>>2. "Вхождения" многих интерфейсов пересекаются, то бишь ф-ии/кортежи, составляющие интерфейсы, порой дублируют друг друга.
AC>В смысле в одном интерфейсе или в нескольких интерфейсах одного компонента?

В нескольких интерфейсах, относящихся к одной подсистеме.

V>>3. Интерфейсы служат тормозом к развитию. Для добавления новых членов в кортеж ф-ий, составляющих интерфейс, тупо создают новый IOldName2 или IOldNameEx и т.д., что не требуется в случае наличия необходимых "пинов".
AC>Т.е. расширение интерфейса компонента будет выполнятся за чёт добавление новых пинов?

Мммм... не будет никакого расширения интефейса. Отдельный пин нерасширяем и несужаем.

V>>А что мы имеем сейчас? Сейчас контракт обслуживает сугубо интерфейсную (стыковочную) часть дизайна, а не поведенческую. То бишь, происходит ровно наоборот, под один и тот же интерфейс мы подставляем разные компоненты именно для целей разного их поведения.
AC>

по идее(даже в том же COM'е) контракт должен включать не только соглашение о собственно интерфейсе, но и соглашение о семантике интерфейса, в т.ч. и том как дожен "вести" себя владелец интерфейса при взаимодействии через этот интерфейс.

Ну и как себя должен вести стандартный вывод, перенаправленный в nul? На принтер? В сокет?
Вот так же и с пинами.

V>>Один метод в интерфейсе — меньше не бывает. ))
AC>В модели КОП из заметки, в интерфейсе может быть не одного метода, для случая когда нужно только установить факт подключения/отключения.

Непонятна практическая польза от этого. Сейчас пустые интерфейсы используются как иммутабельные поля типа bool. Т.е., идёт дублирование языковых ср-в. В дотнете есть еще 3-й аналогичный вариант — аатрибуты.

V>>Или раскрыть термин "высокая/низкая связанность"?
AC>Да.

При низкой связанности дизайн построен на небольшом кол-ве "всем известных типов". Низкая связанность означает гибкость, ведь для замены элемента новым, этот новый должен знать лишь об общих типах, а не о конкретных. Если же компоненты полагаются на знание конкретики друг о друге — то это высокая связанность. Если в системе полно уникальных интерфейсов (как раз по 1-му на компонент или около того) — то вот пример сильной связанности.

V>>Я нечто подобное ковыряю на досуге... Периодически встают разного рода вопросы конфликта синтаксиса...
AC>Интересно, опиши пожалуйста(лучше с картинками и комментированым псевдокодом), что из себя будет представлять компонент с пинами, каковы возможности пинов и, как будет выполнятся взаимодействие компонентов, в общих чертах.

Э нет, это слишком надолго.
Исходная задача — собирать из "кубиков" сложные алгоритмы обработки сигналов (звука). Про варианты взаимодействия рядом написал тебе же.
Когда-то паял примочки к гитарам, потом стал экспериментировать программно: http://www.rsdn.ru/forum/alg/3793843.1
Как раз во время регулярных программных экспериментов всё больше убеждаюсь в убогости КОП в современных текстовых ЯВУ.

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

V>Да всё-равно не выйдет. Программа целиком и есть семантика.

Почему же, в ограниченном диапазоне — вполне выйдет. Design by contract, особенно статический — это же мега-круто.

Ну а семантику прям всей программы рассматривать, ИМХО, не стоит.

V>Я еще не смотрел, но почему-то уверен, что когда посмотрю, то за пару минут придумаю, как без проблем удовлетворить любой контракт, но при этом нарушить исходную семантику. ))

Не сомневаюсь.

Но в любом случае, чем больше проверок — тем лучше.

ARK>>Кстати, я там выше спрашивал — в вашей модели, как я понимаю, компоненты принципиально без состояния (каждый выход — функция всех входов)? Т.е. понятие "последовательность вызовов" бессмысленно?

V>Это зависит от модели расрпостранения сигналов. Если синхронная модель — то последовательность вызовов имеет смысл. Если асинхронная, то тоже имеет, но уже по-другому (реакция лишь на изменения значения, а не на факт поступления 2-в-1-м — сигнала+события).

Так. Как я понимаю, это в программе будет выглядеть примерно таким образом — в теле какой-то функции мы должны дергать выходы компонента в определенном порядке (так же, как в императивном программировании — сперва открываем файл, потом читаем из него). Контракты совсем бы не помешали, чтобы проконтролировать это (сперва читай этот выход, потом этот).

V>Я, вообще-то за то, чтобы компоненты могли (при надобности) иметь состояние.

Тогда внутри компонента с состоянием будет куча локов-синхронизаций?

V>Наружу выставляется кортеж пинов. Такой кортеж вполне себе тип.
V>Насчет выставлять другие компоненты как значения пинов — я соображения уже высказал: это путь к точно такому бардаку, который уже есть де-факто. Боюсь, без понятия "фабрики" не обойтись всё-равно, но использование фабрики весьма специфично — она используется только в момент создания "вычислителя".

Т.е. вы определяете в своей модели набор примитивных типов (ну и один структурный примитив "кортеж").

V>"Пробрасывается" не значение, а сам пин в момент соединения компонент. Значение потом идёт напрямую от источника к приемнику, игнорируя уровни иерархии дизайна.

Ну да, я так и понял. ИМХО, концептуально может быть и копирование значения (если это упрощает модель). А на деле копирование убирается компилятором.

ARK>>Ну, данные наверное тоже можно считать примитивными "компонентами".

V>Хотите об этом поговорить? Я бы с удовольствием. Тут самое время раскатать в блин понятие "ссылочного типа" и его зачастую некорректное применение к типам, отвечающим за данные. И всё потому, что компилятор позволяет что угодно.

Я лично считаю, что ссылочные типы не нужны.

V>Всю схему "кто-то" должен пересчитывать. Этот кто-то должен раздавать компонентам вычислительные ресурсы. Принцип раздачи может быть очень разный.
V>Например: каждый пин будет содержать буфер-защелку. Когда на одном (любом) входе компонента будет обнаружено событие подачи сигнала, то компонент будет поставлен в очередь к шедуллеру. Когда до компонента дойдет очередь, то он может пересчитать свои выходы от всех измененных к моменту получения вычислительных ресурсов входов. В этом смысле логический вычислительный поток каждого компонента постоянно сидит в ожидании входных сигналов. Т.е. мы имеем строгую агентную среду, где не может быть гонок внутри компонент.

Вопрос только — что будет, если пересчитать не успели, а пришел новый сигнал? В теории можно обрубить вычисления, если результатом их не предполагается побочного эффекта. Только будет ли компилятор достаточно умен, чтобы отслеживать такие вещи...

V>Логику можно усложнить. Например, реагировать не на факт подачи сигнала, а лишь на изменение входного значения.

ИМХО, имеет смысл реагировать только на изменение — во всех случаях.

V>Кстате, для эрудиции, базовый в схемотехнике RS-триггер — это классический асинхронный автомат, то бишь, автомат, выполненый на "чистых" функциях — логических вентилях.

Да, кое-что слышал об этом.

V>Прямо отсюда должно быть понятно, почему я не сильно отличаю императивный и функциональный подход. Подобные устойчивые системы могут быть гораздо более сложными, чем RS-триггер. Могут состоять из кучи абсолютно чистых ф-ий, но при этом обладать изменяемым состоянием. Достаточно в ФП-программе суметь создать, например, циклическую структуру данных — и ву а ля, вот тебе изменяемое состояние из бесконечно считаемых по кругу ф-ий. Текущее устойчивое значение ф-ии на каждом витке вполне можно принять за состояние (как это есть в RS-триггере). Например, в упрощенном виде такая циклическая структура дана в виде монады IO в Хаскеле (при том, что её зацикливание выполняется внешним, по отношению к программе, вычислителем).

Тут уже появляется новая сущность — некое "устойчивое состояние" системы. ИМХО, это сильно усложняет понимание программы.

V>Если компонент может сигнализировать об ошибке — пусть у него будет под это специальный пин.

А если мы забудем поверить этот специальный пин?

V>Если речь о зависимых типах, то мы просто не сможем подать на такой входной пин неподходящий выходной. Система типов не даст.

Вот это интересный момент.

Как вы себе это представляете? Это же те самые контракты.

V>Это цикл, а не короткое замыкание. Короткое замыкание — это когда гонки. А цикл — это очень полезная структура. ))

Ну окей, пусть цикл. По-моему, возможность зацикливания надо бы устранить, нет?

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

V>>Не совсем. Это семантический эквивалент на механику вокруг IConnectionPoint/IConnectionPointContainer
AVK>По заявлениям ТС, реактивность не есть обязательный признак. Так что нет.

Я имел ввидутот факт, что предлагаемый автором топика способ подключений компонент — это именно подача интерфейсов обратного вызова, точно так же как листенеры в джаве или как IConnectionPoint/IConnectionPointContainer в COM. Или как ты привел пример с IObservable.

V>>, а так же их IDispatch-эквивалент. Это аналог джавовских листенеров событий. Всё это "красиво" встроено в язык VB/VBA, но в С++, Джаве и дотнете аналогичное только ручками.
AVK>Аналогичное что?

Аналогичное по механике соединение компонент через обмен интерфейсами обратного вызова. На сегодня только ручками в ООП-языках, кроме VB/VBA/VBS.

AVK>С шарпе IConnectionPoint превращается в обыкновенное событие.

Мммм... каждое событие в шарпе — независимо. Поэтому подписывание на интерфейс обратного вызова происходит поэлементно через делегаты, эдакие указатели на методы, нарушающие ООП-типизированность контрактов обратного вызова. Сравни с джавой, где ты обязан подписаться на контракт обратного вызова целиком, а не только на его часть. Да, я понимаю, что базовые листенеры событий представляют из себя "пустышки"... но тем не менее, они отвечают контракту. Эдак удовлетворение любого обычного интерфейса можно сделать через пустышки и превратить строго-типизированные контракты в россыпь независимых методов, каждый из которых можно реализовать отдельно. Собсно, я именно так и предлагаю поступить с обычными ООП-контрактами в моей модели. Ведь именно так поступили с контрактами обратного вызова в дотнете и никто не парится по этому поводу.

AVK>При желании можно завернуть в IObservable.

Вот теперь правильная аналогия, поздравляю. Это оно есть. Это ручная реализация тех самых "пинов" поверх ООП. Смотри, насколько коряво выходит в ООП-синтаксисе без поддержки языка.

V>>Дык, реактивность требует некоторой поддержки
AVK>Какой?

Ну, хотя бы упомянутого уже не раз декларативного порт-маппинга и обязательного низлежащего "вычислителя-шедуллера", потому как сейчас без слез на эту кашу вокруг тривиальных вещей смотреть невозможно:

// Synchronous operation
public DataType DoLongRunningOperation(string param) {
    ...
}

public IObservable<DataType> LongRunningOperationAsync(string param) {
    return Observable.CreateWithDisposable<DataType>(
        o => Observable.ToAsync(DoLongRunningOperation)(param).Subscribe(o)
    );
}

В желаемой некоей реактивной (или агентной в ООП-координатах) среде должен быть только первый метод, который ведет себя как второй:

component C1 {
  in param : string;
  out result : DataType = 
    { // LongRunningOperation depending on param
      ...
    };
}

Или взять ручное заворачивание событий в C# для целей сохранения строгой типизации:

  // To consume GenericEvent as an IObservable:
  IObservable<IEvent<SomeEventArgs>> eventAsObservable = Observable.FromEvent<SomeEventArgs>(
    ev => GenericEvent += ev,
    ev => GenericEvent -= ev);

Сорри, но это хи-хи. Это роспись в том, что C# как язык не приспособлен для целей "настоящего" компонентного программирования (когда программа действительно составляется из "кубиков"-компонент в декларативной манере).

Вот зачем нужен отдельный язык — чтобы подобное шло изкаробки.

=============
Так-то я крайне положительно отношусь к Rx — это ведь постепенная наработка понимания, что нужно современному сложному ПО... хотя лично я, как программист, не готов работать в столь убогой манере, как предлагается в Rx. Просто рано или поздно "кол-во понимания проблемы" должно перерасти в кач-во и тоже самое станет возможно в человеческом виде.

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

V>Я имел ввидутот факт, что предлагаемый автором топика способ подключений компонент — это именно подача интерфейсов обратного вызова

Автор прямо и недвусмысленно это опроверг.

V>Аналогичное по механике соединение компонент через обмен интерфейсами обратного вызова. На сегодня только ручками в ООП-языках, кроме VB/VBA/VBS.

Все равно непонятно — чем VB в этом плане лучше шарпа. Тем что подписку на события можно в декларации описать? Это все?

V>Мммм... каждое событие в шарпе — независимо.

А что такое зависимые события и зачем они нужны?

V>Сравни с джавой, где ты обязан подписаться на контракт обратного вызова целиком

Я на джаве в свое время пописал достаточно. Дотнетные события удобнее. А IObservable еще удобнее.

V>, а не только на его часть. Да, я понимаю, что базовые листенеры событий представляют из себя "пустышки"... но тем не менее, они отвечают контракту.

Делегат дотнетный это тоже вполне себе строго типизированный контракт. Как и IObservable.

V> Эдак удовлетворение любого обычного интерфейса можно сделать через пустышки и превратить строго-типизированные контракты в россыпь независимых методов

Вот только колбек это не то же самое, что прямой метод. Но даже если тебе сильно хочется по непонятной причине набор событий оформить в виде единого контракта — на базе того же IObservable это сделать совсем несложно.

V>Вот теперь правильная аналогия, поздравляю. Это оно есть. Это ручная реализация тех самых "пинов" поверх ООП.

IObservable это реализация паттерна publisher-subscriber. Не меньше и не больше.

V>Ну, хотя бы упомянутого уже не раз декларативного порт-маппинга

Зачем?

V> и обязательного низлежащего "вычислителя-шедуллера"

Шедулеры прекрасно реализованы в Rx без какой либо поддержки языка. Я тебе больше скажу — на прямой вопрос Эрику Мейеру, какая поддержка для Rx может быть добавлена в C#, он ответил прямо и недвусмысленно — никакая не нужна.

V>Или взять ручное заворачивание событий в C# для целей сохранения строгой типизации:

Ручное заворачивание нужно только для совместимости со старым кодом.

V>Сорри, но это хи-хи. Это роспись в том, что C# как язык не приспособлен для целей "настоящего" компонентного программирования

Скорее он не приспособлен для странного конструкта, который ты сочинил.