Это статья, которую я не могу прочитать сам...
Статья условно разделена на две части:
-
Введение в режим состояний
-
Использование и анализ исходного кода библиотеки функций javascript-state-machine модели конечного автомата
Сценарий и предыстория проблемы:
Когда мы обычно разрабатываем, мы по существу переключаем различные состояния приложения и соответствующим образом с ними работаем. Наиболее прямое решение состоит в том, чтобы принять во внимание все эти возможные ситуации, а затем использовать операторы if... else для вынесения суждений о состоянии для обработки различных ситуаций. Однако оценка сложных состояний делает логику кода особенно хаотичной. При добавлении нового состояния или изменении состояния оператор if else или switch case будет соответствующим образом увеличен или изменен, а удобочитаемость и масштабируемость программы станут слабыми. Техническое обслуживание также может быть обременительным.
Возьмем пример, вы когда-нибудь играли в Contra? :
Давайте сначала рассмотрим простую реализацию простейшего действия:
class Contra {
constructor () {
//存储当前待执行的动作
this.lastAct = {};
}
//执行动作
contraGo (act){
if(act === 'up'){
//向上跳
}else if(act === 'forward'){
//向前冲啊
}else if(act === 'backward'){
//往老家跑
}else if(act === 'down'){
//趴下
}else if(act === 'shoot'){
//开枪
}
this.lastAct = act;
}
};
var littlered = new Contra();
littlered.contraGo('shoot');
скопировать кодЧто делать, если есть два комбинированных действия? Измени это:
function contraGo (act){
constructor () {
//存储当前待执行的动作
this.lastAct1 = "";
this.lastAct2 = "";
}
contraGo (act1, act2){
const actArr = [act1, act2];
if(actArr.indexOf('shoot') !== -1 && actArr.indexOf('up') !== -1){
//跳着开枪吧
}else if(actArr.indexOf('shoot') !== -1 && actArr.indexOf('forward') !== -1){
//向前跑着开枪吧
}else if(actArr.indexOf('shoot') !== -1 && actArr.indexOf('down') !== -1){
//趴着开枪吧
}else if(actArr.indexOf('shoot') !== -1 && actArr.indexOf('backward') !== -1){
//回头跑着开枪吧
}else if(actArr.indexOf('up') !== -1 && actArr.indexOf('forward') !== -1){
//向前跳吧
}else if(actArr.indexOf('up') !== -1 && actArr.indexOf('down') !== -1){
//上上下下吧
}
...//等等组合
this.lastAct1 = act1;
this.lastAct2 = act2;
}
}
var littlered = new Contra();
littlered.contraGo('shoot');
скопировать кодНедостатки очевидны.Много if else суждений.При добавлении оглядки на Xiaohong и Xiaolan приходится модифицировать метод contraGo и добавлять кучу перестановок и комбинаций,что делает contraGo очень неудобным.Стабильный метод, и чем больше состояний, тем больше, возвышеннее метод contraGo нарушает принцип открытого-закрытого!
Потом"режим состояния"Спускайтесь вниз, чтобы спасти людей...
Вставьте здесь открытый и закрытый принцип, и вы сможете перейти в конец следующей разделительной линии.
В чем болевые точки — в процессе разработки, когда исходную логику нужно модифицировать из-за изменений, апгрейдов и сопровождения и т.п., очень вероятно, что в старый код будут внесены ошибки, или нам, возможно, придется проводить рефакторинг всю функцию, и требуется новое тестирование исходной функции.
Как это решить - мы должны попытаться внедрить изменения, расширив поведение сущностей, а не модифицируя существующий код для реализации изменений.
Если быть точным - классы, модули и функции должны быть открыты для расширения и закрыты для модификации. Модули должны расширяться без изменения исходного кода.
Ядро — создавайте фреймворки с абстракциями и расширяйте детали с помощью реализаций.
Подводя итог - разработчики должны абстрагировать часто меняющиеся части программы, а затем расширять класс реализации, производный от абстракции.При изменении кода необходимо только заново разработать класс реализации в соответствии с требованиями. От нас требуется быть дальновидными и предсказуемыми к изменениям требований, и в то же время отказываться от преднамеренного абстрагирования каждой части приложения.
Включая открытый и закрытый принципы, шесть принципов шаблонов проектирования здесь подробно не описываются, но кратко перечислены ниже:
Единый принцип (SRP):Класс реализации должен нести единую ответственность. Класс делает только одну вещь или один тип вещей. Не смешивайте функции, которые нельзя разделить на один тип. Обещай мне
Принцип замены Лисков (LSP):Не разрушайте систему наследования.Подклассы могут полностью заменить родительский класс, который они наследуют.При этом можно понять, что место вызова метода родительского класса заменяется подклассом, и вызов может выполняться нормально.Сын страны, заложенной отцом, получится без нажима, верно?
Принцип инверсии зависимостей (DIP):Позвольте мне объяснить вам мое понимание: если определенный набор функций или бизнес-логики может иметь другой параллельный режим или серьезные корректировки позже, лучше абстрагировать эту часть логики, создать абстрактный класс, содержащий связанные методы, и реализовать Класс наследует этот абстрактный класс, чтобы переписать методы в абстрактном классе и завершить конкретную реализацию.Класс, который вызывает эти функциональные методы, не должен заботиться о конкретной реализации этих методов, которые он вызывает, а только вызывает формальные методы, определенные в этих абстрактных достаточно методов, и нет прямой зависимости от класса, который реально реализует эти методы, что удобно для замены и изменения логики реализации в будущем;
Принцип разделения интерфейсов (ISP):При разработке абстрактного класса он должен быть упрощенным и единым.На просторечии А должен полагаться на некоторые методы, предоставляемые Б. Я использую только 3 метода Б, и Б постарается не давать методы, которые А не может использовать;
Закон Деметры (LoD)Уменьшите связанность и сведите к минимуму прямое взаимодействие между объектами.Если одному из классов необходимо вызвать метод другого класса, вызов можно инициировать через класс отношений, чтобы при изменении модуля влияние можно было свести к минимуму.
Принцип открытия-закрытия (OCP)Скажи открыть для расширения и закрыть для модификации Ты можешь унаследовать и расширить все мои способности В твоих руках ты можешь изменить что хочешь, но меня не трогай, ладно? Ok
23 шаблона проектирования суммируются на основе 6 основных принципов, указанных выше, в сочетании с конкретными методами разработки. Все изменения неотделимы от оригинала. С учетом этих основных норм осознания то, что вы пишете, может быть определенным шаблоном проектирования ٩(๑>◡
решение
Режим состояния:Позволяя объекту изменять свое поведение при изменении его внутреннего состояния, создается впечатление, что объект изменяет свой класс.
Давайте сначала посмотрим на модифицированный код, используя режим состояния:
class Contra {
constructor () {
//存储当前待执行的动作 们
this._currentstate = {};
}
//添加动作
changeState (){
//清空当前的动作集合
this._currentstate = {};
//遍历添加动作
Object.keys(arguments).forEach(
(i) => this._currentstate[arguments[i]] = true
)
return this;
}
//执行动作
contraGo (){
//当前动作集合中的动作依次执行
Object.keys(this._currentstate).forEach(
(k) => Actions[k] && Actions[k].apply(this)
)
return this;
}
};
const Actions = {
up : function(){
//向上跳
console.log('up');
},
down : function(){
//趴下
console.log('down');
},
forward : function(){
//向前跑
console.log('forward');
},
backward : function(){
//往老家跑
console.log('backward');
},
shoot : function(){
//开枪吧
console.log('shoot');
},
};
var littlered = new Contra();
littlered.changeState('shoot','up').contraGo();
скопировать кодКонсоль выдаст: стрелять
Решения:
Режим состояния преобразует результат условного суждения во внутреннее состояние объекта состояния (вверх, вниз, назад, вперед в коде).Внутреннее состояние обычно используется как частная переменная (this._currentState) внутри объекта состояния. , а затем предоставляет состояние, которое можно вызвать.Объект метода интерфейса (changeState, contraGo) внутреннего состояния объекта, так что изменение состояния и модификация и добавление вызова метода состояния также очень easy, что облегчает управление внутренним состоянием в объекте состояния.
В то же время шаблон состояния помещает каждую условную ветвь в отдельный класс, который в коде является Actions. Это позволяет использовать состояние объекта (действие - вверх, вниз, назад, вперед) как объекта (Действия.вверх, Действия.вниз и т.д.) по самому объекту, который может быть независимым от других объектов. Изменение (одно поведение, одно действие, не мешая друг другу).
Видно, что режим состояния — это режим проектирования, подходящий для различных сценариев состояния.После перезаписи код становится более четким, а ремонтопригодность и масштабируемость кода улучшаются.
Сценарии использования режима состояния:
-
Объект, который имеет различное поведение, вызванное одним или несколькими динамически изменяющимися свойствами.При взаимодействии с внешними событиями его внутреннее состояние будет меняться, так что поведение системы также изменится.Тогда этот объект является объектом с состоянием
-
Код содержит большое количество условных операторов, связанных с состоянием объекта, таких как операторы if else или switch case, и выполнение этих условий зависит от состояния объекта.
Если сцена удовлетворяет двум вышеуказанным условиям, то мы можем представить, может ли паттерн состояний помочь
Преимущества и недостатки государственного шаблона:
преимущество:
-
Поведение, соответствующее состоянию, инкапсулировано в класс, который является более интуитивным и понятным, и его легко добавлять и изменять.
-
Состояние и состояние, поведение и поведение независимы друг от друга и не мешают друг другу
-
Избегайте постоянного расширения самого объекта и слишком большого количества условных суждений.
-
Каждый раз, когда вы выполняете действие, вам не нужно повторять множество ненужных суждений, какое из них использовать.
недостаток:
-
Необходимо разделять разные состояния вещей и соответствующие им поведения. Иногда очень тонкое разделение неизбежно. Иногда это требует бизнес-логики. Одно действие разбивается на два соответствующих состояния, и действие не понимается.
-
Вещи определенно увеличат количество классов и действий класса, действий класса, а иногда и дольше, основанных на едином принципе, разделенных на несколько категорий в соответствии с функцией, но сделают код путаным, уменьшит читабельность
Пример сценария режима состояния
Шаблоны состояний в разработке компонентов — навигация
Когда мы обычно разрабатываем компоненты, нам часто нужно переключать состояние компонента.Каждое состояние имеет разные методы обработки.В это время мы можем использовать режим состояния для разработки.
Используя ту же идею, что и выше, давайте возьмем небольшой пример компонента React, такого как навигация по баннеру, самые основные два состояния, показать и скрыть, следующие:
const States = {
"show": function () {
console.log("banner展现状态，点击关闭");
this.setState({
currentState: "hide"
})
},
"hide": function () {
console.log("banner关闭状态，点击展现");
this.setState({
currentState: "show"
})
}
};
скопировать кодАналогично, объект States используется для определения состояния баннера.Есть два состояния show и hide, которые имеют соответствующие методы обработки соответственно.После вызова текущий баннер перезаписывается в другое состояние. Далее давайте посмотрим на класс навигации Banner:
class Banner extends Component{
constructor(props) {
super(props);
this.state = {
currentState: "hide"
}
this.toggle = this.toggle.bind(this);
}
toggle () {
const s = this.state.currentState;
States[s] && States[s].apply(this);
}
render() {
const { currentState } = this.state;
return (
<div className="banner" onClick={this.toggle}>
</div>
);
}
};
export default Banner;
скопировать кодЭтот класс имеет метод навигации для состояния коммутации Toggle, затем вызывает соответствующий метод обработки.
Если есть третье состояние, нам нужны только состояния, чтобы добавить соответствующее состояние и обработчик.
Классический пример — светофоры
Все понимают основные функции светофора.Вот, вставьте код напрямую, чтобы добиться той же идеи, а затем измените способ написания:
var trafficLight = (function () {
var currentLight = null;
return {
change: function (light) {
currentLight = light;
currentLight.go();
}
}
})();
function RedLight() { }
RedLight.prototype.go = function () {
console.log("this is red light");
}
function GreenLight() { }
GreenLight.prototype.go = function () {
console.log("this is green light");
}
function YellowLight() { }
YellowLight.prototype.go = function () {
console.log("this is yellow light");
}
trafficLight.change(new RedLight());
trafficLight.change(new YellowLight());
скопировать кодtrafficLight — это экземпляр светофора. В него передается конструктор. Объект предоставляет метод change для изменения внутреннего состояния, то есть цвета света. Change получает тот же объект состояния, а метод объекта вызывается для запуска ответного действия.Здесь все действия называются go, световые объекты разных цветов имеют разные реализации go.
При передаче объекта light методу change состояние светофора изменяется и запускается соответствующий обработчик, что является типичным применением шаблона состояния.
Из приведенных выше трех примеров мы можем почувствовать, что код, использующий режим состояния, имеет ту же структуру кода и ту же функцию.
Эти сценарии на самом деле могут быть представлены общей моделью, «конечным автоматом».
Конечный автомат
Это модель модели состояния.В повседневной разработке многие объекты с несколькими состояниями могут быть смоделированы с помощью модели конечного автомата.Как правило, они имеют следующие характеристики:
-
Вещи имеют несколько состояний, и в любое время они будут только в одном состоянии, а не в нескольких состояниях;
-
Действия могут изменить состояние вещей. О действии можно судить по условиям, чтобы перевести вещи в разные состояния, но оно не может указывать на несколько состояний одновременно. Один раз, только одно состояние, только одно. (Некоторые здесь могут усомниться в приведенном выше примере Contra. Почему Сяохун и Сяолань могут прыгать и стрелять одновременно? Разве это не два состояния одновременно? " и "стрельба" вместе определяют состояние "прыжки и стрельба". Общее состояние персонажей - это на самом деле расположение и комбинация поведений, которые могут происходить одновременно. Комбинация не организована, потому что прыжки и стрельба и стрельба прыжки Должно быть то же, так еще состояние, а)
-
Общее количество состояний ограничено;
Поскольку все, что соответствует приведенным выше сценариям, может быть описано моделью конечного автомата, можем ли мы абстрагировать эту модель и реализовать различные процессы состояния, передавая параметры, без необходимости каждый раз писать этот процесс заново?
На гитхабе есть одинФункциональная библиотека для конечных автоматов, зайди и узнай
Библиотека конечных автоматов Javascript Конечный автомат
инструкции
Введение автора на github очень подробное, https://github.com/jakesgordon/javascript-state-machine, здесь я просто расскажу о лени.
Создайте конечный автомат классического примера светофора, посмотрите, хорошо ли я отреагирую на текст хахахахаха:
const StateMachine = require('javascript-state-machine');
var fsm = new StateMachine({
init: 'green',
transitions: [
{ name: 'warn', from: 'green', to: 'yellow' },
{ name: 'panic', from: 'yellow', to: 'red' },
{ name: 'calm', from: 'red', to: 'yellow' },
{ name: 'clear', from: 'yellow', to: 'green' }
]，
methods: {
onWarn: function() {},
onBeforeWarn: function() {},
onLeaveWarn: function() {},
onEnterYellow: function() {},
onLeaveYellow: function() {},
//...
}
})
скопировать кодАтрибут init начального состояния светофора имеет зеленый цвет, а trainstions — это массив для описания правил изменения состояния, каждый элемент — это объект, который можно понимать как описание правила:
-
форма: из какого состояния исходит текущее поведение
-
to: в какое состояние перейдет текущее поведение после выполнения
-
name: название текущего поведения
После того, как экземпляр сгенерирован, получаем состояние текущего объекта конечного автомата fsm:
fsm.state
скопировать кодНесколько методов перехода для изменения состояния конечного автомата
fsm.warn()
fsm.panic()
fsm.calm()
fsm.clear()
скопировать кодВ то же время государственная машина предоставляет ряд инструментов и методов
fsm.is(s) - return true 如果当前状态机状态为 s
fsm.can(t) - return true 如果过渡方法t可以从当前状态触发
fsm.cannot(t) - return true 如果当前状态下不能发生过渡方法t
fsm.transitions() - 返回从当前状态可以过渡到的状态的列表
fsm.allTransitions() - 返回所有过渡方法的列表
fsm.allStates() - 返回状态机有的所有状态的列表
скопировать кодПеречислены методы жизненного цикла, а жизненный цикл изменений будет выполняться в следующем порядке:
//注意，STATE是当前状态机所处的状态，TRANSITION是即将发生的动作
onBeforeTransition 任何动作触发前触发
onBefore<TRANSITION> 在特定动作TRANSITION前触发
onLeaveState 离开任何一个状态的时候触发
onLeave<STATE> 在离开特定状态STATE时触发
onTransition 在任何动作发生期间触发
onEnterState 当进入任何状态时触发
onEnter<STATE> 进入一个特定的状态STATE时触发
on<STATE> onEnter<STATE>的简写
onAfterTransition 任何动作触发后触发
onAfter<TRANSITION> 在特定动作TRANSITION后触发
on<TRANSITION> onAfter<TRANSITION>的简写
скопировать кодВ сочетании с методом цикла объявления объясните методы в атрибуте методов в приведенном выше примере:
methods: {
onWarn: function() {},//在warn动作发生时触发
onBeforeWarn: function() {},//在warn动作要发生时触发
onLeaveWarn: function() {},//在warn动作发生后触发
onEnterYellow: function() {},//在变成黄灯状态时触发
onLeaveYellow: function() {},//在离开黄灯状态时触发
}
скопировать кодЕсли нужно отслеживать время жизненного цикла, нам нужно объявить его в методах и передать в соответствующей операции
Кроме того, эта библиотека функций также поддерживает множество мощных функций, таких как асинхронность, отказоустойчивость и т. д. Конкретное использование очень хорошо написано автором на github, поэтому я не буду здесь многословен.
лень - это...
Анализ исходного кода
Свет не будет работать, вниз исходный код, давайте посмотрим на библиотеку функций этой чрезвычайно загруженной модели конечного автомата, каков процесс?
Согласно вышеуказанному примеру, давайте перейдем к исходному коду, чтобы увидеть, что происходит:
var fsm = new StateMachine({
init: 'green',
transitions: [
{ name: 'warn', from: 'green', to: 'yellow' },
{ name: 'panic', from: 'yellow', to: 'red' },
{ name: 'calm', from: 'red', to: 'yellow' },
{ name: 'clear', from: 'yellow', to: 'green' }
]
})
скопировать кодСначала посмотрите на эту часть, процесс создания экземпляра конечного автомата StateMachine в конструкторе StateMachine:
function StateMachine(options) {
return apply(this || {}, options);//--下面进入这个方法里--
}
//下面是StateMachine的一些基础设置
StateMachine.version = '3.0.1';
StateMachine.factory = factory;
StateMachine.apply = apply;
StateMachine.defaults = {
wildcard: '*',
init: {
name: 'init',
from: 'none'
}
}
скопировать кодoptions — это объект инициализации конечного автомата, который мы передали:
{
init: 'green',
transitions: [
{ name: 'warn', from: 'green', to: 'yellow' },
{ name: 'panic', from: 'yellow', to: 'red' },
{ name: 'calm', from: 'red', to: 'yellow' },
{ name: 'clear', from: 'yellow', to: 'green' }
]
}
скопировать кодПользовательский метод применения, передаваемый в контексте текущего конечного автомата и указанного выше объекта данных инициализации:
function apply(instance, options) {
var config = new Config(options, StateMachine);//--下面进入这个方法里--
build(instance, config);
instance._fsm();
return instance;
}
скопировать кодConfig входными параметрами являются данные инициализации и метод конструктора StateMachine:
function Config(options, StateMachine) {
options = options || {};
this.options = options; //初始化配置
this.defaults = StateMachine.defaults; //状态机的基本设置
this.states = []; //状态列表
this.transitions = []; //过渡动作列表
this.map = {}; //状态和动作的映射
//-------------------------------------
this.lifecycle = this.configureLifecycle();
this.configureTransitions(options.transitions || []);
//------------------------------------停，我们看上面两行代码做了什么
this.init = this.configureInitTransition(options.init);
this.map[this.defaults.wildcard] = {};
this.data = this.configureData(options.data);
this.methods = this.configureMethods(options.methods);
}
//mixin函数就是将接收到的除第一个之外的参数对象上的属性拷贝到第一个对象上
mixin(Config.prototype, {
//主要是初始化构造状态机一些属性的工具方法，具体实现这里不做展示
addState: function(name) {},
addStateLifecycleNames: function(name) {},
addTransition: function(name) {},
addTransitionLifecycleNames: function(name) {},
mapTransition: function(transition) {},
//......
});
module.exports = Config;
скопировать кодThis.lifecycle хранит несколько значений времени, которые необходимо отслеживать в основном жизненном цикле конечного автомата, а именно: on, onBefore, onAfter, onEnter, onLeave.
Время, относящееся к поведению TRAISITION - onBefore (до возникновения поведения), onAfter (после возникновения поведения)
Время, которое принадлежит состоянию STATE - onEnter (перед входом в состояние), onLeave (перед выходом из состояния)
Момент, принадлежащий и состоянию, и действию — на
this.configureLifecycle() определяет базовую структуру жизненного цикла, а this.configureTransitions() регистрирует метод жизненного цикла времени отклика для каждого состояния и действия конечного автомата.
Давайте посмотрим на жизненный цикл после завершения инициализации, и все поймут Сравните все функции жизненного цикла, перечисленные в приведенном выше использовании, чтобы понять
Ну тогда вернитесь в Config и посмотрите вниз
function Config(options, StateMachine) {
//...省略上面
this.init = this.configureInitTransition(options.init);
this.map[this.defaults.wildcard] = {};
//------------------------------------停，我们看这两行代码做了什么
this.data = this.configureData(options.data);//传入初始化的一些数据，本例中没有，返回{}
this.methods = this.configureMethods(options.methods);//传入自定义的一些数据，本例中没有，返回{}
}
скопировать кодThis.map хранит список действий, соответствующих всем объектам в машине состояний, что можно понимать как Actions in Contra, но здесь состояние соответствует не поведению, а объекту, и этот объект содержит все состояния Имя действия, которое может быть запущено. Значение, соответствующее имени, является описанием перехода, который происходит, когда происходит действие:
name — поведение, которое должно произойти, to — состояние, в которое происходит переход после возникновения поведения, active — поведение, которое должно произойти в текущем автомате
Мы видим, что none — это не данные, которые мы инициализируем и регистрируем, и init — это не поведение нашей регистрации.
На самом деле реальное начальное состояние конечного автомата по умолчанию — несуществующее «none», а поведение, соответствующее переходу из этого состояния в реальное состояние инициализации (зеленый цвет), — это метод init внутри конечного автомата.
Конечный автомат теперь собирается перейти из "none" в начальное состояние зеленого цвета, которое мы действительно установили, метод configureInitTransition будет описывать объект описания поведения, которое должно произойти с текущим конечным автоматом {name: "init", from: " none", to: "green" ", active: true} возвращает this.init
this.map[this.defaults.wildcard] = {}Зарегистрируйте произвольное состояние на карте *, вернитесь к приведенному выше коду, чтобы увидеть последние два предложения конфигурации, а затем вернитесь, чтобы применить, чтобы продолжить:
function apply(instance, options) {
//instance是我们的状态机的上下文，options是传入的初始化的数据
var config = new Config(options, StateMachine);
build(instance, config);//进入下面build方法
instance._fsm();
return instance;
}
function build(target, config) {
//这里只列举了核心代码
mixin(target, PublicMethods);//PublichMethods是用法中状态机提供给我们的工具方法is,can,cannot......
mixin(target, config.methods);//config.methods是上面列举的状态机内部的工具方法
//------------------------------------
config.allTransitions().forEach(function(transition) {
target[camelize(transition)] = function() {
return this._fsm.fire(transition, [].slice.call(arguments))
}
});
//------------------------------------看下这段代码
target._fsm = function() {
this._fsm = new JSM(this, config);
this._fsm.init(arguments);
}
}
скопировать кодconfig.allTransitions() — это список всех имен поведения конечного автомата ["init", "теплый", "паника", "спокойный", "очистить"], пройдите этот массив и зарегистрируйте поведение как метод на Государственный аппарат
Возвращаемое значение этих методов — это this._fsm.fire, о котором мы поговорим позже, вернемся к сборке:
function build(target, config) {
//省略上面
target._fsm = function() {
this._fsm = new JSM(this, config);
this._fsm.init(arguments);
}
}
скопировать кодЗарегистрируйте метод fsm для конечного автомата.После выполнения сборки вернитесь к применению и начните выполнение метода fsm:
function apply(instance, options) {
//省略上面
instance._fsm();//开始执行_fsm（）
return instance;
}
скопировать кодМетод fsm this.fsm = new JSM(this, config) сначала создает экземпляр JSM реального конечного автомата.
function JSM(context, config) {
this.context = context;
this.config = config; //上面config初始化的一堆数据
this.state = config.init.from; //none
this.observers = [context];
}
mixin(JSM.prototype, {
//省略实现细节，用到的下面会详细说
init: function(args) {},
is: function(state) {},
isPending: function() {},
can: function(transition) {},
allTransitions: function() {},
transitions: function() {},
seek: function(transition, args) {},
fire: function(transition, args) {},
//......
});
module.exports = JSM;
скопировать кодВернемся к методу fsm, следующим шагом будет настоящая функция инициализации, this.fsm.init(arguments)
mixin(JSM.prototype, {
//...上面定义的一堆方法
init: function(args) {
//只贴核心代码
if (this.config.init.active)
return this.fire(this.config.init.name, []);//----进入下面fire方法
},
fire: function(transition, args) {
return this.transit(transition, this.state, this.seek(transition, args), args);
//-----seek方法就是返回this.map[this.state][transition].to,就是当前状态none中的当前要发生行为init的行为描述中该行为过渡到的下一个状态，对照下上面的this.map,这里返回的是green
//进入下面transit方法
},
transit: function(transition, from, to, args) {
//只贴核心代码
var lifecycle = this.config.lifecycle;
this.beginTransit();//方法就是将this.pending置为true，表示状态机执行中
args.unshift({
transition: transition,
from: from,
to: to,
fsm: this.context
});
//------------------------------------
return this.observeEvents([
this.observersForEvent(lifecycle.onBefore.transition),
this.observersForEvent(lifecycle.onBefore[transition]),
this.observersForEvent(lifecycle.onLeave.state),
this.observersForEvent(lifecycle.onLeave[from]),
this.observersForEvent(lifecycle.on.transition),
[ 'doTransit', [ this ] ],
this.observersForEvent(lifecycle.onEnter.state),
this.observersForEvent(lifecycle.onEnter[to]),
this.observersForEvent(lifecycle.on[to]),
this.observersForEvent(lifecycle.onAfter.transition),
this.observersForEvent(lifecycle.onAfter[transition]),
this.observersForEvent(lifecycle.on[transition])
], args);
//------------------------------------看下这段代码
},
//...下面定义的一堆方法
}
скопировать кодМетодObserversForEvent возвращает массив, первый объект — это имя функции жизненного цикла, соответствующей текущему действию.
Второй параметр — это массив, каждый элемент представляет собой конечный автомат, в котором зарегистрирован этот метод жизненного цикла. В более сложных сценариях с несколькими конечными автоматами будет возвращен массив с длиной больше единицы. В этом примере нам нужно только обратите внимание на длину массива 0 То же, что и 1, 0 означает, что текущий конечный автомат данного метода жизненного цикла не зарегистрирован и не нуждается в выполнении, 1 означает, что конечный автомат зарегистрирован, тогда конечный автомат возвращается в массив как первый элемент массива
Третий параметр истинен, и методObserversForEvent не будет слишком заморачиваться.Посмотрим на входные параметры, которые на самом деле получаетobservEvents:
events:
Потому что, когда мы инициализировали конечный автомат, не было прописано ни одного метода, поэтому все методы onXXX, второй параметр — пустой массив, а метод doTransit особенный, его нужно выполнять по умолчанию для перехода состояния, поэтому его второй параметр — это массив длины один, содержащий текущий конечный автомат
args построены в приведенном выше коде:
-
mixin
(JSM.
prototype,
{
-
//...上面定义的一堆方法
-
observeEvents
: function
(events,
args， previousEvent
, previousResult
) {
-
//贴核心代码
-
var event
= events[
0][0
],
-
-
args
[0].
event =
event;
-
-
if (
observers.length
=== 0
) {
-
//如果这个生命周期方法该状态机没有注册，不用执行，执行下一个方法去
-
events
.shift();
-
return this
.observeEvents(
events, args
, event
, previousResult
);
-
}
-
else {
-
//敲黑板了，只有doTransit方法进来了
-
var observer =
observers.shift
(),
-
result
= observer[
event].apply
(observer,
args);
-
//上面这句是为了把args作为第二个参数传入doTransit方法并执行，看下面doTransit方法
скопировать кодПриведенные выше два предложения будут напрямую перезаписывать 0-й элемент, выполняемый в настоящее время в массиве событий, список конечного автомата очищается, третий параметр возвращает неопределенное значение, а текущее событие становится ["doTransit", Array(0)]
if (result && typeof result.then === 'function') {
//注册的方法返回一个promise的情况
return result.then(this.observeEvents.bind(this, events, args, event)).catch(this.failTransit.bind(this))
}
else if (result === false) {
//执行完毕或者中途执行出错返回false
return this.endTransit(false);
}
else {
//影响不只一个状态机时，当前状态机从第二个参数里删掉，继续执行下一个状态机里这个方法
return this.observeEvents(events, args, event, result);
}
}
},
doTransit: function(lifecycle) { this.state = lifecycle.to; //状态机过渡到下一个状态},
//...下面定义的一堆方法
}
скопировать кодТаким образом, инициализация конечного автомата завершена, мы вручную выполняем действие, чтобы увидеть:
fsm.warn()
скопировать кодКак мы сказали выше, метод действия на самом деле возвращает метод огня:
return this._fsm.fire(transition, [].slice.call(arguments))
скопировать кодТот же процесс, что и вышеприведенный метод инициализации триггера огня, потому что нет зарегистрированного метода слушателя, выполняется только метод doTransit.
Давайте зарегистрируем метод слушателя для выполнения и посмотрим:
var fsm = new StateMachine({
init: 'green',
transitions: [
{ name: 'warn', from: 'green', to: 'yellow' },
{ name: 'panic', from: 'yellow', to: 'red' },
{ name: 'calm', from: 'red', to: 'yellow' },
{ name: 'clear', from: 'yellow', to: 'green' }
],
methods: {
onBeforeWarn: function() { console.log("执行warn,state将变为yellow") },
}
})
fsm.warn();
console.log(fsm.state)
скопировать кодДавайте посмотрим непосредственно на события первого параметра методаObserverEents:
Вывод консоли:
Конечный автомат - это такой основной процесс в целом, очень простой и очень простой пример, желающие понять, студенты могут пойти посмотреть на источник крупного рогатого скота.
Суммировать
Я вижу, что это не так просто, я рухнул, нужно подвести итог, то это не слишком большая проблема, сцены не используют этот конечный автомат библиотеки, они знают, что основная идея состоит в том, чтобы добиться отличного результата, но на самом деле нужно использовать эта функция, если поддерживается библиотечной функцией, очень мощная, вы можете пойти и посмотреть код автора и документацию -
Наконец, при столкновении с большим количеством условий суждения, упомянутых выше, не забудьте подумать о режиме состояния ~