Если рассуждать в терминах MVC, то можно сказать, что в статье описан один из возможных способов реализации контроллера.
Давайте попытаемся «натянуть» на описанную программу шаблон MVC:
M — model (модель/данные) — ядро оригинальной программы. Данные, это некая структура объектов.
V — view (отображение) — функции, возвращающие код HTML страницы, шаблонизатор, веб-сервер.
C — controller (устройство управления) — в нашем случае КА (FSM), обеспечивающий передачу сигналов от пользователя к модели и логику управления моделью.
Подождите, вот встретится в жизни реальный Карабас-Барабас, окажется что не так все легко и тирвиально. Большинство-то как раз в таких ситуациях приступают к сливу.
Вы будете смеятся, но для меня любимой книгой был и остается «Буратино». Читать мне ее не нужно, я ее и так хорошо помню. Чем она меня так зацепила? Учебник жизни. Чему научила? При любых обстоятельствах не унывать, быть верным друзьям, всегда идти к цели.
Да, Столлман, сколько раз говорили, что он просто фанатик, что рулит не туда, а в конце-концов он оказывался прав. Должен быть такой человек, который ко всему последовательно подходит с точки зрения принципов свободы. Особенно во фри коммунити. Коммерческие принципы отстаивать желающих сколько угодно.
Пардон, отвлекся и забыл, больше не повторится.
Третий вариант это только сильная ругань и наказания. Можно добится многого, но в большом проценте случаев получается противоположный эффект, вместо закрепления привычки к аккуратности получаем сильное сопротивление и отрицание, в самостоятельной жизни ребенку придется самому приходить к аккуратности.
В принципе это та же мотивация и недостатки примерно те же. «Волевой мускул» не тренируется.
Это не просто, а очень просто. У меня двое уже взрослых детей. Предположим у Вас есть ребенок и вы хотите научить его застилать за собой постель. Рассмотрим три варианта:
1. Попробуем через грубую мотивацию. Застелишь — конфета. Прошла неделя. У тебя кончились конфеты, ребеноку они тоже приелись, постель так и не стелится. Задача не выполнена. Плюс ребено приучается к шаблону, что нефиг дергаться, если нет прямой и приятной отдачи.
2. Пробуем внедрить в голову ребенку, что есть обязанности, которые хотя и неохота, но необходимо выполнять. За застеленнную постель хвалим, но не очень сильно, за незастеленную поругиваем немного, сами подаем пример. Через некоторое время шаблон внедрен, ребенок сам, нехотя стелит постель по утрам, сам исподволь и потихоньку тренирует волевой мускул. Через год застилание постели для него не составляет никакого труда.
Я бы сказал, что достижение целей через мотивацию иногда работает, но далеко не всегда, кое что необходимо делать через волю.
Мне кажется, Вы немножко путаетесь. Есть мотивация. В данных жизненных условиях для данного человека можно принять за константу. Есть некий коэффициент отдачи, есть полезный выхлоп из всего этого. Обозначим:
М — мотивация
К — коэффициент преобразования мотивации в полезный эффект
В — выхлоп (полезный эффект из всего этого)
Тогда имеем:
В = М * К
Т.е. при постоянной мотивации чем выше К, тем выше полезный эффект. В качестве существенно важной сооставляющей и входит сила воли.
Мотивацию, ИМХО, существенно и на длительный период поднять невозможно. А может даже и не нужно и даже вредно. А вот силу воли, так называемый «волевой мускул» можно и нужно тренировать.
Вот о методах тренировки «волевого мускула» и написана данная статья.
Дополнено к пункту 3.:
Конечно совершенно необязательно было делать массивы функций. Можно было сделать переходы и через вложенные вызовы функций. Массивы были выбраны для того, чтобы в совокупности с говорящими названиями исполняемых функций получить в одном месте (в словаре перехода) удобочитаемые цепочки исполняемых для перехода действий.
Пример, один ключ/значение словаря (значение тоже словарь):
Хочу вот статеечку в блог родить по этому поводу.
Сейчас могу вкратце на пальцах объяснить. Реализовано на Python. Все на стороне сервера.
1. Переходы из состояния в состояние по запросу от браузера. В запросе параметр tostate=«state to go to». FSM помнит предыдущее состояние.
2. Есть словарь переходов. В этом словаре ключом является строка вида «prev_state» + «next_state». Значением строки является массив названий функций, которые необходимо выполнить при выполнении перехода. Функции работают с атрибутами класса и являются интерфейсом к ядру программы.
3. Метод обработки переходов запоминает предыдущее состояние и последовательно исполняет функции из массива функций перехода.
4. Состояния сделаны двух видов одни состояния условно называются «Show» (показать страницу), другие «Action» они например выполняют проверку формы и в зависимости от результатов переходят в одно из состояний типа «Show».
5. Последняя функция в массиве функций перехода возвращает для перехода в состояние типа «Show» html код для передачи серверу, для состояния типа «Action» — имя состояния, в которое перейти.
Ну вот, вроде и все. Пока готова первая версия. Она включает 20 состояний и 38 переходов.
Недавно реализовал Веб-интерфейс приложения используя конечный автомат. Бибилиотекой не делал, все реализовал в одном классе. Главной целями ставил:
— Чтобы можно бы было нарисовать удобночитаемую диагррамку состояний интерфейса.
— Чтобы код соответствовал диаграмме.
— Чтобы легко было бы перемещаться от кода к диаграмме и наоборот.
— Чтобы легко можно бы было разбираться/добавлять/удалять состояния и действия.
Думаю, что поставленные цели достигнуты.
Конечно. Еще желательно, если уж применяешь паттерн, то написать в комментариях, какой и как или в чем отличия. Чтобы тот, кому придется этот код переделывать мог легко понять, о чем речь. Ну и имена говорящие.
— Согласен, но не совсем, терминология тоже важна, чтобы говорить об одном и том же и понимать друг друга.
— По двери на седьмом этаже, конечно не нужно делать дверь на седьмом этаже, т.е. к паттернам подходить здраво, как Вы и написали. Если уж нужно покидать помещение прямо с седьмого этажа, то нужно не бездумно лепить паттерн «дверь» прямо на этаже а грамотно применить два паттерна:
«дверь» + «пожарная лестница». Естественно для этого нужно понимать то, что делаешь и почему выбираешь паттерны «дверь» + «пожарная лестница», а не паттерн парашют.
По паттернам, кстати, хотелось бы еще отметить следующую проблему. Они рождены и поисаны во многом, как решение специфических проблем, возникающих при программировании на C++ (и возможно Java), при программировании на других языках, например с динамической типизацией, таких как Python, нежелательно тупо применять паттерны из GoF. Бездумное их применение усложняет программу на питоне очень сильно. Для Python, нужны другие паттерны.
Конечно, ничего не мешает принять в качестве внутрифирменного стандарта использование для определенных типовых задач определенных паттернов. Но деление на стандарт/стиль кодирования и паттерны уже устоялось и лучше эти вещи не путать.
Все-таки хорошо бы разделять стандарт (стиль) программирования и паттерны. Нпример, чтобы не путаться. Я бы в качестве аналогии привел конструкторскую документацию:
стиль/стандарт — оформление чертежей и конструкторской документации
паттерны — типовые конструкции узлов изделий
Я бы сказал, что шаблоны проектирования это скорее типовые примеры грамотного конструирования элементов программы. Их использование, кроме прочего позволяет писать понятные другим программистам программы.
В общем случае конструирование программы должно подразумевать следующие шаги:
— Анализ задачи.
— Подготовка требований к программе
— Анализ возможных изменений программы в будущем (например, добавление новых типов интерфейсов)
— Разбиение на модули/объекты/массивы объектов
— В нужных/ключевых местах подбор подходящих паттернов. Обязательно учитывая отношение эффективности их применения к затратам, хотя бы приблизительно.
Давайте попытаемся «натянуть» на описанную программу шаблон MVC:
M — model (модель/данные) — ядро оригинальной программы. Данные, это некая структура объектов.
V — view (отображение) — функции, возвращающие код HTML страницы, шаблонизатор, веб-сервер.
C — controller (устройство управления) — в нашем случае КА (FSM), обеспечивающий передачу сигналов от пользователя к модели и логику управления моделью.
Или скорее наоборот.
— GCC!
— Вся юниксовая обвязка!
Еще бы терминал получше.
Цель воспитания — внедрить в сознание:
1. Определенные шаблоны поведения.
2. Способность к самостоятельному поведению.
Во втором пункте, одна из вещей, которым нужно научить ребенка, это ставить перед собой задачи и добиваться их выполнения.
Опять-таки, одна из вещей, которые для этого нужны, это умение выполнять множество рутинных/неприятных/неинтересных вещей. Вот для легкого выполнения таких вещей и нужно развивать «волевой мускул».
А по каждому мелкому поводу находить и применять мотивацию нерационально. Есть такое слово «надо».
По-моему, так! © Винни-Пух
Третий вариант это только сильная ругань и наказания. Можно добится многого, но в большом проценте случаев получается противоположный эффект, вместо закрепления привычки к аккуратности получаем сильное сопротивление и отрицание, в самостоятельной жизни ребенку придется самому приходить к аккуратности.
В принципе это та же мотивация и недостатки примерно те же. «Волевой мускул» не тренируется.
1. Попробуем через грубую мотивацию. Застелишь — конфета. Прошла неделя. У тебя кончились конфеты, ребеноку они тоже приелись, постель так и не стелится. Задача не выполнена. Плюс ребено приучается к шаблону, что нефиг дергаться, если нет прямой и приятной отдачи.
2. Пробуем внедрить в голову ребенку, что есть обязанности, которые хотя и неохота, но необходимо выполнять. За застеленнную постель хвалим, но не очень сильно, за незастеленную поругиваем немного, сами подаем пример. Через некоторое время шаблон внедрен, ребенок сам, нехотя стелит постель по утрам, сам исподволь и потихоньку тренирует волевой мускул. Через год застилание постели для него не составляет никакого труда.
Я бы сказал, что достижение целей через мотивацию иногда работает, но далеко не всегда, кое что необходимо делать через волю.
М — мотивация
К — коэффициент преобразования мотивации в полезный эффект
В — выхлоп (полезный эффект из всего этого)
Тогда имеем:
В = М * К
Т.е. при постоянной мотивации чем выше К, тем выше полезный эффект. В качестве существенно важной сооставляющей и входит сила воли.
Мотивацию, ИМХО, существенно и на длительный период поднять невозможно. А может даже и не нужно и даже вредно. А вот силу воли, так называемый «волевой мускул» можно и нужно тренировать.
Вот о методах тренировки «волевого мускула» и написана данная статья.
Конечно совершенно необязательно было делать массивы функций. Можно было сделать переходы и через вложенные вызовы функций. Массивы были выбраны для того, чтобы в совокупности с говорящими названиями исполняемых функций получить в одном месте (в словаре перехода) удобочитаемые цепочки исполняемых для перехода действий.
Пример, один ключ/значение словаря (значение тоже словарь):
# 23 'page_pg_block_add':{'type':'Act','methods':[self.fsm_pg_block_add, self.fsm_diag_files_rm, self.fsm_create_cur_page_diag_files, self.fsm_page_cur_save, self.fsm_go_to_page]},# 23 — номер перехода по диаграмме
Сейчас могу вкратце на пальцах объяснить. Реализовано на Python. Все на стороне сервера.
1. Переходы из состояния в состояние по запросу от браузера. В запросе параметр tostate=«state to go to». FSM помнит предыдущее состояние.
2. Есть словарь переходов. В этом словаре ключом является строка вида «prev_state» + «next_state». Значением строки является массив названий функций, которые необходимо выполнить при выполнении перехода. Функции работают с атрибутами класса и являются интерфейсом к ядру программы.
3. Метод обработки переходов запоминает предыдущее состояние и последовательно исполняет функции из массива функций перехода.
4. Состояния сделаны двух видов одни состояния условно называются «Show» (показать страницу), другие «Action» они например выполняют проверку формы и в зависимости от результатов переходят в одно из состояний типа «Show».
5. Последняя функция в массиве функций перехода возвращает для перехода в состояние типа «Show» html код для передачи серверу, для состояния типа «Action» — имя состояния, в которое перейти.
Ну вот, вроде и все. Пока готова первая версия. Она включает 20 состояний и 38 переходов.
— Чтобы можно бы было нарисовать удобночитаемую диагррамку состояний интерфейса.
— Чтобы код соответствовал диаграмме.
— Чтобы легко было бы перемещаться от кода к диаграмме и наоборот.
— Чтобы легко можно бы было разбираться/добавлять/удалять состояния и действия.
Думаю, что поставленные цели достигнуты.
— По двери на седьмом этаже, конечно не нужно делать дверь на седьмом этаже, т.е. к паттернам подходить здраво, как Вы и написали. Если уж нужно покидать помещение прямо с седьмого этажа, то нужно не бездумно лепить паттерн «дверь» прямо на этаже а грамотно применить два паттерна:
«дверь» + «пожарная лестница». Естественно для этого нужно понимать то, что делаешь и почему выбираешь паттерны «дверь» + «пожарная лестница», а не паттерн парашют.
стиль/стандарт — оформление чертежей и конструкторской документации
паттерны — типовые конструкции узлов изделий
В общем случае конструирование программы должно подразумевать следующие шаги:
— Анализ задачи.
— Подготовка требований к программе
— Анализ возможных изменений программы в будущем (например, добавление новых типов интерфейсов)
— Разбиение на модули/объекты/массивы объектов
— В нужных/ключевых местах подбор подходящих паттернов. Обязательно учитывая отношение эффективности их применения к затратам, хотя бы приблизительно.