Добрый день!

Нужно написать небольшую программу.
Хочется написать ее, используя принципы слабого связывания.
Проблема в том, что это нужно сделать на процедурном языке программирования: классов нету, интерфейсов нету, указателей на функции нету, внедрения зависимостей нету.

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

Как это делается в процедурных языках?

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

Z>Как в этом случае можно хоть в каком-то виде реализовать слабое связывание?
Z>Простой пример.
Z>Пользователь нажимает на кнопку и запускает какую-то длительную бизнес-операцию. При этом происходит изменение бизнес-данных.
Z>Модуль, реализующий эту бизнес-операцию, по мере изменения данных должен оповещать другие модули об этих изменениях.
FSM

Z>Модуль, реализующий интерфейс (форму, с которой работает пользователь), должен в ответ на это оповещение понять какие данные изменились и отобразить эти изменения.

Z>Как это делается в процедурных языках?
https://www.youtube.com/watch?v=M7uo5jmFDUw

_>https://www.youtube.com/watch?v=M7uo5jmFDUw

В "моем" ЯП нету таких возможностей как в Erlang-е.
Я использую простой-примитивный язык.

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

Z>В "моем" ЯП нету таких возможностей как в Erlang-е.
Z>Я использую простой-примитивный язык.

ST ?

Здравствуйте, zelenprog, Вы писали:
Z>Как это делается в процедурных языках?
Обычно в процедурных языках есть тип данных "указатель на процедуру". Всё строится поверх него.

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

Z>Я использую простой-примитивный язык.

Используйте язык DSL который будет компилироваться в ваш неведомый простой-примитивный язык.

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

Z>Как это делается в процедурных языках?

Да куча вариантов. Например, можно определить формат обмена данных и передавать данные через unix socket, fifo, или обычный файл. Оповещения можно реализовать через сигналы или подписку на события файловой системы. Если язык совсем уж примитивный, и нет доступа ни к функциям операционной системы, ни к сырой памяти (чтобы реализовать указать на функцию), то нужно задуматься о целесообразности использования этого языка. Названия языка можно узнать? Или это секретные секреты местных НИИ?

Z>>Как это делается в процедурных языках?
S>Обычно в процедурных языках есть тип данных "указатель на процедуру". Всё строится поверх него.

В том-то и дело, что в "моем" языке нету указателей на процедуру.
Как выкрутиться в этой ситуации?

C> Названия языка можно узнать? Или это секретные секреты местных НИИ?

Нет, это не секреты. Но называть этот язык не хочу — засмеёте.
Но написать надо небольшую программу именно на этом языке.

C> Если язык совсем уж примитивный, и нет доступа ни к функциям операционной системы, ни к сырой памяти (чтобы реализовать указать на функцию), то ...

Доступа к функциям ОС и к сырой памяти нету, указателей на функцию нету.

_>Используйте язык DSL который будет компилироваться в ваш неведомый простой-примитивный язык.

DSL, мне кажется, тут не поможет.
DSL ведь можут работать с классами\объектами. Значит в нем "естественным" образом реализуется и слабое связывание и внедрение зависимостей.
Переложить это на процедурный язык, мне кажется, просто невозможно.

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


_>>Используйте язык DSL который будет компилироваться в ваш неведомый простой-примитивный язык.

Z>DSL, мне кажется, тут не поможет.
Z>DSL ведь можут работать с классами\объектами. Значит в нем "естественным" образом реализуется и слабое связывание и внедрение зависимостей.
Z>Переложить это на процедурный язык, мне кажется, просто невозможно.

Приведите пример кода на вашем "безымянном" языке
Создание переменных (локальных, глобальных)
Ветвление
Циклы
Вызов функций
Определение функций
Опрелеление массивов
Определение структур
Есть ли какие ограничения?

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


C>> Названия языка можно узнать? Или это секретные секреты местных НИИ?

Z>Нет, это не секреты. Но называть этот язык не хочу — засмеёте.
Вы из-за такой ерунды переживаете? Вам шашечки или ехать?

Z>Но написать надо небольшую программу именно на этом языке.

C>> Если язык совсем уж примитивный, и нет доступа ни к функциям операционной системы, ни к сырой памяти (чтобы реализовать указать на функцию), то ...

Z>Доступа к функциям ОС и к сырой памяти нету, указателей на функцию нету.
Целые числа есть? Массивы есть? Если да то можно всё что угодно сделать.

