The term ‘state’ may be used in various senses, which may not even all be susceptible of a precise definition. It was therefore important that you include a definition in your paper, to make quite clear how you were using the term. In the following I do not offer a unique definition of the state of an object but rather try to sketch a number of ways of thinking about it, which may be appropriate in different contexts.
First, however, you need to think what you mean by ‘object’: are you thinking about a conceptual object, i.e. some entity you are trying to model, or about an instance of a class in a specific programme; perhaps you also want to think about the state of a variable which could at different times refer to different objects or about a system, maybe as accessed via a certain user interface.
Part of the difficulty in defining the state of an object in OOP is that when we model entities in a particular language, that language often does not permit us to distinguish object attributes which are conceptually part of the same entity from others that are not. For example, a linked list of Car will consist of a number of Link-objects, which contain pointers to the next (and maybe previous) Link although conceptually the list is a single object; the links may also be embedded in Car-objects or contain pointers to them, but in this case the linked objects are conceptually separate rather than part of the list; in a list of recent changes, hoewever, the changes may only be present in the list and considered as part of it. In these various cases we must decide whether we consider the state of one object to include that of the linked objects. Further, a Car may have a link to an Registering_Authority – we probably do not consider the state of car to change when its registering authority changes the URL of its website. Unless the implementation language does allow us to distinguish different types of link, it will not be possible make a general definition of the state of an object in terms of the language alone.
The ‘external’ or ‘functional’ state could be defined as ‘how it behaves’, ee.g. how it reacts to method invocations or to a user interface. For an object as a class instance this definition depends on the type to which the object is seen as belonging: seen as a Circle, the colour of a Coloured_Circle is not visible, and hence irrelevant to its state. A difficulty with this is that ‘how it reacts’ may need to defined in terms of values returned, and these ‘values’ might be the states of other objects. One way to formalise this is to say that two states of an object are the same if all possible future executions of some system in which it is embedded result in the same mapping from inputs to that system to outputs from it. This enclosing system may be required to be a self-contained system, capable of execution independent of its environment; on the other hand, one could allow it to be as small as the object in question itself. In any case, a mathematical approach is then to define a state as an equivalence class of
The ‘internal’ state could be defined as the state of the representation. A first attempt is apparently circular but perhaps helpful: ‘The internal state of an object is the state of its members’. Here we need to take care to distinguish significant aspects of the representation from insignificant ones: at the lowest level, the representation of an object may well include addresses of other objects, but it is unlikely to be useful to consider a change in such an address as a change in state. On the other hand, a change in the state of a cache for the result of a query, while it makes no difference to the functional state (as described above), will be important when considering performance tests.
