Термін " стан " може вживатися в різних сенсах, які навіть не можуть сприйняти точне визначення. Тому важливо було включити визначення у свій документ, щоб зрозуміти, як ви використовуєте цей термін. Далі я не пропоную унікального визначення стану об’єкта, а намагаюся накреслити кілька способів його роздуму, які можуть бути доречними в різних контекстах.
Перш за все, вам потрібно подумати, що ви маєте на увазі під « об’єктом »: чи думаєте ви про понятійний об’єкт, тобто про якусь сутність, яку ви намагаєтеся моделювати, або про екземпляр класу в певній програмі; можливо, ви також хочете подумати про стан змінної, яка могла б у різний час посилатися на різні об'єкти або про систему, може бути, як отримати доступ через певний користувальницький інтерфейс.
Частина труднощів у визначенні стану об'єкта в ООП полягає в тому, що, коли ми моделюємо сутності певною мовою, ця мова часто не дозволяє нам відрізняти атрибути об'єктів, які концептуально є частиною тієї ж сутності від інших, які не є. Наприклад, зв'язаний список Carскладатиметься з ряду Link-об'єктів, які містять вказівники на наступний (а може і попередній), Linkхоча концептуально цей список є єдиним об'єктом; посилання також можуть бути вбудованіCar-об'єкти або містять вказівники на них, але в цьому випадку пов'язані об'єкти є концептуально окремими, а не частиною списку; у списку останніх змін, все-таки, зміни можуть бути присутніми лише у списку та вважатись їх частиною. У цих різних випадках ми маємо вирішити, чи вважаємо ми стан одного об’єкта таким, що стосується пов'язаних об'єктів. Крім того, Carможе бути посилання на Registering_Authority- ми, мабуть, не вважаємо, що стан автомобіля може змінюватися, коли його реєстраційний орган змінює URL-адресу свого веб-сайту. Якщо мова реалізації не дозволить нам розрізнити різні типи зв’язків, неможливо зробити загальне визначення стану об’єкта лише з точки зору мови.
" Зовнішній " або " функціональний " стан можна визначити як "як він поводиться", наприклад як він реагує на виклики методу або на користувальницький інтерфейс. Для об'єкта як екземпляра класу це визначення залежить від типу, до якого об'єкт сприймається як належний: бачив як a Circle, колір аColoured_Circleне видно, а значить, не має значення для його стану. Складність з цим полягає в тому, що "як він реагує" може знадобитися визначити значення повернених значень, і ці "значення" можуть бути станами інших об'єктів. Один із способів формалізувати це - сказати, що два стани об’єкта однакові, якщо всі можливі майбутні виконання якоїсь системи, в яку він вбудований, призводять до того ж відображення від входів до цієї системи до виходів з неї. Ця система, що охоплює, може вимагати бути автономною системою, здатною виконувати незалежно від її оточення; з іншого боку, можна дозволити його бути таким же маленьким, як і сам предмет, про який йде мова. У будь-якому випадку математичним підходом є визначення стану як класу еквівалентності
" Внутрішній " стан можна визначити як стан представництва. Перша спроба, мабуть, кругла, але може бути корисною: "Внутрішній стан об'єкта - це стан його членів". Тут нам потрібно подбати про те, щоб відрізнити суттєві аспекти подання від незначних: на найнижчому рівні представлення об'єкта цілком може включати адреси інших об'єктів, але навряд чи буде корисно розглянути зміну такої адреси як зміна стану. З іншого боку, зміна стану кешу результату запиту, хоча воно не має значення для функціонального стану (як описано вище), буде важливим при розгляді тестів на ефективність.