Monthly Archives: July 2012

Clean Interface Inheritance

Recently, I had a interesting conversation about interface inheritance with one of my colleagues. Reason was a decision necessary how to implement basic behavior based on a set of interfaces for a number of classes. At first, I was not comfortable to  let one interface inherit from another. I was quite biased from the design of the code base I am currently working on.

Generally spoken, each class inherits from its very own interface. In addition the inheritance scheme of classes is reflected in the interface inheritance as seen in the example below. Why would one come up with such a design at all?

Complexe Interface Inheritance

To understand this design (it’s still a design) some more context is required. In the particular codebase a dependency injection container is used to resolve instances of a particular type. To do so a unique identifier is required. This could be a string but also an interface. E.g. the Microsoft Extensibility Framework (MEF) makes usage of interfaces for resolving. Using MEF it is quite easy to get a set of components implementing a particular interface (e.g. some kind of IPlugin interface).

The issue I’ve seen, there are only few common interfaces in the codebase . Instead of collecting all types of a particular interface, dedicated interfaces are used to resolve particular instances of types. However, by using interfaces this way, the focus is to identify types by their interfaces not using interfaces as contracts.

Back to the issue how to design the interface inheritance, we came up with two alternate approaches, both valid indeed, but with very different design goals.

Implementing or Inheriting interfaces

In the left hand approach two types inherit from the same base type implementing a particular interface. Both types also implement another interface, i.e. both types fulfill the same contract. In the right hand approach we see both types inheriting from the same interfaces as well. While at the end both approaches will end in the same a similar result, there is a significant difference in the semantic.

Based on both approaches, we came up with two possible solutions for a .NET implementation. While this might seem quite academic to you, there is quite a difference how one might use these types.

Inheriting Interfaces vs Implementing Interfaces

As in the example before, both approaches will end up in two classes implemented identically, however, both implementations show semantic differences best seen when considering the usage of these classes. In the left hand example one could iterate through a typed list of IAlgorithm calling a Dispose method required by the IDisposable interface. This implementation is obviously contravariant. Following the right hand scheme, you might still iterate through the list, however,  before accessing the Dispose method it is required to cast the concrete instance to IDisposable. While being still contravariant, it is not implicitly possible.

The question now, is to decide when to use the fist or the second approach. Interfaces inheriting from other interfaces is absolutely valid once you can answer the question if your type is some kind of with yes. In the given example each algorithm is an IDisposable. No exception, no excuse. Choosing the second approach you should be able to answer the question whether your type needs to fulfill a particular contract with yes. If only a few algorithms need to be fulfill the contract given by the IDisposable interface, and an algorithm is not a IDisposable by default, the second approach might be the right to choose. While each algorithm is still an IAlgorithm, only some of them could implement the IDisposable interface.

Maybe this seems obvious to you, however, I still see quite experienced developers having significant problems in choosing appropriate inheritance structures. From avoiding inheritance at all to the point of using the most complex inheritance structures you might have ever seen in your programmers life. There is no right or wrong but there might be a best solution suitable to your problem. So never hesitate questioning your current design looking for a better approach. 

Windows Metafile Preview on Windows 7

Works on my machine!The visual preview of files in Windows Explorer is one of the great features of Windows when looking for a certain file. Unfortunately, with Windows Vista Microsoft disabled the preview for Windows Metafile Format (.WMF) and Enhanced Metafile Format (.EMF) files. As I needed t work a lot with EMF files during my latest book project with Springer, I was looking for some way to enable the preview of the file types mentioned above in Windows Explorer.

Windows 7 without EMF/WMF preview

Fortunately, there is a great plugin called emfplugin written by Daniel Gehringer to enable the preview. The plugin is available for x32 and x64 machines and should work on both, Windows Vista and Windows 7. Once installed (and rebooted) the Windows Explorer is capable of displaying EMF and WMF files.

Windows Explorer EMF and WMF thumbnail preview plug-in

The plugin is licensed under the MIT license, so its safe to go with it. At the very end this raises the question why Microsoft did actually disable the preview for two formats developed by Microsoft itself and whether they might work with Windows 8 again.

Windows 8 Pricing

Windows 8 LogoBased on the blog entry from Brandon LeBlanc the Windows 8 Upgrade (via Windows.com) will probably be available for $39.99. This is quite a smart move by Microsoft as you get Apple’s Mac OS X Snow Leopard from their store for about $29.00.

If the upgrade really works from Windows XP up to Windows 7, Microsoft might be possible to shift many users to the next generation of Windows. While the price for previous Windows upgrades was quite high, many users kept their former version of Windows until they bought a new personal computer, obtaining a new OEM version of Windows.

Nowadays, computers used at homes definitely last longer than the average Windows life cycle and quite a lot personal computers outside in the wild might see at least two version of Windows until being replaced.

Therefore, personally I welcome this move by Microsoft, considering to upgrade even more than one of my licenses to the new Windows version. Even though, this might be a strategic move by Microsoft to keep market share, existing customers definitely gain by the relatively low prices by upgrading even from previous Windows version. This might be quite an advantage as one has to buy each and every Mac OS version on the way upgrading from previous versions.