Можем ли мы сказать, что объекты имеют атрибуты, состояния и поведение?

Я читал введение Oracle в концепции ООП и наткнулся на это описание:

Реальные объекты имеют две общие характеристики: все они имеют состояние и поведение. Собаки имеют состояние (имя, окрас, порода, голодные) и поведение (лай, извлечение, вилять хвостом). Программные объекты концептуально похожи на объекты реального мира: они тоже состоят из состояния и связанного поведения.

Моя проблема с этим отрывком в том, что при описании состояния его атрибуты миксов тоже там. Например, имя и цвет собаки - это ее атрибуты, в то время как она голодна или голодна - это ее состояние.

Так что, на мой взгляд, точнее разбить характеристики объектов на три части: атрибуты, состояния и поведение .

Конечно, при переводе этого на язык программирования я вижу, что тройное разделение становится двойным, потому что и атрибуты, и состояния будут храниться в полях / переменных, а поведение - в методах / функциях.

Но с концептуальной точки зрения имеет смысл разделить эти 3 вещи.

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

Или я что-то пропустил?

Вы правы в том, что объекты состоят из атрибутов, состояний и поведения, если вы определяете атрибуты, чтобы обозначать неизменяющиеся характеристики экземпляра. На самом деле, важно проводить это различие, потому что существуют объекты, которые содержат только атрибуты (в вашем смысле) и никакого состояния; они называются неизменяемыми и очень полезны при программировании.

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

Однако я должен добавить, что неизменяемые данные экземпляра обычно не называются атрибутами. Мы склонны говорить о них как о «окончательных», «только для чтения» или «постоянных данных» в зависимости от того, какой язык мы используем. Подходящим термином для них будут «инварианты», но тогда это слово не часто используется в этом смысле; это чаще используется для других вещей.

Я думаю, что более правильно сказать, что объекты имеют только две характеристики. Принимая пример Oracle:

Собаки имеют состояние (имя, окрас, порода, голодные) и поведение (лай, извлечение, вилять хвостом). Программные объекты концептуально похожи на объекты реального мира: они тоже состоят из состояния и связанного поведения.

Тот факт, что значения (состояние) для имени, цвета, породы и голодных хранятся в объекте в атрибутах, является деталью реализации. Вам не нужны атрибуты вообще.

Если вы собираетесь включить атрибуты в качестве третьей характеристики, то вам также необходимо включить методы в качестве четвертой, поскольку поведение объектов (например, состояние) также может изменяться. Состояние и поведение - две абстрактные характеристики объектов. Атрибуты и методы являются конкретными реализациями этих концепций.

State - это набор атрибутов и соответствующих значений, поэтому, с моей точки зрения, вы не правы (и вы создаете ненужную дополнительную сложность для простого определения).

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

Понятия «голодный» и «испытывающий жажду» могут быть получены из базовых атрибутов (например, уровень глюкозы в крови, уровень гидратации), поэтому мы можем думать о состоянии как о мета-атрибуте, который получается из базовых атрибутов, которые мы можем циклически преобразовать в True или False на основе состояние соответствующих базовых атрибутов. Для света , например, мы могли бы думать о свете , как имеющие атрибуты 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; плавать б; может быть помещен в структуру AB {int a; плавать б; };
8. когда вы объединяете в нем несколько фрагментов кода, вы получаете класс: class ABf {int a; плавать б; сумма с плавающей запятой (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. Есть указатель this с типом ABf *
16. переменные типа a и b и c зависят от контекста, если они находятся внутри функции-члена, они могут означать this-> b или просто b.
17. Функции-члены int ABf :: sum (float c) - это просто краткая запись для int sum (ABf * this, float c);
18. Слово «государство» означает то же самое, что и данные.
19. слово «поведение» означает то же самое, что и код
20. Слово «атрибут» означает то же самое, что и данные.

Так что между состоянием и атрибутом нет ничего особенного. Это просто случайная коллекция битов. Это просто произвольное различие, чтобы отделить их. Просто нужно знать, для чего это псевдоним.