Чи може об'єктно-орієнтована програма розглядатися як Кінцева державна машина?

Це може бути філософське / фундаментальне питання, але я просто хочу його уточнити.

На мій погляд, Машина кінцевих станів - це спосіб моделювання системи, при якому вихід системи буде залежати не тільки від поточних входів, але і від поточного стану системи. Крім того, як випливає з назви, машина з кінцевим станом може бути сегментована на кінцеву кількість N станів із відповідним станом та поведінкою.

Якщо це правильно, чи не повинен кожен об'єкт із даними та членами функцій бути станом у нашій об'єктно-орієнтованій моделі, що робить будь-який об'єктно-орієнтований дизайн кінцевою машиною?

Якщо це не інтерпретація FSM в дизайні об'єктів, що саме означають люди під час впровадження FSM в програмне забезпечення? я щось пропускаю?

Спасибі

Будь-яка однопотокова програма, що працює на машині з обмеженою кількістю пам’яті, може бути змодельована як машина з кінцевим станом. Конкретний стан в машині з кінцевим станом буде представляти конкретні значення всіх релевантних сховищ - локальних змінних, глобальних змінних, накопичувального купи, даних, які зараз замінені у віртуальній пам'яті, навіть вмісту відповідних файлів. Іншими словами, у цій кінцевій моделі стану буде багато держав, навіть для досить тривіальних програм.

Навіть якщо єдиний стан, який має ваша програма, - це єдина глобальна змінна 32-бітного цілочисельного типу, що передбачає щонайменше 2 ^ 32 (більше 4 мільярдів) станів. І це навіть не враховуючи лічильник програм та стек викликів.

Модель автоматичного віджимання більш реалістична для подібних речей. Це як кінцевий автомат, але має вбудовану концепцію стека. Це насправді не стек викликів, як у більшості мов програмування.

Існує пояснення у Вікіпедії , але не зациклюйтеся в розділі формального визначення.

Автомати, що висуваються, використовуються для моделювання загальних обчислень. Машини Тьюрінга схожі , але IIRC не є однаковими - хоча їх обчислювальні можливості рівноцінні .

Дякую Кевіну, що вказав на помилку вище - як вказує також Вікіпедія , автоматичні машини, що висуваються, є більш потужними, ніж машини кінцевого стану, але менш потужні, ніж машини Тьюрінга.

Я чесно не знаю , де цей мозок пердеть прийшли - я зробити знаю , що контекст чутливих граматик є більш потужними , ніж контекстно - вільної, і що контекстно - залежні граматики не може бути проаналізований з допомогою простого натискання вниз автомат. Я навіть знаю, що хоча можливо розібрати будь-яку недвозначну без контексту граматику за лінійний час, для цього, як правило, потрібно більше, ніж (детермінований) автоматичний віджимаючий автомат. Тож, як я міг би думати, що автоматичний поштовх є еквівалентним машині Тьюрінга - це химерно.

Можливо, я думав про автоматичний поштовх із доданими додатковими машинами, але це було б, як вважати кінцевий автомат як еквівалентний автоматичному поштовху (просто додайте та використовуйте стек).

Автомати, що висуваються, важливі при аналізі. Я досить добре знайомий з ними в цьому контексті, але я ніколи насправді не вивчав їх як комп'ютерні моделі обчислень, тому не можу дати більше деталей, ніж я вже маю.

Можна моделювати один об'єкт OOP як машину з кінцевим станом. Стан машини визначатиметься станами всіх змінних членів. Зазвичай ви підраховуєте лише дійсні стани між (не під час) викликами методу. Знову ж таки, у вас, як правило, буде багато турбуватися про стан - це те, що ви можете використовувати як теоретичну модель, але ви не хотіли б перераховувати всі ці стани, за винятком, можливо, у тривіальному випадку.

Однак досить поширене моделювання деякого аспекту стану об'єкта за допомогою машини з кінцевим станом. Поширений випадок - AI для ігрових об'єктів.

Це також те, що зазвичай робиться при визначенні аналізатора за допомогою моделі автоматичного розгортання. Хоча в моделі стану є кінцевий набір станів, це лише модель моделі стану аналізатора - додаткова інформація зберігається в додаткових змінних поряд із цим станом. Це вирішує, наприклад, питання про 4 мільярди станів для цілого числа - не перераховуйте всі ці стани, просто включіть цілу змінну. У певному сенсі це все ще є частиною стану автоматичного висувного автоматичного пристрою, але це набагато більш керований підхід, ніж фактично малювання 4 мільярдів бульбашок стану на діаграмі.

