Databases Reference
In-Depth Information
Using program counters and memory to manage state was the goal of John von Neu-
mann and others in the 1940s when they developed the first computer architecture. It
specified that both data and programs were stored in the same type of core memory
and a program counter stepped through a series of instructions and updated memory
values. High-level programming languages divided memory into two regions: data and
program memory. After a computer program was compiled, a
loader
loaded the pro-
gram code into program memory and the data region of memory was allocated to
store programming variables.
This architecture worked well for single-processor systems as long as it was clear
which programs were updating specific memory locations. But as programs became
more complex, there was a need to control which programs could update various
regions of memory. In the late 1950s, a new trend emerged that required the ability to
protect data by allowing specific access methods to update regions of data memory.
The data and the methods, when used together, formed new programming constructs
called
objects
.
An example of the object state is shown in figure 10.3.
Objects are ideal for simulating real-world objects on a single processor. You model
the real world in a series of programming objects that represent the state of the
objects you're simulating. For example, a bank account might have an account
ID
, an
account holder name, and a current balance. A single bank location might be simu-
lated as an object that contains all the accounts at that bank, and an entire financial
institution might be simulated by many bank objects.
But the initial object model using methods to guard object state didn't have any
inherent functions to manage concurrency. Objects themselves didn't take into
account that there might be hundreds of concurrent threads all trying to update the
state of the objects. When it came to “undoing” a series of updates that failed halfway
through a transaction, the simple object model became complex to manage. Keeping
track of the state of many objects in an imperative world can become complex.
set-a
get-b
Object instance variables
a=1
Your code
b=7
get-a
set-b
Accessor “methods”
(getters and setters)
Figure 10.3
Object architecture uses encapsulation to protect the state
of any object with accessor functions or methods. In this example, there
are two internal states, a and b. In order to get the state of a, you must
use the
get-a
method. To set the state of a, you must use the
set-a
method. These methods are the gatekeepers that guard all access to the
internal state variables of an object.
