Polymorphism and inheritance patterns in VB

[Steve Jorgensen]

The classing Visual Basic and VBA support for polymorphism, let's face it, is
a bit on the weak side, and built-in support for inheritance is non-existent.
This little essay is about some patterns I've ended up using successfully for
certain kinds of inheritance and polymorphism, and some that have not worked
out so well.

Let's start with obvious things that turn out not to work well:
1. Use interface classes and "Implements " for polymorphism:

At first glance, this seems like a fine choice. After all, in languages like
Java, interface implementation is used by most programmers at least as often
as inheritance, and is better than inheritance for many things. Also, using
interfaces allows for polymorphism without breaking type safety. Alas, in VB
things are not as good as they at first appear.

As it turns out, interfaces and Implements are useful sometimes in limited
circumstances, but the way they work in VB makes them often take extra effort
to maintain and makes them behave unpredictably in many circumstances.
First of all, rather than simply requiring that all the interface members be
implemented and making them visible through the interface like Java would do,
VB requries you to explicitly create an implementation of each method for each
interface using a qualified name. Each of these is then a separate method
that can its own different implementation (oh what a tangled web that could
be), and to make all cases act the same (like you want about 100% of the
time), you must explicitly call one central method from each of the interface
implementations fo the case.

Now, if that weren't bad enough, you'd best be careful never to mix early
binding and late binding code on the same classes in the wrong order because
if you set an Object variable equal to a variable of an interface type, the
object behaves as an instance of the interface it was in before you assigned
it. In other words, even though it is now housed in an Object variable, you
can't access any members or attributes of the object other than the ones
exposed through the last interface it used as before it went -in- to the
Object variable. What a mess.
2. Using composition and delegation to simulate inheritance:

Since you can't have one class implicitly inherit from and extend another, the
next thing that comes to mind is to create an "inheriting " class that exposes
the same methods as and contains an instance of the parent class, then
forwards calls to the contained "parent" from any method that is not supposed
to override the parent behavior.

In practice, this is a seious hassle. If you use interfaces, the compiler
will tell you when a change to the parent necessitates a change to the
"inheriting " class, but with all the overhead of interfaces discussed above.
If you use late binding and no interfaces, then you don't have the hassle, but
you also don't have the compiler forcing you to update the inheriting classes
when a parent changes, and it can be a lot of effort tracking them down. As a
final blow, you can't inherit and override anything private to the "parent"
class.
Next, for some things that often do work well.

1. Using late binding for polymorphism:

Rather than using interfaces, you can simply allow code to use instances of
certain classes polymorhically by storing everything in a simple Object
variable.

This technique does have some notable down-sides, but the up-sides can often
outweigh it. The biggest down-side is that the compiler can't make sure that
only classes that follow a particular interface can be passed to procedures
that expect to use that interface. If it breaks, it will break at run-time.
The big up-side is that it doesn't require much code overhead at all.

If there's a part of your code that's really begging for a large number of
classes to be used interchangeably by some procedures, this may be a good way
to go. To mitigate the down-sides, try to make sure code that's written this
way will pass instances of every class that might be passed, and call
everything that might be called one each one early in testing. That way, if
you do break something, you'll know about it before you deploy it. If
necessary, write some automated tests as insurance, and run them before each
deployment.
2. Use inverted containership (I believe my way of doing this is a version of
the "Decorator Pattern").

In this pattern, you implement something resembling inheritance by having one
class that always acts as the interface layer, and its run-time behavior is
determined by what kind of class instance it is encapsulating at run-time. In
other words, you might "decorate" a clsQuery class by supplying it with an
instance of clsInvoiceLineQ uerySpec. clsQuery provides the publicly
accessible interface, and clsInvoiceLineQ uerySpec has method signatures
clsQuery understands that provide the clsQuery instance with specific data
constants and procedures that enable it to operate in a specific context (e.g.
a SQL string).

Note that in this case, it can be somewhat practical to use an "Interface" for
the specific classes to define what they must make available to the general
interface class. The specific classes might never need to be accessed any
other way than through that interface, so there are no ambiguities or wrapped
calls to worry about.

3. Instances as "classes":

