Observations
Observations
When it invented, or refined, the Delegate construct for VJ++, Microsoft proposed the Delegate solution not
as an alternative to interfaces, but rather as an alternative in the Java event model and to promote the loose
coupling between classes in event− handling scenarios, which also set the stage for an elegant anonymous
invocation model. Sun refused to accept the proposal to include Delegates in Java, but Microsoft went ahead
anyway and built Delegate support into the Windows Foundation Classes (WFC)the precursor to the .NET
Framework class libraryan issue that had the phones at Sun's lawyers ringing off the hook.
As a result, Delegates could only be used in software that ran on Microsoft's JVM, which was unacceptable to
Sun because it, essentially, violated the "write once, run everywhere" philosophy and many other "rules"
Microsoft had apparently disobeyed. So now you have Visual J++ Delegates in the .NET Framework, "write
once, run on every Windows." I have been a Java fan for years, and still am, but I find Delegates so powerful
and elegant that it's difficult to see why Sun had such a nervous breakdown over them.
The beauty of .NET is that no matter what you believe, both Event models can be adopted with relative ease.
While Delegates will be the recommended route for wiring events, Visual Basic .NET's support for native
interfaces and the relative ease with which you can construct adapters lets you work with both. That's an
amazing amount of power, don't you think?
As for the Asteroid/Trajectory application you can inspect it further in the source code that comes with this
book. It is included in the [Link] project.
493
