Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
Yeap, you're missing traits as a technique to simulate behaviour. –  Yannis Rizos Jan 5 '12 at 16:49
add comment

6 Answers

up vote 6 down vote accepted

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.

share|improve this answer
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! –  daniels 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
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
show 3 more comments

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).

share|improve this answer
add comment

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.

share|improve this answer
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
add comment

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.

share|improve this answer
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
add comment

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.

share|improve this answer
add comment

Partitioning all the things (I can't come up with anything other abstract enough than a thing, forgive me) that contribute to the state of the object to attributes and real states is completely subjective.

Unless you can come up with a formal definition for those things that don't contribute to the real state of the object, I'm afraid we better stick to the original definition.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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