In many cases, it is sufficient to customize the behavior of an object through
initialization data alone. In this case, you can have a public function that
initializes an object with the correct data, and returns it. A form of
inheritance can be implemented in this scheme by supplying each class with a
Clone procedure, so you can clone one and extend or modify its behavior to
handle a more specific case.

For instance, let's say I have a class clsQuery that gets all its behavior
from the values of members called ParametersClaus e, SelectList, FromClause,
WhereClause, GroupByClause, and HavingClause. Now, let's say you provide a
public function called InvoiceLineQuer y that initializes a clsQuery instance
with SelectList = "tblInvoiceLine s.*" and FromClause = "tblInvoice s". Now,
you have an object that can query the entire tblInvoiceLines table.

Now, implement another function called InvoiceLinesFor Invoice that calls
InvoiceLineQuer y to get an instance, then sets ParametersClaus e =
"prmInvoice Id Long" and WhereClause =
"tblInvoiceLine s.InvoiceId=prm InvoiceId". This instance can be used to query
just the lines for a particular invoice.

As you can see, this can be a reasonably useful sort of real inheritance.
Note that .NET does similar things with the WindowsForms model. Each
WindowsForm object is constructed at run-time, but the code structures that do
the construction allow for a sort of inheritance by sequential addition of
items to the form's collections. I believe this is another sort of
implementation of the "Decorator Pattern".

[Steve Jorgensen]

Hi Jim,

....

http://www.exciton.cs.rice.edu/JavaR...egyPattern.htm

I really like this idea. Can you post code for a small example?
Thanks,
JAF
I finally got time to make up a little example for ya in addition to the one
RKC posted. This is not air code - it's tested and it works, though it is
obviously missing some error handling it would need for use in a production
app.

=== Module: basTestLogWrite r
Option Compare Database
Option Explicit

Public Sub TestTxtFileLogW riter()
Dim objWriterStrate gy As New clsLogWriterTxt FileStrategy

objWriterStrate gy.FilePath = CurrentProject. Path & "\" & _
"LogWriterTest. txt"

WriteLogData objWriterStrate gy

End Sub

Public Sub TestTableLogWri ter()
Dim objWriterStrate gy As New clsLogWriterTab leStategy

With objWriterStrate gy
.DbFilePath = CurrentProject. Path & "\" & _
"Log Writer Test Output.mdb"
.TableName = "tblLogEntr y"
.FieldName = "LogEntryTe xt"
End With

WriteLogData objWriterStrate gy

End Sub

Private Sub WriteLogData(Wr iterStrategy As ILogWriterStrat egy)
Dim objWriter As New clsLogWriter

objWriter.Setup WriterStrategy
objWriter.OpenL og

With objWriter
.WriteMessage "Test message 1"
.WriteMessage "Test message 2"
End With

objWriter.Close Log

End Sub

=== Module: clsLogWriter
Option Compare Database
Option Explicit

Private mobjStrategy As ILogWriterStrat egy

Public Sub Setup(Strategy As ILogWriterStrat egy)
Set mobjStrategy = Strategy
End Sub

Public Property Get Strategy() As ILogWriterStrat egy
Set Strategy = mobjStrategy
End Property

Public Sub OpenLog()
Strategy.OpenLo g
End Sub

Public Sub CloseLog()
Strategy.CloseL og
End Sub

Public Sub WriteMessage(Me ssage As String)
Dim strFormattedMsg As String

strFormattedMsg = FormatMessage(M essage)
Strategy.WriteF ormattedMsg strFormattedMsg

End Sub

Private Function FormatMessage(M essage As String) As String
Const cstrTimestampFo rmat = "yyyy-mmm-dd hh:nn a/p"
Dim strTimestamp As String

strTimestamp = Format(Now, cstrTimestampFo rmat)
FormatMessage = BulletChar & " " & _
strTimestamp & ": " & _
Message
End Function

Private Function BulletChar() As String
BulletChar = Chr$(149)
End Function

=== Module: ILogWriterStrat egy
Option Compare Database
Option Explicit

Public Sub OpenLog()
End Sub

Public Sub CloseLog()
End Sub

