34. To Encapsulate Or Not To Encapsulate, That Is The Question
Around the time of Metropolis Graphics, I did some contract development for a Montreal company developing a GIS (geographic information system) application. What made the job interesting was that we developed the software on OpenStep, the Intel port of NextStep.
Years ago I had read Brad Cox’s book on Objective-C, and now I had a chance to use it in the field, so to speak.
In some respects, NextStep was more a child of the Xerox Parc philosophy than the Macintosh was. It was architected on top of a Smalltalk-like language, based on messaging between objects. Not to belabor the point, but as Alan Kay has said, C++ was not what he had in mind when he invented the term Object Oriented.
And in his Next pitches, Steve Jobs emphasized the software components arguments that Brad Cox had put forward in his book. It was probably the closest anyone came to bringing that vision to life. I have a feeling that emphasis was lost once Apple purchased Next. If there is a marketplace for software components on OS X, I am unaware of it. And though I did some work in Swift (Apple’s replacement for Objective-C) a few years ago, I don't recall how Smalltalk-like it was.
One other point of interest about the GIS software was that it was based on a dependency graph. These days every 3D system seems to have a node graph system of some kind, allowing users to connect the outputs of operations to the inputs of other operations. Some, such as Houdini, are primarily based on such architecture.
I am still contemplating whether this is something I want to implement in my system. If I was developing a system intended for the market, I definitely would, but since this is exploratory development, I am hesitant to settle for what may seem like the obvious choice.
My view of node graph systems is that they bring some of the power of software development to users who are not programmers. What I would like to discover is a way to enhance the expressive power of programmers using some sort of visual development approach. And to do so while retaining the full power of Common Lisp.
Maybe a bit of a tall order.
Design & Code
The image above is deceptively simple. It depicts extrusions along a particle system growing from the vertices of a grid mesh. What is new here is that the interesting computations take place behind the scenes, in the sweep-mesh-group class.
As can be seen in the code listing, this class inherits from manager-group, and computes its children (uv meshes) as necessary. This avoids the need for a separate animator in the scene to update these meshes. The only animator added to the scene is the particle system. When it updates at each frame, the mechanism in dependency-node-mixin kicks in and calls the compute-procedural-node method of the sweep mesh group.
Not only does this encapsulate the computation inside the class, it only rebuilds the children when necessary.
I have been wondering whether I have gone too far down the rabbit hole: is it better to have visible loosely coupled components (simple animators that operate on objects), or encapsulated classes (with more complex internal — and hidden — behavior)?
Currently leaning towards the latter. I am hoping that it will allow for building layers of abstraction by hiding complexity, one of the tenets of Object Oriented design. This makes me think of the “Worse is Better” paper by Richard Gabriel, which states (much simplified) that is better to bring a simple system to market soon and then evolve it, rather than taking a long time coming up with a “prefect” solution in isolation.
I think part of the purpose of this blog is to not dwell in isolation, as I have done with past projects which never saw the light of day.
