Acommon approach is
to build a library of reusable components, leaving the application code architecture to
the developer. One step further is to build a framework for applications in that domain.
As well as providing components, a framework ?¬?xes the architecture of the application,
with the developer plugging in her own application-speci?¬?c code at prede?¬?ned
points. Using a framework generally involves a large initial investment of time to learn
how it is meant to be used??”in the best case by reading extensive and accurate
documentation, but too often by trial and error and user forums.
In an attempt to make it easier to get started with a framework, there is sometimes a
wizard that will query the developer for necessary information and generate a partially
completed skeleton application. This approach is particularly seen where the framework
is integrated with an Integrated Development Environment (IDE), for example,
early Graphical User Interface (GUI) builders. The problem in many cases with this
approach is that it presents the developer with a mass of code that she has not seen, let
alone written, and yet is expected to maintain. That differs from successful approaches
to raising developer productivity, such as compilers, where the developer can remain
on a higher level and not have to understand or work with the larger mass of code that
is automatically generated on a lower level.
Pages:
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582