In other words, as you work on the generator, you
effectively refactor the generated code, extracting a repeated block into the domain
framework. Note that this is different from the refactoring you will do on the generator
itself, where repeated blocks of generator commands will be refactored into
subgenerators.
Since there are no hard and fast rules for ordering the creation of the generators and
domain framework, you should treat them as a balancing act. If you ?¬?nd things tilting
toward a heavy generator or heavy generated code, push back by transferring some of
the burden to the domain framework. If you ?¬?nd the domain framework becoming
unwieldy or in danger of turning into an end in itself, apply pressure in the other
direction by simply focusing on getting working code out. If you ?¬?nd the generated
code becoming obscure and unrecognizable to developers, and at least at this stage
there may be a need for modelers to look at and debug the generated code, take a step
backward toward generating the same kind of code as good developers previously
wrote by hand.
Remember that you can always refactor the balance later: existing models will
continue to generate code that works ?¬?ne, even if you move blocks between the
generator and the framework.
As we saw in Section 11.3, generators can be used for things other than code or
other product source ?¬?les such as XML.
Pages:
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650