NET. After a platform??™s early days, there is an implicit assumption that
these components will be accurate, bug-free, and offer the current interface for the
foreseeable future. There is also often the implicit assumption by the developers that
the code they are working on will continue to use the same platform. Sadly, neither of
these assumptions seems particularly well founded.
If the operating system, platform library, and SDK we rely on cannot, in the end, be
relied on, how can we reduce our dependence on it? One way is to create a new
framework: cross-platform, open source and hence bug-free (or at least if there is a
bug you can quickly correct it), and switch to using that. Irony aside, this is indeed a
popular approach, as can be seen from examples such as GTK?? or the lower-level
Cairo Graphics library. However, to be successful, such projects need a large number
of participants with different platforms and needs, and require a number of years to
complete. While most of them never make it, the ones that do are a great addition to the
tools available to software developers.
Another approach is to attack the other end of the problem: rather than trying to
make a new implementation framework that is more generic, make a new framework
layer that is more speci?¬?c to your problem domain. The interface of this domain
framework upwards to your generated code can remain the same, and only the
interface down to the components needs change with the platform.
Pages:
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590