We define a Framework (FW) as a software structure with generic functionalities which can be adapted or extended in order to provide a specific application.

They can be mistaken with libraries but the approach is totally different. These are the FW key distinguishing features:

• Inversion of Control. The flow of control is dictated by the FW and not by the application using its services. This is also known as the Hollywood principle: “don’t call us, we’ll call you”.
• Extensibility. Certain functionalities of the FW are not “closed” – as it happens in libraries -, on the contrary they are designed to be extended in order to solve the particular problem.
• Default Behavior. FWs have a default behavior, which defines the flow of control. As seen before, the extensions allow us to adapt this default behavior to the particular problem that each application solves.

Frameworks are the base of plug-in architectures and software-ecosystem oriented systems (facebook, twitter, amazon…), but, above all, is the perfect base architecture for the generated code.

Technically, depending on the programming language, there are different ways to implement them. If it’s allowed by the language, abstract classes, partial classes, delegates and generic types are the best features to do it. Otherwise there are other strategies such as interpreters, intermediate functions – kind of visitor pattern- to solve the extensible call and others.

Benefits in code generation
These are some of the features that recommend the use of FWs:

• Extensible. The work is divided in two main parts, which makes easier the definition of the code generator.
• Structured. Designing the generic part on one side and extensions on the other, provides a more structured architecture.
• Security. Handmade code and generated code are in different files, and this mitigates the risk of loss or replacement.
• Reusable. Once the FW is defined it can be used in different projects, again making easier the development of the generator.
• Readability. The separation of the generic flow of control and the extensions facilitates code reading.

Conclusion
When code generation is approached for the first time, it is often thought that the system must be 100% generated. After that, we realize that this is not only a complex approach, but also a design error and an unbalanced distribution of work.

To achieve a well-designed architecture and a good distribution of work frameworks are the better half of our generated systems.

Finally, it’s important to remark that designing the generated code as a framework structure is also a good practice, because it allows us to implement – by extending – those manually features that we don’t want to automate and it provides systems that can be extended by a software ecosystem.
 

View all Academic Posts.