This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: More on Subsystems
Feed Title: Richard Demers Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rademers-rss.xml
Feed Description: Richard Demers on Smalltalk
Travis Griggs made a number of interesting comments about my posting on The Code Grouping Mess. I won't argue with the points he makes, but I continue to believe software should be built out of subsystems because that's the way the natural world is built.
Yes, I know that sounds like idealistic, hyper-academic drek. And yes, I know that the natural world only appears to be built that way because that's the way scientists have chosen to characterize it, and that there are all kinds of exceptions to that view. But we really do talk about atoms and molecules and cells; they really do appear to be at different levels of a physical hierarchy; and the properties of each level do emerge from the structures and actions of the lower level. So it is not unrealistic to think software can (should) be built the same way, with human designers and programmers as the evolutionary engine, rather than natural selection.
Not taking the physical analogy too literally, what would hierarchical software subsystems look like? In one view, they are just BIG objects, defined by a class whose methods encapsulate their contents. Like an object, a subsystem is an instance of a class with both state and behavior. And like objects, subsystems interact with other subsystems via messages, and cannot affect the contents of other subsystems except through class-defined methods.
From this, it should be clear that I do not view subsystems as just another way to package classes and methods. They are not another configuration management technique for shared code. In fact, I would view a package as being a kind of subsystem; an instance of the Package class of subsystems, with classes and methods as their contents.
But subsystems are qualitatively different from objects. I like to think of subsystems as each being a separate, independent address space in which objects are managed. Structurally, each has a class-defined set of slots that point to objects contained in the heap portion of the subsystem. The objects in the subsystem's heap can freely interact with each other, but not with objects in the heaps of other subsystems. Interactions between subsystems are through a special kind of object called a Capability that carries not only addressability but also rights of use.
It would take major changes to Smalltalk's Virtual Machine to fully implement these ideas, but they can be simulated within a standard image. We need only make the concept of a subsystem containing objects "virtual," implemented by means of a framework and enforced through conventions.
Incidentally, what I call subsystems are called "System Objects" in the IBM OS/400 operating system. There are, however, two major differences: OS/400 System Objects contain traditional mapped data values, as required by procedural languages, and there is no concept of "classes." Historically, in the 1970's two different groups of people took the concept of objects in different directions for different purposes. I believe it is time to reunite them.
Previous Topic
