The world of object-oriented programming (OOP) revolves around the concept of object state. How do you define the state of an object? In terms of values of its attributes. At the atomic level, it is quite quantitative. But the combined picture that emerges, the state of the object in question, cannot be quantified. Take the example of a Bus as a class having attributes:

1. maker 


2. model 


3. grossWt 


4. engineCap 


5. odoRead 


6. fuelAvl 


7. lastService 


8. yearsInService 


9. lastBreakDown 


10. fuelEco
Consider three sets of data of an object bus67:

1. maker: "Volvo" 


2. model: "B7R" 


3. grossWt: 19000 


4. engineCap: 7 


5. odoRead: 4000 


6. fuelAvl: 80 


7. lastService: 23-Mar-2018 


8. yearsInService: 1 


9. lastBreakDown: 01-Jan-1970 


10. fuelEco: 3

1. maker: "Volvo" 


2. model: "B7R" 


3. grossWt: 19000 


4. engineCap: 7 


5. odoRead: 12000 


6. fuelAvl: 100 


7. lastService: 01-Feb-2019 


8. yearsInService: 2 


9. lastBreakDown: 01-Feb-2019 


10. fuelEco: 3.1

1. maker: "Volvo" 


2. model: "B7R" 


3. grossWt: 19000 


4. engineCap: 7 


5. odoRead: 40000 


6. fuelAvl: 20 


7. lastService: 01-Aug-2021 


8. yearsInService: 4 


9. lastBreakDown: 31-Oct-2020 


10. fuelEco: 3.1
Each dataset corresponds to a "state". What is not clear is how to measure the same. It is a more abstract thing, even though composed of quantifiable entities. Understanding object state change changes its behaviour also is key. That also is the root cause of most of OOP’s endemic issues.

Data encapsulation has made data inaccessible through traditional routes. But that has only shifted the problem to the object layer. Now one can do anything to any object through method invocation. And "method invocation" is a potent weapon. Because a method, by definition, has the access to the innards of an object. Using or misusing that access, a method can set any attribute to any value with potentially disastrous consequences.

That pretty much sums up the problem of side effects in OOP.

It is not a trivial problem. It has driven software architects to design stateless systems. A stateless system, in its simplest form, is a function which has a peculiar mental affliction. It is extremely introverted. It does not connect to a network, or any database, or any storage. It just accepts all whatever it takes to do computation through input parameters. And the output or the return value will solely depend on the inputs and nothing else.

One may ask a basic question here: How does one get data without having accessed network or disk or database? Well, the calling program does that job. Having gathered all the data, it invokes the function. The function, the pure one, needs to restrict itself to computing. I do not know if you have noticed that we have quietly trespassed into the world of stateless computing. These days, it has been synonymous with AWS Lambda. Many decades ago, a humble networking protocol took care of communications between two computers having huge geographical separation. It was fully stateless. It was called HTTP.

Modern Web Services - SOAP or REST - are also stateless. Data are structured like objects in XML or JSON. So one can pass on any amount of complexity to a function - web method - and get an equally complex response. The traditional object-oriented model can probably be safely abandoned at this point in time.

This article was just a primer on object state. In some subsequent articles, I will examine how complex systems are built upon the simple concept of object state - or the lack of it.