Сделать отдельную структуру-очередь. К примеру на основе кольцевого списка. Далее один модуль в него добавляет оповещение. У других модулей есть функция вроде process_events(), которая вызывается где-то в основном цикле. Эта функция проверяет наличие оповещений и обрабатывает их, если они есть.

Т.е. развернуть модель работы с push на poll.

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

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

Z>Но написать надо небольшую программу именно на этом языке.
VBScript? 1C?

Z>Доступа к функциям ОС и к сырой памяти нету, указателей на функцию нету.
Аналог eval() точно должен быть. Если и этого нет, то это сизифов труд, писать на таком языке.

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

Z>>>Как это делается в процедурных языках?
S>>Обычно в процедурных языках есть тип данных "указатель на процедуру". Всё строится поверх него.

Z>В том-то и дело, что в "моем" языке нету указателей на процедуру.
Z>Как выкрутиться в этой ситуации?

У меня дежавю

Автор: zelenprog
Дата: 14.07.23

?
Прошёл всего год.

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

Z>Нет, это не секреты. Но называть этот язык не хочу

VisualBasic ?

_>Приведите пример кода на вашем "безымянном" языке
_>Создание переменных (локальных, глобальных)
_>Ветвление
_>Циклы
_>Вызов функций
_>Определение функций
_>Опрелеление массивов
_>Определение структур

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

_>Есть ли какие ограничения?

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

Без указателей на функции код получается жестко связанным.

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

Z>По сути мне нужно "вручную" придумать механизм, заменяющий указатели на функции.
Зачем?

Z>Без указателей на функции код получается жестко связанным.
Какую задачу вы хотите решить? Причем тут жесткая связанность. Все проблемы связанности важны при масштабированиии, в маленьких программах это не принципиально.
В C это решалось написанием мелких утилит которые компоновались друг с другом через ввод/вывод.

cat input | prog1 --prm 1 | prog2 | prog3 > result

SVZ>У меня дежавю

Автор: zelenprog
Дата: 14.07.23

?
SVZ>Прошёл всего год.

Да, настоящая тема — очень похожа на ту старую тему.

Только в той старой теме я использовал более "продвинутую" (более позднюю) версию "моего" языка, которая умела работать с несколькими модулями.
То есть программа могла состоять из нескольких модулей. Можно было использовать отдельный файл-модуль как отдельный класс.
Это позволяло "эмулировать" работу с объектами.
И нужно было придумать, как реализовать механизм наследования, используя отдельные модули как классы.

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

Но это не исключает того, что этот модуль надо организовать так, чтобы методы были разделены по обязанностям. Чтобы между методами, относящимися к разным обязанностям, было как можно меньшее связывание.
Так как по объему кода, по количеству функций, этот модуль получится достаточно большой.
Без "логичного" разделения в нем будет трудно ориентироваться.

Вот чтобы в этой программе получилось слабое связывание между процедурами, нужно придумать как в этом процедурном языке "внедрять" одну процедуру в другую.
Например, есть процедура, которая выполняет "бизнес"-операцию.
Эта процедура "оповещает" о выполненных действиях. На эти оповещения должен отреагировать другой код.
Для простоты рассмотрим интерфейс: на оповещения интерфейс должен перерисоваться соответствующим образом, то есть имеется процедура, которая отображает что-то на форме в зависимости от оповещения о выполненном дейтсвии.
Однако, в зависимости от разных начальных условий, интерфейс будет разным, и должен по разному реагировать на оповещения.
То есть вызывающая процедура, которая инициирует весь этот процесс, должна:
1) "создать" соответствующий интерфейс и
2) "внедрить" его в бизнес-процедуру
3) вызвать бизнес-процедуру.

Смысл в том, что потом потребуется создать еще один (третий) вид интерфейса.
И хорошо было бы, чтобы создав новую процедуру для нового интерфейса, например "GUI_Update3()", реализующую новый способ "реакции", я поменял бы только код вызывающей процедуры, добавив новое условие:

func UserStartProcess()
{
    if (...)
        lGUIUpdater = GUI_Update1
    elseif (...)
        lGUIUpdater = GUI_Update2
    elseif (...)
        lGUIUpdater = GUI_Update3

    DoBusinessProcess(lGUIUpdater);
}

И чтобы мне не пришлось менять ни бизнес-процедуру, ни других частей программы.

_>Какую задачу вы хотите решить? Причем тут жесткая связанность. Все проблемы связанности важны при масштабированиии, в маленьких программах это не принципиально.

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

Вот здесь подробнее описал:
https://rsdn.org/forum/design/8788388.1

Автор: zelenprog
Дата: 28.07 13:00