Saving (Inter)face, Build Engine apps with a Software Factory?

I’ve recently been reading “Framework Design Guidelines”. It has a lot of good suggestions. But the suggestions on “Choosing between Class and Interface” seem to go against a lot of what I’ve become accustomed to with ArcObjects.

Specifically, on page 80, they make a pretty good case for why you’re usually better off using abstract classes instead of interfaces for “separating contract from implementation”.

In addition to ArcObjects, this also seems contrary to what Juval Lowy also promotes in his book, Programming .NET Components.

While I’ve grown comfortable with interface-centric design, I wonder how much easier life would be if the ease of use offered by ArcObjects’ BaseCommand and BaseTool were introduced to other areas, such as dockablewindows and toolcontrols.

I wish I had more time to look into Software Factories. Seems like I’ve written the same basic application with ArcEngine so many times I could probably do it in my sleep. I wonder if it would be possible to use VSTS to build a factory, then just tweak the factory to crank out a new ArcEngine based application for a different problem domain. Speaking of domains, I wonder what a “domain specific language” for ArcObjects would look like. Seems like there should be a word for a mapcontrol buddied with a tocControl and a toolbarcontrol.

Helpful random arcobjects Tip:

Zombie toolbar names showing up in Arcmap under View>Toolbars?

I went into my registry and deleted everything but the default entry under HKEY_CURRENT_USER\Software\ESRI\ArcMap\Settings\CommandBarNameCache and this solved the problem.

Arcmap apparently rebuilds this cache,sans zombie, next time you view the menu.

Would be nice if MxCommandBars.Unregister would clean this up.

Kirk