A software always consists of data and behavior (business logic). The behavior are the (business) rules that define what the software should do – in a very easy form, think of a function like a + b = c. The function (behaviour or business logic) is a + b, the result is c.
The result is data, without further processing it will never change. This is why data represents an object’s state – The data is “the place” in an object where we store a temporary value – it could change over time – so it represents the state of the object.
One small example – Image we have an Object of Class “TrafficLight” –
As we know, a traffic light has 3 light bulbs: one red, one yellow, and one green – oh wait – actually, this is already a simplification as there are all sorts of different traffic lights…
So let’s say – in our domain (simplified from reality)
- A traffic light consists of 3 light bulbs, red, yellow and green.
- There is always exactly one and only one light be switched on at the same time.
- In our domain, red is followed by yellow is followed by green, is followed by yellow is followed by red and so on.
So for the color yellow, it can be followed by either red (going “up”) or green (going “down”), depending on the current state of the traffic light.
So the Class might look like:
Active Light (red / yellow / green)
– RedBulb (“on” / “off”)
– YellowBulb (“on” / “off”)
– GreenBulb (“on” / “off”)
– Direction (“up” or down”)
So after we start our TrafficLight simulation, at a specific time, let’s say after 2 minutes, our TrafficLight might be in the current state of “red”, “down”, or “yellow”, “up” –
And from this current state, we could calculate the next light that will be switched on. So if you would “pause” or “freeze” the running program at any given time and would look at each value in an object, all these values together form the current state of the object.