1 July 2006
Understanding software objects
Modern software relies upon “objects,” discrete, self-contained representations in software of real things: billiard balls, automobile tires, abstractions like “facts.” An object has internal properties that aren’t exposed to the outside world, and which govern its behavior, and it has a second set of rules that govern the way in which it interacts with other objects.
Consider, for example, a billiard ball. It has internal properties that the outside world doesn’t ordinarily need to know about—compressive strength—and it has external properties that govern its interaction with the surrounding world, its elasticity and response to contact with a packaging object, for instance.
A billiard ball software object is simply a portable, self-contained enumeration of those internal and external rules. It self-regulates according to the internal rules, and it interacts with the adjoining world according to the external rules.
The problem NIST is grappling with, to continue with the billiard ball example, is this: Is it better to define a billiard ball object, or is it better to define a generic, abstract object called “ball” and then derive from it when needed a single-use object that has the specific properties of a billiard ball? And what are the indispensable properties and interactions at the selected level of abstraction?
Those questions will have to be answered for thousands of industry-specific objects before a standard can be published.
In short, NIST is grappling with the question Plato struggled with more than 2000 years ago: What is the “essence” of things? Plato was just curious, trying to understand the world in which he lived. For modern computer scientists, it’s a must-do line-item.
Read questions answered by our experts or join the email list.
