Конечный автомат, также известный как конечный автомат (FSM), представляет собой математическую модель, абстрагированную от правил работы реальных вещей. Он состоит из регистра состояния и комбинационной логической схемы. Он может выполнять передачу состояния в соответствии с заданным состоянием в соответствии с управляющим сигналом. Это центр управления, который координирует соответствующие действия сигналов и выполняет определенные операции.
Конечные автоматы в основном делятся на две категории: первый тип, если выход связан только с состоянием и не имеет ничего общего с входом, он называется конечным автоматом Мура, второй тип, если выход не только связан; к состоянию, но также и к входным данным, он называется автоматом состояний Мили.
В качестве примера возьмем коробку передач автомобиля. Если это автоматическая коробка передач, то каждая передача, соответствующая переключению передач, имеет состояние. Например, передача P означает стоянку, а передача N означает состояние холостого хода. Передача находится в рабочем состоянии, R Задняя передача. Каждое поведение переключения будет изменять состояние коробки передач. Такое поведение переключения эквивалентно событию перехода состояния. Существуют ограничения на события перехода состояний конечного автомата, а ограничения перехода состояний коробки передач являются физическими ограничениями. Если взять в качестве примера мой Chevrolet, то для переключения с передачи P на передачу D мне нужно: P файлы -> N файлы- > R файлы -> D файлы преобразуются последовательно и не могут быть преобразованы напрямую из P файлы Перейти кDфайлы。
Определите статус: Определите различные статусы системы. Каждое положение файла коробки передач эквивалентно статусу государственной машины.
Определите переходы: Определите переходы между состояниями и определите, когда выполняются условия для того, чтобы переход произошел. Каждое переключение передач в коробке передач представляет собой переход состояний.
Определить действия: для разных состояний определите соответствующие действия. Эти действия могут выполняться при входе в состояние, при выходе из него или во время определенных переходов.
Событие: его также можно назвать триггером, что означает то же самое, что является триггером или паролем для выполнения определенной операции: когда конечный автомат находится в определенном состоянии, конечный автомат сработает только тогда, когда внешний мир сообщит о состоянии. машина, что делать. Выполнять определенные действия для завершения операций, которые требует от нее внешний мир.
Поняв базовые знания, а затем нарисовав диаграмму состояний, вы можете написать код в соответствии с диаграммой состояний для реализации логики этого конечного автомата.
В предыдущих главах мы рассказали, что такое конечный автомат и как его использовать. В повседневной разработке мы всегда думаем так. Код конечного автомата настолько сложен. Сложный код может замедлить наш прогресс в разработке. Нужно ли нам использовать конечный автомат? Итак, здесь мы разберем, что может дать нам государственная машина и каковы ее недостатки.
Вообще говоря, конечные автоматы удобны в использовании и способствуют дальнейшему обслуживанию и расширению, но стоимость использования относительно высока, и для программистов существует определенный технический порог. Но это все технически. Будет ли все по-другому, если мы посмотрим на это с другой стороны?
Как упоминалось ранее, все преимущества и недостатки конечных автоматов рассматриваются с технической точки зрения. Однако если вы посмотрите на то, что может дать государственная машина с точки зрения бизнеса.
Доменно-ориентированное проектирование — это подход к разработке программного обеспечения, при котором сложные проблемы решаются путем подключения конкретных реализаций к постоянно улучшающейся модели основных бизнес-концепций. Эта концепция была предложена Эриком Эвансом. Что касается определения предметно-ориентированного проектирования, в «Глоссарии терминов предметно-ориентированного проектирования» их много в Интернете, и я не буду представлять их здесь подробно.
Ранее мы говорили о конечных автоматах, а теперь внезапно переходим к DDD (проектирование, управляемое предметной областью). Какова связь между ними? Необходимо поговорить об идее разработки в DDD, которая заключается в том, чтобы позволить экспертам в предметной области и техническим экспертам создавать друг друга. общий язык. Разработайте систему вместе. Государственная машина просто выражает этот бизнес-процесс на техническом языке, чтобы технические эксперты и эксперты в предметной области имели общую модель для описания идей, которые они хотят выразить, чтобы лучше общаться и развиваться.
Помимо снижения затрат на связь между экспертами предметной области и техническими экспертами, конечный автомат также помогает в разработке модели предметной области следующими способами:
Что касается разработки DDD с поддержкой режима состояний, некоторые концепции конечных автоматов в чем-то похожи на некоторые концепции в DDD. Тем, кто не знаком с DDD, полезно сначала проанализировать модель состояния бизнеса, а затем использовать модель состояния для проектирования системы с использованием идей DDD. С этой точки зрения модель состояний может помочь новичкам понять DDD и снизить порог входа в DDD. Но если вы хотите эффективно использовать DDD, одной модели состояний недостаточно. DDD — это полноценная методология проектирования программного обеспечения, а конечный автомат — это всего лишь реализация модели состояний.
Существует определенный порог для начала работы с конечным автоматом, но он не слишком высок. Прежде чем использовать его, лучше всего прислушаться к советам опытных технических специалистов, прежде чем решать, использовать ли конечный автомат. Если вы можете дать какие-то конкретные сведения. предложения, я лично считаю, что вам необходимо учитывать следующие моменты:
Как шаблон проектирования, конечный автомат, помимо того, что он технически делает наши изменения в коде более гибкими и простыми для расширения, его большим преимуществом является то, что он позволяет нам более четко понимать весь бизнес-процесс при проведении технического анализа. Лично я считаю, что вопрос не в том, использовать ли конечный автомат в проекте, а в том, чтобы использовать идею конечного автомата для анализа бизнес-процесса. ясно понятно, какой бы метод не использовался для реализации бизнеса, результат будет в два раза лучше, приложив вполовину меньше усилий.