One of the things lacking with any OO programming language like Java is the idea of capturing "contextual usage patterns". By this I mean the ability to capture the essence of how an object is to be used in the context of various environments. I use the term "contextual usage pattern" to mean the usage pattern of an object in some context.
OO Interfaces provide a great means of defining the structural and functional "contracts" that an object needs to support. But beyond that, a user is left with a pile of Java docs that describe how one is to use an object's API. Docs are often lacking in telling a user what all the possible usage patterns are - in other words - docs are not great at teaching a user how to code a call to an object in the context of some program. They do an OK job at best - but what's bad is that there's no formal way of capturing the technical knowledge needed to use an object - what I refer to as the "contextual usage patterns".
This is where parametric modeling (i.e. Bowstreet Factory) provides the solution. The Factory provides modeling elements called builders. When a user adds a builder to a model, the builder performs a generative task. More broadly speaking, a builder is the implementation of a design pattern. A builder accepts a set of user supplied inputs (parameters), performs a pattern recognition on a set of referenced domain objects (identified by the input parameter values), and finally applies a construction pattern on those domain objects - in the given context. If you pair a builder with an object, you get a solution to what I am talking about - an object plus its "contextual usage pattern". The builder provides the contextual usage pattern. This is because the builder can take on the role of coding the call to the object in the context of wherever the input parameters direct it.
Let's take a simple example. Say you have a Java Class that provides a formatted date that's specific to some retail store chain's back end systems. Rather than have a pile of docs on how users should code to it, the store chain's developers create a Formatted Date Builder. This builder lets the retail store chain's portal developers to simply provide an input that's a reference to a JSP tag on a server page. The builder analyzes the context of the page, and writes the code that invokes the formatted date class and maps the data to the page. If the page changes, then the automatic regeneration of the builder takes care of updating the code that calls the object in the context of that page. So, the builder provides the implementation of the "contextual usage pattern", and eliminates all the ambiguity and errors that get introduced by trying to provide this with primitive Java documentation.
Java docs are good at documenting what an object does, but a builder is more appropriate at capturing the technical design intelligence needed to implement the use of an object in various contexts.
When you take this concept a step further, you realize that a builder can capture the "contextual usage patterns" of a whole set of objects. This is powerful. One builder can code calls to a set of objects, whose usage must be coordinated or orchestrated. In other words, if you have a case where two objects must be called in a certain manner when used together in a certain context, a builder can implement this usage pattern. One builder might invoke a call to object1 feeding it parameter x, and code a call to object2 feedign it parameter y. If the context changes, the builder can update the call code to all the objects. This is the kind of usage pattern that gets messy to document, because it involves documenting the use of a whole package of objects. Bowstreet's Factory has builders that do this on a mega scale.
10:02:42 AM 
|
