Hotswap
From APIDesign
(→Modular systems and Hotswap) |
|||
| Line 2: | Line 2: | ||
== [[Modular system]]s and [[Hotswap]] == | == [[Modular system]]s and [[Hotswap]] == | ||
| + | |||
| + | In fact, the goal of [[modular system]]s is to allow a kind of [[hotswap]]. System components are supposed to be installed, enabled, disabled, upgraded or removed from the system on the fly. I believe the [[modular system]] succeeded in their mission. They find out the necessary practices to make this happen and limit the goals, so we know what is beyond the scope. | ||
| + | |||
| + | Modularity works fine for services. For implementation of shared interface that some components/modules in the system implement and others look up and use. Really look up and use everytime, you are not allowed to hold a reference to individual implementations. Such implementations are dynamic, change everytime and keeping reference to them may result in two objects implementing the same interface (old and new) not being assignable to each other. | ||
| + | |||
| + | In spite of that restriction, [[modularity]] helps developers a lot. Instead of reloading the whole application after change of one service implementation, one can reload just the implementing component/module. Still, all the objects created by the module need to be released and recreated. | ||
== [[Debugger]] == | == [[Debugger]] == | ||
Revision as of 20:54, 19 December 2010
Hotswap is the most important technology that makes developers productive. Why people think that PHP makes them more productive than Java? Because it is enough to change a single line of code in your .php file, save it and reload the webpage. Doing the same with Java requires compilation, packaging, deployment. All of this takes ages and is not flexible enough. At least it was not until Thomas Wuerthinger released his patched Hotspot!
Modular systems and Hotswap
In fact, the goal of modular systems is to allow a kind of hotswap. System components are supposed to be installed, enabled, disabled, upgraded or removed from the system on the fly. I believe the modular system succeeded in their mission. They find out the necessary practices to make this happen and limit the goals, so we know what is beyond the scope.
Modularity works fine for services. For implementation of shared interface that some components/modules in the system implement and others look up and use. Really look up and use everytime, you are not allowed to hold a reference to individual implementations. Such implementations are dynamic, change everytime and keeping reference to them may result in two objects implementing the same interface (old and new) not being assignable to each other.
In spite of that restriction, modularity helps developers a lot. Instead of reloading the whole application after change of one service implementation, one can reload just the implementing component/module. Still, all the objects created by the module need to be released and recreated.
Follow
