Связь самая прямая. Одна из причин возникновения онкологии — длительное воспаление. В данном случае воспаление скорее всего было вызвано бактериальной инфекцией.
По 12 часов человек не может ежедневно работать. Скорее всего там график неделя через неделю. Т.е. две недели в месяце рабочие (включая и выходные тоже), две — нет.
Прекрасно. И если вы обратите внимание, то увидите, что в рамках одного обработчика совершается действие, которое приводит к инициации другого. Ведь так?
Похоже, что так.
Что такого предлагает ситуационное программирование, что позволяет радикально уменьшить размер (семантически эквивалентного) блока кода?
Я не про семантически эквивалентный блок, а про процедуру (функцию), как блок. Правда в СП количество процедур действительно будет больше.
Это два независимых правила, реализующих различные бизнес-задачи. Как следствие, SRP говорит нам, что они должны быть в разных обработчиках
Это два алгоритма, которые будут реализованы в разных подпрограммах, но вызваны в рамках одного обработчика, который вызывается для ситуации «Транзакция по счету завершилась».
Пример выше.
Внутри каждого обработчика можно вызывать друг за другом другие поддпрограммы, или выполнять манипуляции с локальными данными.
Так вот, когда состояние системы удовлетворяет условиям «движение вниз и позиция в нижнем краю» — вызываются оба обработчика, или только один?
Могут и два, если у них нет общих переменных, то могу вызваться параллельно, если есть, то друг за другом. Но код в каждом из них будет разный, каждый для своего случая. Это видно на реальном примере. У меня сложностей с пониманием что куда нужно распихивать не возникало ни разу. Но не стану утверждать, что и не возникнет.
Например, человек один раз ввел «Идет игра». И как вы говорили раньше, спустится на один уровень иерархии, далее будет работать только с условиями актуальными только для режима игры. Через коммуникационный интерфейс можно будет запрашивать доступные на текущем уровне иерархии условия, переходить по уровням вниз-вверх.
Не могут. Под пересечением я имел в виду не одновременный вызов, а то, что часть кода из одного может мигрировать в другой (новый). Это же разные вещи.
Это же два разных условия, правильно? И два разных обработчика, так?
Боюсь там будет побольше двух условий (и обработчиков). Было бы
так просто я бы сразу код написал. Но то, что они разные это точно.
Знаете, структурное программирование — которое избавляет от линейных простыней — давно придумали.
Структурное программирование призвано уменьшить код блока (процедуры/функции).
Ситуационное программирование призвано свести код блока к 1-2 строкам.
Во-первых, тезис «у каждой ситуации свой обработчик» не запрещает иметь два обработчика на одну ситуацию.
Да как же у одной ситуации может быть больше одного обработчика??
Во-вторых, если вы введете ограничение «на одну ситуацию один обработчик», вы резко уменьшите поддерживаемость системы (потому что бывают независимые обработчики).
Ничего не понял.
Наконец, в-третьих, я говорил об обработчиках, условия которых совпадают, но не идентичны. Пример был выше: условиями одной ситуации является «движение вниз», условиями другой — «движение вниз и позиция в нижнем краю». Это же два разных обработчика?
Ну конечно. Первое это триггер, у него свой обработчик. Второе это условие из двух триггеров, у этого условия свой обработчик.
Под символическим представлением я подразумеваю:
1. Текущая секция змейки является головой
2. Направление движения змейки — вниз
3. Голова змейки находится в самой нижней клетке поля
Т.е. набор символических представлений триггеров (на ЕЯ).
Вернее примерно так:
(? чего змейки,? какая текущая) секция? что является? чем головой.
змейка? что движется? куда вниз.
змейки? чего голова? что находится? где клетка (? какая *самая нижняя,? чего поля).
Когда выяснили? Они могут пересекаться только если создается новое условие.
(1) при каждом списании 100 рублей со счета, на связанный счет должен начисляться 1 рубль (бонусная система)
(2) раз в месяц со счета должны списываться 1000 рублей (регулярный платеж)
Это отдельная подпрограмма, соизмеримая со змейкой. Но она реализуема.
И сразу возникает вопрос, как вы будете бороться с возрастанием сложности в таком случае.
Модульностью
И уже успели обобщить свой опыт на все возможные ситуации
Да, пока не появились ситуации не вписывающиеся в опыт.
О какой «линейной простыне» вы говорите?
Об классическом программирование: if, for, while…
Обработчики — разные, но их условия совпадают. По логике, должны вызываться оба. Это так, или нет?
Не может быть так. У каждого условия (ситуации) свой обработчик.
Я не про семантически эквивалентный блок, а про процедуру (функцию), как блок. Правда в СП количество процедур действительно будет больше.
Это два алгоритма, которые будут реализованы в разных подпрограммах, но вызваны в рамках одного обработчика, который вызывается для ситуации «Транзакция по счету завершилась».
Внутри каждого обработчика можно вызывать друг за другом другие поддпрограммы, или выполнять манипуляции с локальными данными.
Могут и два, если у них нет общих переменных, то могу вызваться параллельно, если есть, то друг за другом. Но код в каждом из них будет разный, каждый для своего случая. Это видно на реальном примере. У меня сложностей с пониманием что куда нужно распихивать не возникало ни разу. Но не стану утверждать, что и не возникнет.
Боюсь там будет побольше двух условий (и обработчиков). Было бы
так просто я бы сразу код написал. Но то, что они разные это точно.
Структурное программирование призвано уменьшить код блока (процедуры/функции).
Ситуационное программирование призвано свести код блока к 1-2 строкам.
Да как же у одной ситуации может быть больше одного обработчика??
Ничего не понял.
Ну конечно. Первое это триггер, у него свой обработчик. Второе это условие из двух триггеров, у этого условия свой обработчик.
1. Текущая секция змейки является головой
2. Направление движения змейки — вниз
3. Голова змейки находится в самой нижней клетке поля
Т.е. набор символических представлений триггеров (на ЕЯ).
Вернее примерно так:
(? чего змейки,? какая текущая) секция? что является? чем головой.
змейка? что движется? куда вниз.
змейки? чего голова? что находится? где клетка (? какая *самая нижняя,? чего поля).
Это отдельная подпрограмма, соизмеримая со змейкой. Но она реализуема.
Модульностью
Да, пока не появились ситуации не вписывающиеся в опыт.
Об классическом программирование: if, for, while…
Не может быть так. У каждого условия (ситуации) свой обработчик.
Там стоит заглушка. Интерпретатор пока в разработке.