「状態」という用語は、さまざまな意味で使用されている可能性があり、正確な定義の影響を受けにくい場合もあります。したがって、用語の使い方を明確にするために、論文に定義を含めることが重要でした。以下では、オブジェクトの状態の一意の定義を提供するのではなく、さまざまな状況で適切である可能性がある、オブジェクトについてのさまざまな考え方をスケッチしてみます。
ただし、最初に、「オブジェクト」の意味を考える必要があります。概念的なオブジェクト、つまり、モデル化しようとしているエンティティ、または特定のプログラムのクラスのインスタンスについて考えていますか。おそらく、特定のユーザーインターフェイスを介してアクセスされたときに、さまざまなオブジェクトまたはシステムを参照する可能性のある変数の状態についても考えたいと思います。
OOPでオブジェクトの状態を定義する際の難しさの1つは、特定の言語でエンティティをモデル化する場合、その言語では、同じエンティティの概念上一部であるオブジェクト属性とそうでない他のオブジェクト属性を区別できないことが多いことです。たとえば、リストのリンクされたリストは、次の（場合によっては前の）へのポインタを含むCar多数の- Linkオブジェクトで構成されますが、Link概念的にはリストは単一のオブジェクトです。リンクはまたに埋め込まれるかもしれませんCar-objectsまたはそれらへのポインタを含むが、この場合、リンクされたオブジェクトはリストの一部ではなく概念的に分離されています。ただし、最近の変更のリストでは、変更はリストにのみ存在し、その一部と見なされる場合があります。これらのさまざまなケースでは、リンクされたオブジェクトの状態を含むように1つのオブジェクトの状態を考慮するかどうかを決定する必要があります。さらに、a CarへのリンクがあるRegistering_Authority場合があります。登録機関がWebサイトのURLを変更しても、車の状態が変化するとは考えていません。実装言語でさまざまな種類のリンクを区別できない限り、オブジェクトの状態を言語だけで一般的に定義することはできません。
「external」または「functional」状態は、「動作」として定義できます。メソッドの呼び出しやユーザーインターフェイスに対する反応。見られる：クラスのインスタンスとしてオブジェクトのこの定義は、オブジェクトが属すると見されたタイプに依存しCircle、Aの色Coloured_Circle見えないため、その状態とは無関係です。これの問題は、「どのように反応するか」が、返される値に関して定義する必要があり、これらの「値」が他のオブジェクトの状態である可能性があることです。これを形式化する1つの方法は、オブジェクトが埋め込まれているシステムの将来のすべての実行が、入力からそのシステムへの出力からオブジェクトへの出力への同じマッピングになる場合、オブジェクトの2つの状態は同じであると言うことです。この囲い込みシステムは、その環境に関係なく実行できる自己完結型システムである必要がある場合があります。一方、問題のオブジェクト自体と同じくらい小さくすることもできます。いずれの場合でも、数学的アプローチは、状態を等価クラスとして定義することです
「内部」状態は、表現の状態として定義することができます。最初の試みは、明らかに循環的ですが、おそらく役立つでしょう：「オブジェクトの内部状態は、そのメンバーの状態です」。ここでは、表現の重要な側面と重要でない側面を区別するように注意する必要があります。最下位レベルでは、オブジェクトの表現に他のオブジェクトのアドレスが含まれている可能性がありますが、そのようなアドレスの変更を検討することは役に立ちそうにありません状態の変化として。一方、パフォーマンステストを検討するときは、クエリの結果のキャッシュの状態を変更しても、機能の状態は変化しません（前述のとおり）。