I was reading through Oracle's introduction to OOP concepts and I came across this description:

Real-world objects share two characteristics: They all have state and behavior. Dogs have state (name, color, breed, hungry) and behavior (barking, fetching, wagging tail). Software objects are conceptually similar to real-world objects: they too consist of state and related behavior.

My problem with that passage is that when describing state its mixes attributes there too. For instance, the name and color of a dog are its attributes, while it being hungry or thursty are its states.

So in my opinion it's more accurate to break the characteristics of objects into three parts: attributes, states and behaviors.

Sure, when translating this into a programming language I can see that the three-fold partition becomes a two-fold one, because both attributes and states will be stored into fields/variables, while behaviors will be store into methods/functions.

But conceptually speaking it makes more sense to have the 3 things separate.

Here's another example: consider a lamp. Saying that both the lamp size and whether or not it's turned on are states is a stretch in my opinion. The lamp size is an attribute, not a state, while it being turned on or off is a state.

Or did I miss something?


You are right in that objects consist of attributes, states, and behavior, if you define attributes to mean non-changing characteristics of an instance. As a matter of fact, it is important to make this distinction, because there exist objects which contain only attributes, (in your sense,) and no state; they are called immutable and they are very useful in programming.

This three-part definition is indeed represented in programming languages, for example using the final keyword in Java or the readonly keyword in C# to denote instance data which may not change throughout the lifetime of the instance.

I have to add, though, that non-changing instance data are usually not called attributes. We tend to speak of them as 'final' or 'readonly' or 'constant data' depending on which language we are using. The proper term for them would be 'invariants', but then this word is not frequently used in this sense; it is more often used for other things.

  • Thinking it terms of non-changing and changing characteristics of an instance makes sense. And I am glad I wasn't that far off. Thanks! – Daniel Scocco Jan 5 '12 at 17:09
  • Is the lamp's size during a manufacturing or assembly process going to be a state? – JeffO Jan 5 '12 at 18:22
  • No, it is going to be an attribute. (In the OP's sense of the word.) – Mike Nakis Jan 5 '12 at 18:24
  • 4
    There is no fundamental difference between state and attributes therefore it's simpler to define state as being possibly mutable or immutable. While having (immutable) attribute and (mutable) state is not incorrect (and is in many sense equivalent), that distinction makes the definition more complex than necessary. Although IMO the term "state" is probably not the best term to describe the concept since "state" somehow implies that it is supposed to change, while the "state" -- as described in Oracle's article -- does not have that. – Lie Ryan Jan 5 '12 at 18:47
  • I think that the stance of people towards immutability is changing as the years go by; for those who understand its importance, there is a fundamental difference between mutable and immutable state, enough to warrant a different name. May I recommend a very interesting reading? Eric Lippert - Fabulous Adventures in Code - Immutability in C# Part One: Kinds of Immutability – Mike Nakis Jan 5 '12 at 19:08

I think it's more accurate to say objects have only two characteristics. Taking Oracle's example:

Dogs have state (name, color, breed, hungry) and behavior (barking, fetching, wagging tail). Software objects are conceptually similar to real-world objects: they too consist of state and related behavior.

The fact that the values (state) for name, color, breed, and hungry are stored in the object in attributes is an implementation detail. You don't really need attributes at all.

If you're going to include attributes as a third characteristic, then you'd also have to include methods as a fourth, since (like state) behaviors of objects can change as well. State and behavior are two abstract characteristics of objects. Attributes and methods are concrete implementations of those concepts.

  • Does the fur color of a fox become a state because it changes in winter? – JeffO Jan 5 '12 at 18:23
  • @JeffO Fur color also might change when it gets old, wet, dyed... any number of reasons. It's not really a state just because it can change during the life of one object, but because different objects of the same type can have different values for that attribute. – Bill the Lizard Jan 5 '12 at 19:19

State is set of attributes and corresponding values, so from my point of view, you are not right (and you are creating unnecessary additional complexity to simple definition).


We can classify things in innumerable ways and each classification would have no "right answer". There is a benefit to classifying things only if the classification leads to some deeper understanding or to improve communication. If your team prefers to use the terms attributes, states and functions and has good working definitions for these this will help improve internal communication but you need to be flexible when communicating outside this group.

The concepts "hungry" and "thirsty" can be derived from basic attributes (e.g. blood glucose, hydration level) so we could think of state as a meta-attribute that is derived from base attributes that we can cycle to True or False based on the state of relevant base attributes. For the light example, we could think of the light as having the attributes applied_voltage and resistance and the functions voltage_switch() and shine(). The voltage_swich() is then a function of some input (e.g. manual switch, light, timer, etc.) and shine() is a function of applied_voltage and resistance. We could declare a meta-attribute called light_state that is either True or False to help mentally construct the object, but in the end these ideas are all just mental constructs that we use to organize our work.


The state of an object is encoded in its attributes, either directly or indirectly. For instance, if you want your Dog to be thirsty, you can let it have a

private boolean thirsty;

Alternatively, you can let it have something like

private Date lastDrinkAt;

and conclude whether your instance of dog is thirsty by comparing the current time with the time it last drank something.

Either way, the state of your objects lies within its attributes.

Then there are classes that do not have attributes, mostly utility classes. But you usually don't want to create an instance of them either in this case.

For the sake of being able to reason about statements, scientists usually stick to the principle of minimality. I think that's why Oracle didn't mention state explicitly. It can be derived from the value of the attributes.

  • 1
    Oracle did mention state explicitly; read the quote. And the OP is obviously using the word attributes in the sense of non-changing characteristics of an object, so he is not confusing them with state. – Mike Nakis Jan 5 '12 at 17:13
  • They're still characteristics - whether they are changing or, whether you call them "attributes" or "members". There's nothing else in the programming world to represent the state of an object besides its attributes. – Raku Jan 9 '12 at 8:21

The real-world connections are misguided. Here's how I would teach it(c++ approach):

  1. Computers support two different storage formats: data and code
  2. data looks like bits 010101010101
  3. code looks like asm instructions
  4. data bits have two different values, it's either 0 or 1
  5. data is abstracted to data types: int i=1; is just short notation to some bits 0000001
  6. code will look like a function: int f(int a) { return a+a+a; } is short notation for some asm instructions
  7. when you have several variables, you combine them to a struct: int a; float b; can be placed to a struct AB { int a; float b; };
  8. when you combine some code pieces to it, you get a class: class ABf { int a; float b; float sum(float c) const { return a+b+c; } };
  9. Then for data we have variable names which can be used to find the value: a+b+c to access the data.
  10. And then we have normal function calls: int k = f(10); to access the asm instructions "stored" inside f-function.
  11. Then there is object instances: ABf var;
  12. And the member function calls: int k2 = var.sum(10.0);
  13. functions have types int f(int);
  14. member functions have types int ABf::sum(float);
  15. There is this-pointer with type ABf*
  16. variables like a and b and c are context dependent, if they're inside member function, they could mean this->b, or just b.
  17. Member functions int ABf::sum(float c) is just short notation for int sum(ABf* this, float c);
  18. the word "state" just means the same as data
  19. the word "behaviour" just means the same as code
  20. the word "attribute" just means the same as data.

So there isn't really anything different between state and attribute. It's just random collection of bits. It's just arbitrary distinction to separate them. Just need to know what it's alias for.

Not the answer you're looking for? Browse other questions tagged or ask your own question.