Public Sub WriteFormattedM sg(Message As String)
End Sub

=== Module: clsLogWriterTxt FileStrategy
Option Compare Database
Option Explicit

Implements ILogWriterStrat egy

Public FilePath As String

Private mintFileNum As Integer

Public Sub ILogWriterStrat egy_OpenLog()
mintFileNum = FreeFile
Open FilePath For Output As mintFileNum
End Sub

Public Sub ILogWriterStrat egy_CloseLog()
Close mintFileNum
End Sub

Public Sub ILogWriterStrat egy_WriteFormat tedMsg( _
Message As String _
)
Print #mintFileNum, Message
End Sub

=== Module: clsLogWriterTab leStategy
Option Compare Database
Option Explicit

Implements ILogWriterStrat egy

Public DbFilePath As String
Public TableName As String
Public FieldName As String

Private mdbsLogDb As DAO.Database
Private mrstLogTable As DAO.Recordset

Public Sub ILogWriterStrat egy_OpenLog()
Set mdbsLogDb = Workspaces(0).O penDatabase(DbF ilePath)
Set mrstLogTable = mdbsLogDb.OpenR ecordset(TableN ame, _
dbOpenDynaset, _
dbAppendOnly)
End Sub

Public Sub ILogWriterStrat egy_CloseLog()
mrstLogTable.Cl ose
mdbsLogDb.Close
End Sub

Public Sub ILogWriterStrat egy_WriteFormat tedMsg( _
Message As String _
)
mrstLogTable.Ad dNew
mrstLogTable(Fi eldName) = Message
mrstLogTable.Up date
End Sub
On 16 Dec 2004 10:32:46 -0800, ji********@comp umarc.com wrote:

Steve Jorgensen wrote:

On Thu, 16 Dec 2004 02:12:53 GMT, rkc

<rk*@rochester .yabba.dabba.do .rr.bomb>

wrote:

OK, I get it now. From what I can tell, the pattern I'm describing

most

closely resembles the "Strategy Pattern".

http://www.exciton.cs.rice.edu/JavaR...egyPattern.htm

I really like this idea. Can you post code for a small example?
Thanks,
JAF

[rkc]

Steve Jorgensen wrote:

Hi Jim,

...

http://www.exciton.cs.rice.edu/JavaR...egyPattern.htm

I really like this idea. Can you post code for a small example?
Thanks,
JAF

I finally got time to make up a little example for ya in addition to the one
RKC posted. This is not air code - it's tested and it works, though it is
obviously missing some error handling it would need for use in a production
app.

Usefull example. It's pretty clear how it could be easily extended to
write to an XML file, another database or even an spreadsheet.
You also got the handling of the data in the context class
(clsLogWriter)w here it belongs. I got that wrong. Not sure why you
expose Private mobjStrategy with a property get though.

The file setup code in the test module is ugly, but then I realized
in real life you would probably handle that in the strategy classes
via config data stored outside the application code.

[Steve Jorgensen]

On Mon, 20 Dec 2004 01:06:06 GMT, rkc <rk*@rochester. yabba.dabba.do. rr.bomb>
wrote:

Steve Jorgensen wrote:

Hi Jim,

...

http://www.exciton.cs.rice.edu/JavaR...egyPattern.htm

I really like this idea. Can you post code for a small example?
Thanks,
JAF

I finally got time to make up a little example for ya in addition to the one
RKC posted. This is not air code - it's tested and it works, though it is
obviously missing some error handling it would need for use in a production
app.

Usefull example. It's pretty clear how it could be easily extended to
write to an XML file, another database or even an spreadsheet.
You also got the handling of the data in the context class
(clsLogWriter) where it belongs. I got that wrong. Not sure why you
expose Private mobjStrategy with a property get though.

That was a case of "I needed it last time, so..." Frankly, I don't remember
why I need a public Strategy member, so I probably should have left it out
until the need arises again.
The file setup code in the test module is ugly, but then I realized
in real life you would probably handle that in the strategy classes
via config data stored outside the application code.

Pretty much, yeah. This was the minumum code I thought I could write that
would fully demonstrate the template pattern, and why it would be useful.