More often, there is a need to specify new
dynamic behavior per application. We have seen a number of ways of building
modeling languages to capture such information, and in Chapter 11 we saw several
approaches for turning that information into code. Now we must consider how the
domain framework can best integrate such code.
First though we must address the myth that information can be divided into data
and code. All too often we hear skeptics say: ???sure, you can generate that part, but
that??™s just data: what about some real code???? The truth is that there is a sliding scale of
increasing complexity, with stereotypical data and stereotypical code at opposite
ends. Good developers will generally work to push things toward the simpler, datalike
end of the spectrum, and thus reduce complexity. In many cases we have seen in
industry, the ???need??? for real code has in fact simply been evidence of a failure to take a
step back and look at the wider picture.
To take a more iconoclastic viewof things, all code is in fact data, used to con?¬?gure
some framework or engine. C code is the fodder for the compiler: one long string, or
after parsing a simple tree of a few keywords with primitive string or integer values as
leaves. Database guys can snicker at developers as they point out that even an online
pet food store might have more complicated data structures.
Pages:
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599