Theory

  1. Recognize abstract/logical components within the solution/code. This suits particularly well in a situation, where there is large codebase that requires unifying and refactoring. Focusing exactly how the thing should be done and what’s the logical process.
  2. Estimate and analyze the one level higher abstraction than what is currently being done. It might be worthwhile for example abstract out the technology specific terminology and focus on the logical structure. Abstracting out the technology makes it trivial to change the underlying technology frame with easily maintainable implementation. Sometimes the change might not require changes at all in other than the code generator.
  3. Code the reference solution as usual (this can be before designing the abstraction as it usually helps to realize the proper abstraction). If there are large differences in different logical solutions, estimate how many different references are needed to cover the entire field. Note! This step is really, really important part. Using traditional object oriented environment to constrain the solution will greatly help to spot the logical issues. Generating procedural code right away will risk missing logical and structural errors.
  4. Recognize the absolute information in the logical model; what is logically required for the implementation.
  5. Parametrize the code replacing the absolute information blocks with parametrized content => making the code generation template that is driven by the information gathered above.
  6. The template will include places for the case-specific custom code. However the code is not all over the place, but in strictly controlled places. The implementation is enforced with interfaces, abstract base classes or simply generating method calls to non-existent methods that demand implementation in partial classes.

Visualization of Extracting Abstraction

Extract Abstraction

Last edited Sep 14, 2010 at 9:22 PM by kallex, version 2

Comments

No comments yet.