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

16

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

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

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

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

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

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

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

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

Даниэль Скокко
источник
4
Да, вы упускаете черты в качестве техники для моделирования поведения.
Яннис
Посмотрите на этот пост, это может помочь: yegor256.com/2014/12/09/…
yegor256

Ответы:

13

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

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

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

Майк Накис
источник
Думая об этом с точки зрения неизменяющихся и меняющихся характеристик экземпляра, имеет смысл. И я рад, что не так далеко Благодарность!
Даниэль Скокко
Будет ли размер лампы в процессе производства или сборки государственным?
JeffO
Нет, это будет атрибут. (В смысле этого слова ОП.)
Майк Накис
4
Между состоянием и атрибутами нет принципиальной разницы, поэтому проще определить состояние как возможно изменяемое или неизменное. Хотя наличие (неизменяемого) атрибута и (изменяемого) состояния не является неправильным (и во многих отношениях эквивалентным), это различие делает определение более сложным, чем необходимо. Хотя IMO термин «состояние», вероятно, не лучший термин для описания концепции, поскольку «состояние» каким-то образом подразумевает, что оно должно меняться, в то время как «состояние» - как описано в статье Oracle - не имеет этого.
Ли Райан
Я думаю, что отношение людей к неизменности меняется с годами; для тех, кто понимает его важность, существует фундаментальное различие между изменчивым и неизменным состоянием, достаточное, чтобы оправдать другое имя. Могу ли я порекомендовать очень интересное чтение? Эрик Липперт - Сказочные приключения в коде - Неизменность в C # Часть первая: Виды неизменности
Майк Накис
4

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

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

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

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

Билл Ящерица
источник
Становится ли цвет меха лисы состоянием, потому что он меняется зимой?
JeffO
@JeffO Цвет меха также может измениться, когда он стареет, становится влажным, окрашен ... по ряду причин. На самом деле это не состояние только потому, что оно может меняться в течение жизни одного объекта, а потому, что разные объекты одного типа могут иметь разные значения для этого атрибута.
Билл Ящерица
1

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

Павел Бучек
источник
0

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

Понятия «голодный» и «испытывающий жажду» могут быть получены из базовых атрибутов (например, уровень глюкозы в крови, уровень гидратации), поэтому мы можем думать о состоянии как о мета-атрибуте, который получается из базовых атрибутов, которые мы можем циклически преобразовать в True или False на основе состояние соответствующих базовых атрибутов. Для света , например, мы могли бы думать о свете , как имеющие атрибуты applied_voltageи resistanceи функции voltage_switch()и shine(). voltage_swich()Является функцией некоторого входного сигнала (например , ручной переключатель, свет, таймер и т.д.) и shine()является функцией applied_voltageи resistance. Мы могли бы объявить метаатрибут под названием « light_stateИстина» или «Ложь», чтобы помочь мысленно построить объект, но в конце концов все эти идеи являются просто мысленными конструкциями, которые мы используем для организации нашей работы.

Блэйн
источник
-2

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

private boolean thirsty;

Кроме того, вы можете дать ему что-то вроде

private Date lastDrinkAt;

и определите, жаждет ли ваш экземпляр собаки, сравнивая текущее время со временем, когда он в последний раз что-то пил.

В любом случае, состояние ваших объектов находится в пределах его атрибутов.

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

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

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

Связи в реальном мире ошибочны. Вот как бы я научил этому (подход 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. Слово «атрибут» означает то же самое, что и данные.

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

ТР1
источник