How encapsulation does not prevent knowledge sharing
Despite encapsulation, a client may know something
of the state data maintained by a server.
Not by direct access to it, but through the exchange of messages, and the specification of operation contracts.
All animals must know something of the world they live
in.
An earthworm knows
enough to recognise another worm of the same type – for mating purposes.
Certainly, a worm
can recognise others members of the worm set, though it may not remember them,
and surely cannot count them.
Even 3,500 million
years ago, the earliest organisms knew enough not to eat themselves.
They could
recognise their own substance and distinguish it from chemicals in their
environment.
Later, through
evolution, animals developed ever more sophisticated ways of knowing the world.
By about 700 million years ago, Jellyfish had nerve nets that enabled them to sense
things in the world and manipulate them.
In a nerve net, intermediate neurons monitor messages from sensory neurons and react by sending messages to direct motor neurons.
Thus, animals evolved to process transient
sensations – each being an encoded description of a reality.
By about 550 million years ago, some animals
had a central hindbrain to monitor and control homeostatic state variables.
An internal information feedback loop connected that hindbrain
to the organs and motors of the body.
The hindbrain had to sense the state of the body state
variables and send messages to direct actions that maintain those variables.
About 250 million years ago, the paleo-mammalian
brain evolved to manage more complex emotional, sexual and fighting behaviors.
A wider information feedback loop was needed to connect
that higher brain to the external world.
The higher brain had to sense the current state of food
items, friends and enemies in the world, and direct appropriate actions
In
short
Animals must know the real world well enough to manipulate it and predict its behavior.
If they could not find food and avoid danger, they would soon die.
A staggering achievement of humankind was the invention of machines that can store knowledge.
Software systems must know something of the world around them, since they are designed to monitor and direct entities and events in that world.
Humans not only remember knowledge (in memory) they also share knowledge (via messages).
They describe their knowledge of the world to each other - well enough.
When you talk to me, I get to know something of what you know (not how you store knowledge in your brain).
If humans could not share knowledge thus, human society would soon collapse.
I can test what you tell me against my experience and in other ways, empirical, logical and social.
And then reasonably conclude I do know something of what you know - well enough.
Sadly, human communication is imperfect, and misunderstandings occur.
But software systems also remember knowledge (in memory) and share knowledge (via messages).
And they are designed to share knowledge perfectly.
E.g. A sensor object tells a motor object that a room's air temperature is too low; there is no room for misunderstanding.
The motor acts according to that shared knowledge.
The motor need not directly access the sensor's state data, but one way or another it needs to know the state of the sensor.
Hiding how a system, person or object stores information does not mean hiding what it knows.
People share knowledge via emails stored on an email server.
We don’t know or care how our emails are stored (in binary digits).
But our ongoing discussion depends on sharing the knowledge that is encoded in that store.
Encapsulating a system behind an
interface is a principle of modular design, much older than OO thinking.
In the 1960s, an interface was understood
to hide what is inside the system, its internal operation and state data.
In the 1970s, Parnas
proposed principles for modular system design.
He recommended encapsulating the
operations that write (encode) and read (decode) the elements of a persistent
data structure.
Similarly,
in the 1980s, OO theory presumed a client cannot directly access the state of a
server.
Still, a client object may request a server object to
report facts that it detects or
knows.
Why?
So that the client can act accord to the knowledge it has acquired.
In business operations, human and computer
actors need to know the state of entities recorded in business databases.
The business rules for an operation can be
defined as pre and post conditions referring to the state of the server system
that performs the operation.
E.g.
· a precondition of a sale operation is this: Debt + Sale Value < Credit Limit.
·
a post condition
of the sale operation is this: Debt (after) = Debt (before) + Sale Value.
A client may need to check that a precondition is met, then direct
the
server to establish a post
condition.
Thus, a client may need to know something
of the server’s state data, both its structure and its value.
In short, despite encapsulation, a client
may know something of the state data maintained by a server.
Not by direct access to it, but through
the exchange of messages, and the specification of operation contracts.