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);
}

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

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);
}

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