Implementing another interface

To get another view on this strange phenomenon, let’s look at another implementation of IFilter. Like Bug Wizard, Global Wizard does several conversion operations. But unlike Bug Wizard, it handles each operation with a separate IFilter class rather than a Select Case block.

We’ll look at a typical global conversion class, CModGlobDelFilter. The Source and Target properties are implemented exactly the same as for CBugFilter, so we’ll skip to Translate:

‘ Great big, long, complex state machine all in one ugly chunk
Private Function IFilter_Translate(sLine As String, _
                                   ByVal iLine As Long) As EChunkAction
§

That comment looks so intimidating that we’ll just skip over what a global class is and how you might convert one until Chapter 5. The important point is that IFilter_Translate will convert each line of one, count the line numbers, and return an indicator of what it did.

CModGlobDelFilter, like all of the other Global Wizard filter classes, has a Name property, which I won’t show because it’s simply the classic Get/Let property procedure pair wrapping an sName variable. The Name property is a property of the class, not of the IFilter interface. But its internal sName variable is visible inside the class to the implementation of the interface Translate method.

Hmmm. These conversion classes are all polymorphic through the IFilter class. But they also all have a Name property with the same String type. That’s dumb polymorphism. Why would anybody want to do that?