オブジェクト指向プログラムは有限状態マシンとして見ることができますか？

これは哲学的/基本的な質問かもしれませんが、ただ明確にしたいだけです。

私の理解では、有限状態マシンは、システムの出力が現在の入力だけでなく、システムの現在の状態にも依存するシステムをモデル化する方法です。さらに、名前が示唆するように、有限状態マシンは、それぞれの状態と動作を持つ有限のN個の状態にセグメント化できます。

これが正しい場合、データおよび関数メンバーを持つすべてのオブジェクトをオブジェクト指向モデルの状態にして、オブジェクト指向設計を有限状態マシンにするべきではありませんか？

それがオブジェクト設計におけるFSMの解釈ではない場合、ソフトウェアでFSMを実装するとき、人々は正確に何を意味しますか？私は何かが欠けていますか？

ありがとう

有限量のストレージを備えたマシンで実行されているシングルスレッドプログラムは、有限状態マシンとしてモデル化できます。有限状態マシンの特定の状態は、関連するすべてのストレージ（ローカル変数、グローバル変数、ヒープストレージ、仮想メモリで現在スワップアウトされているデータ、関連ファイルの内容など）の特定の値を表します。言い換えれば、非常に些細なプログラムであっても、その有限状態モデルには多くの状態があります。

プログラムが持つ唯一の状態が32ビット整数型の単一のグローバル変数であっても、少なくとも2 ^ 32（40億を超える）状態を意味します。そして、それはプログラムカウンターとコールスタックを考慮していません。

プッシュダウンオートマトンモデルは、この種のものに対してより現実的です。有限オートマトンに似ていますが、スタックの概念が組み込まれています。ただし、ほとんどのプログラミング言語のように、実際には呼び出しスタックではありません。

ウィキペディアの説明がありますが、正式な定義セクションで行き詰まってはいけません。

プッシュダウンオートマトンは、一般的な計算のモデル化に使用されます。チューリングマシンは似ていますが、計算能力は同等ですが、IIRCは同一ではありません。

上記のエラーを指摘してくれたkevin clineに感謝します。Wikipediaも指摘しているように、プッシュダウンオートマトンは有限状態マシンよりも強力ですが、チューリングマシンよりも強力ではありません。

この脳のおならがどこから来た私は正直わかりません-私がやる依存文法は文脈自由よりも強力であり、その文脈依存文法は簡単なプッシュダウンオートマトンを使用して解析することができないという状況を知っています。明確なコンテキストのない文法を線形時間で解析することは可能ですが、それを行うには一般に（決定論的な）プッシュダウンオートマトン以上のものが必要であることさえ知っています。したがって、プッシュダウンオートマトンをチューリングマシンと同等に信じるのは奇妙なことです。

多分追加の機械が追加されたプッシュダウンオートマトンを考えていたかもしれませんが、それはプッシュダウンオートマトンと同等の有限オートマトンを数えるようなものです（スタックを追加して活用するだけです）。

プッシュダウンオートマトンは解析において重要です。私はその文脈でそれらに十分に精通していますが、計算のコンピューター科学モデルとしてそれらを実際に研究したことはないので、私はすでに持っている以上の詳細を与えることはできません。

単一のOOPオブジェクトを有限状態マシンとしてモデル化することは可能です。マシンの状態は、すべてのメンバー変数の状態によって決定されます。通常、有効な状態は、メソッド呼び出しの間（ではない）にのみカウントされます。繰り返しますが、一般的に心配する状態はたくさんあります。これは理論モデルとして使用できるかもしれませんが、ささいな場合を除いて、それらの状態をすべて列挙したくないでしょう。

いくつかのモデル化するために、けれどもそれは、かなり一般的である側面有限状態マシンを使用して、オブジェクトの状態を。一般的なケースは、ゲームオブジェクトのAIです。

これは、プッシュダウンオートマトンモデルを使用してパーサーを定義するときに通常行われることでもあります。状態モデルには有限の状態セットがありますが、これはパーサーの状態の一部のみをモデル化します。追加の情報は、その状態とともに追加の変数に格納されます。これにより、たとえば40億の1整数の状態の問題が解決されます。すべての状態を列挙せず、整数変数を含めるだけです。ある意味ではプッシュダウンオートマトン状態の一部ですが、ダイアグラムに40億個の状態バブルを描画するよりもはるかに管理しやすいアプローチです。