Справа не в тому, чи є щось "є" чи "не" машина з кінцевим станом. Кінцева машина стану - це розумова модель, яка може бути корисною для розуміння чогось, якщо цю річ можна розглядати як єдину.

Зазвичай модель машини кінцевого стану застосовується до речей з невеликою кількістю станів, таких як звичайна граматика або секвенсор інструкцій комп'ютера.

Відповісти прямо на ваше запитання: майже точно не. Очевидно, що для OOP не існує формальної математичної теорії про те, як обчислення лямбда та / або комбінаторна логіка є недостатньо функціональним програмуванням, або машини Тьюрінга - це звичайне старе імперативне програмування.

Дивіться це запитання про stackoverflow для отримання додаткової інформації.

Я здогадуюсь, що відсутність основної математичної теорії є причиною, коли всі знають, що таке "об'єкт", коли бачать його, але ніхто не бачить "об'єктів" так само, як ніхто інший.

Ні, практично ніяк. Машина з кінцевим станом зазвичай запам'ятовує лише одну частину даних: її поточний стан.

Типовим застосуванням FSM є лексинг або розбір. Наприклад, коли ми робимо лексинг, кодування дій для кожного можливого введення з точки зору поточного стану та значення введення досить (як правило) досить просто.

Наприклад, у нас може бути стан НОМЕРА, в якому ми читаємо цифри числа. Якщо наступним символом, який ми читаємо, є цифра, ми залишаємось у стані НОМЕРА. Якщо це пробіл або вкладка, ми повертаємо цифри, а потім переходимо до певного стану WHITE_SPACE або чогось у цьому порядку.

Тепер, безумовно, вірно, що в типовому FSM (особливо в реалізованому в програмному забезпеченні) ми закінчуємо шматочками та фрагментами, які технічно не зовсім підходять до FSM, змішаного із самим FSM. Наприклад, коли ми читаємо цифри числа, ви часто збираєтеся зберігати позицію першої цифри, тому, добираючись до кінця, ви можете легко обчислити значення числа.

Сама ФДМ має деякі обмеження - у неї немає механізму підрахунку. Розглянемо, наприклад, мову, яка використовувала "/ " для початку коментаря та " /" для завершення коментаря. Його лексер, ймовірно, мав би стан коментаря, який він увійшов, побачивши маркер '/ '. У цей момент немає можливості (крім додавання іншого стану, такого як COMMENT2), щоб виявити інше "/ " і зрозуміти, що він має справу з вкладеним коментарем. Швидше, у стані коментаря, він визнає */, що говорить йому залишити стан коментаря, а все інше залишить його у стані коментаря.

Як згадувалося, ви, безумовно, можете включити стан COMMENT2 для вкладеного коментаря - і в цьому, стан COMMENT3 тощо. Однак у якийсь момент вам не вистачить додати більше станів, і це визначить максимальну глибину введення, яку ви можете додати до коментарів. За допомогою іншої форми аналізатора (тобто, не чистого стану машини, але щось, що має деяку пам’ять, щоб він міг рахувати), ви можете просто відстежувати глибину гніздування безпосередньо, тому ви залишаєтесь у стані КОМЕНТАРУ, поки не досягнете ознайомлення з тим, врівноважує перший, тож ваш лічильник повертається до 0, і ви залишаєте стан COMMENT.

Як я вже сказав, коли ви додаєте подібний лічильник, те, що у вас є, вже не є дійсно FSM. У той же час, вона є на самому ділі досить близько - в Зокрема, досить близько , що ви можете моделювати лічильник, просто додавши більше держав.

У типовому випадку, однак, коли хто - небудь говорить про реалізацію FSM в програмному забезпеченні, вони будуть тримати його досить «чистий». Зокрема, програмне забезпечення буде реагувати на поточний вхід на основі лише поточного стану та значення самого введення. Якщо реакція залежить від багато чого іншого, вони зазвичай не називатимуть це державною машиною (принаймні, якщо вони знають, про що говорять).

Я не вважаю, що прийнята відповідь є абсолютно правильною.

Ви не можете моделювати довільну програму, написану мовою Turing Complete, незалежно від того, об'єктно-орієнтована вона чи ні, як Машина кінцевих держав. Майже всі сучасні комп'ютерні мови, такі як Java, C ++ або Smalltalk, є Turing Complete.

Наприклад, ви не можете створити Кінцеву машину стану, щоб розпізнати послідовність об'єктів, де у вас є n екземплярів одного об'єкта, а потім n екземплярів іншого об'єкта, оскільки Кінцеві автомати стану не можуть записати n до змінної. Вони можуть лише зчитувати вхід і переходити у стан.