原文是貼在我E文博客中，先轉(zhuǎn)過來有空再譯:

In the pococapsule newsgroup, someone asked the following question about dynamic invocation proxies in PocoCapsule:

As far as i understand, these proxies are dependent on the configuration file (e.g. setup.xml).... I would think that the need for recompiling the proxy when the configuration file changes is a "big disadvantage". One of the great things of IoC is that the system can be configured by "just" changing the configuration file. But now users also have to recompile reflextion proxies (?). ... Can pxgenproxy generate reflextion code for ALL classes in the specified .h file(s)?

I would like to use this opportunity to clarify several related issues:

First of all, with PocoCapsule, one does not need to recompile dynamic proxies under configuration changes that only modified function invocation parameter values. One only needs to rebuild new proxies for new function invocation signatures involved in the new configuration. In my opinion, this is not only desirable (no recompilation on parameter value changes) but also acceptable (build new dynamic proxies for new signatures). The assumption is that real world application configurations should avoid applying new invocation signatures that have never been tested before. This kind of usage scenario automatically avoids the need of an on-the-field recompilation after a reconfiguration. Because all dynamic proxies to be used by the application on field should have been generated and compiled for deploying the application during QA tests.

Secondly, many popular IoC containers today even favor static solutions over dynamic configurations. In these manual programmatic based (such as the PicoContainer without the Nano) or metadata based (such as the Spring Framework with Spring-Annotation) solutions, not only new function signatures but even parameter value changes in configurations would force recompilations. Although I am not keen on these solutions (especially the recompilation under value change is highly undesirable in my opinion), I do believe that these well accepted and even enthusiastically pursued solutions indicate that such a recompilation does not bother real world applications.

This is not because the industry does not recoganize the claimed "disadvantage" of the on-the-field recompilation implied in these hot solutions, but because IoC frameworks are not intended to be yet another scripting environment. Rather, IoC frameworks are mainly for:

• Separating plumbing logic (component life cycle controls wirings, initial property settings etc.) from business logic and supporting framework agnostic business logic components.
• Allowing user to setup (configure/deployment/etc.) an application declaratively (by expressing what it is alike, rather than the procedure of how to build it step-by-step),
• Supporting the idea of software product lines (SPL) based on reusable and quickly reconfigurable components and domain-specific modeling.

Whether a given IoC framework is able to avoid on-the-field recompilation when new signatures appearing in the declarative configuration descriptions is merely a bells-and-whistles feature rather than a "great thing" (neither a "big disadvantage" if it does not support it). In PocoCapsule, generated dynamic proxies are very small and cost neligable recompilation time for most applications, not to mention that:

• On-the-field recompilation can largely be avoided if component deployments have been pre-tested (as discussed in the beginning).
• This recompilation need even less time than packaging deployment descriptors (such as package them into .war/.ear/.zip files).

Now, let's take a look on those seemingly "minor" disadvantages from the suggested solution that generates proxies for all classes in specified header files:

• More manually code fixes: I would suggest one to play some of relevant utilities, such as GCC XML, on various header files on different platforms (including Windows, various unix/linux, VxWorks, Symbain OS, etc. Because IoC frameworks do not (and should not) prohibit user to use non-portable components, the utilities that parsing header files would have to either deal with non-portable header files (including various platform specific C++ extensions) or require users to fix those header files manually before parsing. In the suggested scenario, the developers who were only going to configure the application at high level would have to apply more low level code fix effort.
• Bloated code generation and heavy runtime footprint: Based on various application examples, we compared PocoCapsule generated proxies code to CERN REFLEX that generate all proxies of classes in specified header files. Typically, one would see REFLEX produces 10 to 1,000 times more code than it was actually needed for an IoC configuration. These redundent code eat megas of runtime memory (instead of few or few tens kilos). This is because in the suggested solution, one would have to generate proxies for all classes that were implicitly included (declared in the other header files that were include by specified header files), proxies for all classes that were used as parent classes of some other classes, and proxies that are used as parameters of class methods, etc.. Otherwise, it would be merely 50 yards vs 100 yards, namely, one would still have the claimed "big" disadvantage of having to rebuild proxies after all.
• Human involved manually edited filters: Utilities, such as GCC XML (and therefore the CERN REFLEX), allows one to filter out unwanted proxies to reduce the size of generated code. However, one would have to manually edit filter configurations. The consequence of applying such filters are more code (or script) and more complexities to be handled and mantained manually. This immediately defeats the whole point of using the IoC frameworks.
• Additional footprint for a runtime type system: To support OO polymorphism (e.g. components that extend from interfaces) without recompilation, simply generating all proxies is not sufficient. The solution would have to provide a runtime type system (and additional metadata as well). This will increase the application runtime footprint roughly by another ~1Mbytes.
• Generic programming (GP) would be prohibited: As we know, C++ template specialization mandates recompilation. We can't have compiled code that could be applied to all possible specializations. To ensure no recompilation, the solution would have to accept a "minor" disadvantage, namely prohibit the use of GP. GP is used heavily in many PocoCapsule examples (see those corba examples that use "native" servant implemention). It significantly shortens the learning curve of some middlewares, such as CORBA (one no longer need to learn POA skeletons), simplifies application code, and supports legacy components with much less refactoring cost.

With all these disadvantages what one would gain was a merely an "advantage" that could help him to shoot himself in the foot -- to deploy an application that involves wirings that have never been tested previously.