問題は、何かが有限状態機械であるかどうかではありません。有限状態マシンは、何かを1つと考えることができる場合、何かを理解するのに役立つメンタルモデルです。

通常、有限状態機械モデルは、通常の文法やコンピューターの命令シーケンサーなど、状態の数が少ないものに適用されます。

あなたの質問に直接答えるために：ほとんど間違いなくそうです。OOPの正式な数学的理論は、ラムダ計算および/または組み合わせ論理の基本的な機能プログラミング、または通常の古い命令型プログラミングの基本的なチューリングマシンのようには見えません。

詳細については、このstackoverflowの質問を参照してください。

私の推測では、基礎となる数学的理論の欠如が、誰もが「オブジェクト」を見ると「オブジェクト」が何であるかを知っているが、誰も「オブジェクト」を他の人とまったく同じように見ない理由です。

いいえ、実際にはそうではありません。有限状態マシンは通常、現在の状態という1つのデータのみを記憶します。

FSMの典型的なアプリケーションは、字句解析または構文解析です。たとえば、字句解析を行っている場合、現在の状態と入力の値に関して、可能なすべての入力に対するアクションを（通常）かなり簡単にエンコードできます。

たとえば、数値の桁を読み取っているNUMBER状態があるとします。次に読み込む文字が数字の場合、NUMBER状態のままになります。スペースまたはタブの場合、数字を返し、WHITE_SPACE状態、またはその順序の何かに進みます。

現在、典型的なFSM（特にソフトウェアに実装されているFSM）で、FSM自体とFSMを混在させることは技術的に完全には合わない断片になります。たとえば、数字の桁を読み取るときは、最初の桁の位置を頻繁に保存するため、最後に到達したときに数字の値を簡単に計算できます。

FSM自体にはいくつかの制限があります-カウントメカニズムはありません。たとえば、「/ 」を使用してコメントを開始し、「/ 」を使用してコメントを終了する言語を考えてみましょう。そのレクサーは、おそらく「/ 」トークンを見たときに入ったCOMMENT状態になります。この時点では（COMMENT2のような別の状態を追加する以外に）別の「/」を検出し、ネストされたコメントを処理していることを認識する方法はありません。むしろ、コメント状態では、コメント状態*/を終了するように指示するものとして認識され、他のものはコメント状態のままになります。

前述のように、ネストされたコメントにCOMMENT2状態を含めることができます。その中には、COMMENT3状態などが含まれます。ただし、ある時点で、状態を追加することにうんざりして、コメントに許可する最大のネストの深さが決まります。他の形式のパーサー（つまり、純粋なステートマシンではなく、カウントできるメモリを備えたもの）を使用すると、ネストの深さを直接追跡できるため、次のコメントトークンに達するまでコメント状態のままになります。最初のカウンターのバランスをとるため、カウンターは0に戻り、COMMENT状態を終了します。

しかし、私が言ったように、そのようなカウンターを追加するとき、あなたが持っているものはもはやFSMではありません。同時に、あるあなただけのより多くの状態を追加することによって、カウンタをシミュレートできることを具体的には、十分に近い-実際にはかなり近いです。

ただし、典型的なケースでは、誰かがソフトウェアにFSMを実装することについて話すとき、彼らはそれを合理的に「純粋」に保ちます。特に、ソフトウェアは、現在の状態と入力自体の値のみに基づいて、現在の入力に反応します。反応が他の多くのものに依存している場合、彼らは通常それを状態マシンとは呼びません（少なくとも彼らが話していることを知っている場合）。

受け入れられた答えが完全に正しいとは思わない。

オブジェクト指向であろうとなかろうと、チューリング完全言語で書かれた任意のプログラムを有限状態マシンとしてモデル化することはできません。Java、C ++、Smalltalkなど、ほとんどすべての最新のコンピューター言語はチューリング完全です。

たとえば、有限状態マシンは変数にnを書き込むことができないため、1つのオブジェクトのnインスタンスに続いて別のオブジェクトのnインスタンスがあるオブジェクトのシーケンスを認識する有限状態マシンを作成できません。入力を読み取り、状態に切り替えることができるだけです。