You might be asking yourself, "What are Builders and why the heck did Chad add them to Chasm?". Lets go into it a bit.
Figure. The left is the design of Chasm while the right is what could have been the design. The left simplifies inheritance.
Builders are a Design Pattern. They allow for an object to be implemented in multiple ways without changing itself. What this allows is an object to represent a simple concept, as in a button, but have its implementation handled by a library, or even multiple libraries, without concerning the original Concept. It abstracts away the implementation. So, a button is described by language and the Chasm formalism but the Builder defines how it is implemented. This allows multiple libraries to implement the same useful concept.
For example, Chasm's concept Button was originally implemented in SVE by inheriting off of the ButtonBuilder, adding in the required implementation for the Button to integrate with SVE. Later, other libraries and toolkits can do the same.
Why not inheritance? If you have extension by inheriting off of Button itself, then any code which extends Button will have to extend all implementations of Button. The Builder internalizes this, so that extending Concepts to Button, do not worry about what the Builder is and don't have to choose which implementation they inherite from. Though the figure seems to show it as more complicated, the number of inherited classes explodes with each new inheritance. The heavy use of inheritance in Chasm required Builders.
Of interest too, Builders themselves can add states and symbols to the concept in order to deal with their own internal behaviors.
NOTE: inheriting builders is a good idea! Needs to add picture about this.
Generating Builders with chasm2C
See ChasmCodePhilosophy.
Back to HomePage