Чи можна сказати, що об’єкти мають атрибути, стани і поведінку?

Я читав вступ Oracle до концепцій OOP, і натрапив на цей опис:

Об'єкти реального світу мають дві характеристики: всі вони мають стан та поведінку. Собаки мають стан (ім’я, колір, породу, голодний) та поведінку (гавкіт, плодоношення, виття хвоста). Програмні об'єкти концептуально схожі на об'єкти реального світу: вони теж складаються із стану та пов'язаної з ними поведінки.

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

Тож, на мою думку, точніше розбити характеристики предметів на три частини: атрибути, стани та поведінку .

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

Але концептуально кажучи, має сенс розділити 3 речі окремо.

Ось ще один приклад: розгляньте лампу. Сказати, що і розмір лампи, і включена чи ні, є станом, на мій погляд. Розмір лампи - це атрибут, а не стан, а ввімкнення або вимкнення - стан.

Або я щось пропустив?

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

Це тричастинне визначення дійсно представлене в мовах програмування, наприклад, використовуючи finalключове слово на Java або readonlyключове слово в C # для позначення даних про екземпляр, які можуть не змінюватися протягом життя примірника.

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

Я думаю, що точніше сказати, що об'єкти мають лише дві характеристики. Беручи приклад Oracle:

Собаки мають стан (ім’я, колір, породу, голодний) та поведінку (гавкіт, плодоношення, виття хвоста). Програмні об'єкти концептуально схожі на об'єкти реального світу: вони теж складаються із стану та пов'язаної з ними поведінки.

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

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

Стан - це набір атрибутів і відповідних значень, тому, з моєї точки зору, ви неправі (і ви створюєте зайву додаткову складність простому визначенню).

Ми можемо класифікувати речі незліченними способами, і кожна класифікація не мала б «правильної відповіді». Класифікація речей є вигідною, лише якщо класифікація призводить до глибшого розуміння або до поліпшення спілкування. Якщо ваша команда вважає за краще використовувати терміни атрибути, стани та функції та має чіткі робочі визначення для цього, це допоможе покращити внутрішню комунікацію, але вам потрібно бути гнучкими при спілкуванні поза цією групою.

Поняття "голодний" і "спраглий" можна вивести з основних ознак (наприклад, рівня глюкози в крові, рівня гідратації), щоб ми могли вважати стан як мета-атрибут, який походить від базових атрибутів, на яких ми можемо переходити до істинного чи помилкового на основі стан відповідних базових атрибутів. Для легкого прикладу ми можемо вважати, що світло має такі атрибути, applied_voltageі resistanceфункції voltage_switch()і shine(). voltage_swich()Є функцією деякого вхідного сигналу (наприклад , ручної перемикач, світло, таймер і т.д.) і shine()є функцією applied_voltageі resistance. Ми могли б оголосити мета-атрибут, який називається light_stateІстинним або Неправдивим, щоб допомогти подумки побудувати об'єкт, але врешті-решт ці ідеї - це лише психічні конструкції, які ми використовуємо для організації своєї роботи.

Стан об’єкта кодується у його атрибутах, прямо чи опосередковано. Наприклад, якщо ви хочете, щоб ваша собака спрагла, то можете дозволити їй мати

private boolean thirsty;

Крім того, ви можете дозволити йому щось подібне

private Date lastDrinkAt;

і зробіть висновок, чи спраглий ваш приклад собаки, порівнявши поточний час з часом, коли він останній раз пив.

Так чи інакше, стан ваших об'єктів лежить в його атрибутах.

Потім є класи, які не мають атрибутів, в основному класи корисності. Але, як правило, не хочеться створювати їх примірник ні в цьому випадку.

Для того, щоб мати можливість міркувати про твердження, вчені зазвичай дотримуються принципу мінімальності. Я думаю, що тому Oracle не згадував про стан держави прямо. Він може бути отриманий із значення атрибутів.

Зв'язки у реальному світі неправильно керуються. Ось як би я навчив цього (підхід c ++):

1. Комп'ютери підтримують два різні формати зберігання даних: код та код
2. дані схожі на біти 010101010101
3. код схожий на інструкції ASM
4. біти даних мають два різних значення - це або 0, або 1
5. дані абстрагуються до типів даних: int i = 1; є лише коротким позначенням деяких бітів 0000001
6. код буде виглядати як функція: int f (int a) {return a + a + a; } є короткими позначеннями для деяких інструкцій asm
7. коли у вас є кілька змінних, ви об'єднуєте їх у структуру: int a; float b; може бути розміщений до структури AB {int a; float b; };
8. комбінуючи до нього деякі фрагменти коду, ви отримуєте клас: клас ABf {int a; float b; float sum (float c) const {return a + b + c; }};
9. Тоді для даних у нас є імена змінних, за допомогою яких можна знайти значення: a + b + c для доступу до даних.
10. І тоді у нас є нормальні виклики функцій: int k = f (10); для доступу до інструкцій Asm, "збережених" всередині f-функції.
11. Потім є екземпляри об'єкта: ABf var;
12. І функція-член викликає: int k2 = var.sum (10.0);
13. функції мають типи int f (int);
14. функції члена мають типи int ABf :: sum (float);
15. Існує цей покажчик типу ABf *
16. такі змінні, як a і b і c, залежать від контексту, якщо вони знаходяться всередині функції члена, вони можуть означати це-> b або просто b.
17. Функції члена int ABf :: sum (float c) - це лише коротке позначення для int sum (ABf * this, float c);
18. слово "стан" просто означає те саме, що і дані
19. слово "поведінка" просто означає те саме, що і код
20. слово "атрибут" просто означає те саме, що і дані.

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