Lamino

Objects, persistent or not

In general, there are more persistent objects that "are there" before the program starts doing its usual chores, and more ephemeral objects that are created and destroyed during its execution (in fact, creating objects is one of the most time-consuming activities that profiling highlights in a program). Spring provides the means to define both the persistent object graph and the ephemeral objects.

Synthetic Getters

IoC generally results in clean code which does not depend at all on the container. However, there is a case where making an explicit call to the container cannot be avoided, and this is when one needs a non-singleton object.

This is my answer to how we can ensure non-intrusive use of an IoC container in that case, by separating the code that is independent from the dependent one and generating the latter automatically.

WHAT IS LAMINO

Lamino is a high-level configuration metalanguage that enhances basic IoC (Inversion of Control a.k.a. Dependency Injection) with configuration layering and encapsulated components. It is hosted by an IoC language and it "compiles" to it. Using configuration layering, the application developer can create editions or extensions by expressing the differences of each configuration layer from the layer below it. Using encapsulated components, the application developer can define reusable configuration chunks that import and export specific services, while hiding internal contents.

WHY USE IoC IN THE FIRST PLACE

An OO program cannot be adequately described by its code alone. It is not just code with an entry-point. Instead, it is an object graph with an entry-point. We can define an OO program more accurately, if we have the means to define both the code and the object graph. IoC containers provide the programmer with a handy facility to assemble the object graph needed by a program.

The difference that OO brought to mainstream programming, is the ability to achieve variability through the use of polymorphism. Every time we introduce a new class in a program, encapsulating a chunk of the overall logic, we create a new variation point. This variation point can be exploited by varying the implementation of the class which demands code changes that can be extensive. IoC containers bring the variation points to the surface, where objects can be defined in a single place regardless of their clients.

A lot of IoC containers use code as the configuration language to define objects. My belief is that IoC containers that use declarative configuration (mostly XML) offer an additional advantage, that of being more susceptible to introspection and editing, even by non-programmers. Treatments like those Lamino does would not be possible on code-based IoC configurations.

WHY USUAL IoC IS NOT ENOUGH

Usual IoC does a good job in defining a single application, but using it to define different editions and deployments of a product is cumbersome. IoC allows us to modify the variation points of the configuration, but the way to do it is by copying the configuration and applying the changes by hand. This practice masks the fact that most of the configuration is unchanged, and the small amount of change that was effected cannot be recognized afterwards. It is customary to use flat property files to group together values that are prone to change from site to site, but this variability falls short of what IoC is capable of. What is lacking, is a way to layer the configuration so as to build upon existing configuration, specifying just the changes.

The other capability that usual IoC is lacking, is a way to reuse configuration to instantiate components as many times as needed. Without this capability, the programmer needs to copy and rename the objects that constitute the object graph of the component. Again, this does not leave a trace of the underlying similarity, and does not promote reuse.