The Sun’s definition of an object is one of many forms. Though, not entirely applicable in all cases. For example, a singleton service object may not need to hold any state, base on Sun’s examples. It may have one or more interfaces that invoke by the client. Once the invocation has completed, no data is stored within the object hence no state. Sun’s definition is a bit ambiguous. It gives examples for state as data. e.g. speed, direction, hungry, breed. It is implying that objects are for data encapsulation. There are more types of object than data encapsulation objects (ie data entity) e.g. controller objects, etc. There are many other definitions for state. For singleton object in multi-threaded environment, the object may be busy (one state) and calling objects has to wait for the single object to be free (one state). Both of these states are not data related.
A better and less confusing definition, mentioned by Booch, would be an object has roles or responsibilities. This relates more the problem domain than the definition use by Sun. If the designer use this form of definition, the designer actually think about the problem solving at hand. So the questions would be what sort of objects does the system need to solve the problem, what would their responsibilities and interactions. For example, the responsibility of a Manager is to manage a bunch of objects such as a window manager would manages window objects. I am not saying Sun’s definition is wrong. I prefer the roles/responsibilities – which actually allow the designer to think about the problem and solutions to the problem. It is quicker to think about roles/responsibilities than to think about state/behaviour. Maybe I am too brain washed by the GoF’s Design Patterns.