Refactoring on Marko Apfel

Verwenden von partiellen Klassen für COM-Belange

Mon, 12 Jul 2010 15:16:00 +0200

Motivation

Schon im Whitepaper „Auszeichnung von COM-Kategorien an .NET-Klassen mittels Attributen und deren Verwendung für Setup-Builds“ [1] habe ich deutlich gemacht warum das Verwenden von COM-Registrierungsfunktionen ein suboptimales Programmierpattern ist. Knackpunkt sind die Verstöße gegen SOC (separation of concerns) [2] und SRP (single responsibility principle) [3].

Casing of COM-Interop registered components

Tue, 08 Jun 2010 09:54:00 +0200

During a refactoring I realized that renaming of components, which will be registered for COM-Interop, must be done carefully.

In my case i changed the casing of XyzToolbar to XyzToolBar.

At the developing machine everything works fine. But after installing the modified stuff at the production machine, the toolbar was not visible. Using regasm with the new assemblies helped.

Gefahren des “cleanup code refactoring” im Zusammenhang mit P/Invoke und übergebenen Strukturen

Wed, 28 Apr 2010 09:40:00 +0200

Problemkontext

So schön auch das automatische “cleanup code refactoring” von ReSharper ist, im Zusammenhang mit Strukturdefinitionen, die als Übergabe-Parameter für unmanaged Code Aufrufe benötigt werden, lauert eine große Gefahr.

Standardmäßig ist im Profil “Full Cleanup” die Option “Reorder type members” auf “Yes” gestellt.

Casting Anti-Pattern

Thu, 29 Oct 2009 12:35:00 +0100

Im unten stehendem Code ist ein Anti-Pattern, welches immer wieder im ArcObjects-Kontext zu beobachten ist.

if (element is IMapSurroundFrame)
{
 IMapSurround mapSurround = ((IMapSurroundFrame)element).MapSurround;
 ..

Es wird eine is-Abfrage gemacht (element is IMapSurroundFrame) und dann ein Stück später der tatsächliche Cast ((IMapSurroundFrame)element).