Polymorphism using DLL Declares?

[Vince Castellano]

Hello,

I have a set of DLLs that implement different configurations of the
same API. Consider them as first.dll, second.dll, and third.dll. They
all share a common API, calling pattern, and have the same logic to
handle the calls. Calls in the VB.net code does not call the DLLs
directly, but rather a custom dll wrapper class, so that the logic can
be made for the VB code in the abstraction class.

Initially, my idea was to create a superclass that contained
MustOverride prototypes for the DLL calls, and the VB public apis
implemented in this class. Then have 3 concrete classes FirstDll,
SecondDll, and ThirdDll, and have the Declares override the DLL api
calls, and just inherit the VB public API. This did not work however
as
you can not specify Declares as overrides.

Second, I attempted to implement the Strategy pattern, by creating an
interface called DllAPI which had the DLL prototype Declares as
methods, then create 3 concrete classes implementing the interface
with
their respective declares. Then create GlobalAPI class that contained
all the public VB APIs, and contains a reference to a DllAPI object,
which polymorphically is the proper DLL type, and delegate DLL calls
to
that object. This did not work either however as you cannot use
Declares to implement an interface.

What is the right way to do this, as to not have to maintain duplicate
VB public API information in multiple classes that are 95% the same?
Normally I would not seek asking such questions, as they are design
issues, but everything I try seems to be constrained by VB limitations
(with or without good reason), so I am hoping someone else has solved
this issue.

Thank you,
Vincent Castellano

[Spam Catcher]

"Vince Castellano" <su*****@gmail.comwrote in
news:11**********************@m58g2000cwm.googlegr oups.com:

What is the right way to do this, as to not have to maintain duplicate
VB public API information in multiple classes that are 95% the same?
Normally I would not seek asking such questions, as they are design
issues, but everything I try seems to be constrained by VB limitations
(with or without good reason), so I am hoping someone else has solved
this issue.

Are you trying to build a Plug-In system?

[Tom Shelton]

On Feb 2, 4:33 pm, "Vince Castellano" <[e-mail]:

Hello,

I have a set of DLLs that implement different configurations of the
same API. Consider them as first.dll, second.dll, and third.dll. They
all share a common API, calling pattern, and have the same logic to
handle the calls. Calls in the VB.net code does not call the DLLs
directly, but rather a custom dll wrapper class, so that the logic can
be made for the VB code in the abstraction class.

Initially, my idea was to create a superclass that contained
MustOverride prototypes for the DLL calls, and the VB public apis
implemented in this class. Then have 3 concrete classes FirstDll,
SecondDll, and ThirdDll, and have the Declares override the DLL api
calls, and just inherit the VB public API. This did not work however
as
you can not specify Declares as overrides.

Second, I attempted to implement the Strategy pattern, by creating an
interface called DllAPI which had the DLL prototype Declares as
methods, then create 3 concrete classes implementing the interface
with
their respective declares. Then create GlobalAPI class that contained
all the public VB APIs, and contains a reference to a DllAPI object,
which polymorphically is the proper DLL type, and delegate DLL calls
to
that object. This did not work either however as you cannot use
Declares to implement an interface.

What is the right way to do this, as to not have to maintain duplicate
VB public API information in multiple classes that are 95% the same?
Normally I would not seek asking such questions, as they are design
issues, but everything I try seems to be constrained by VB limitations
(with or without good reason), so I am hoping someone else has solved
this issue.

Thank you,
Vincent Castellano

Vincent...

If I understand what your trying to do, then there are a couple of
ways to go about this. If your only talking the 3 dll's, then I would
probably declare a public MustInherit (abstract) class in a class
library that exposed the api to your client application. In side, I
would create three concrete classes that contained the declares for
each dll, but had an internal constructor. These classes could be
created then by either a factory method, or you might use something
like an abstract factory pattern.

If all the calling sequences are the same, then something like the
template method pattern would be perfect for you. Simply put the
calling sequences in the public api of the MustOverride class, and
then put some protected MustOverride (abstract) methods to actually
call the api calls. Each concrete class would then call the correct
api. It would look some thing like:

Public MustInherit Class PublicApi
Public Sub DoCoolStuff1 (ByVal aParameter As String)
' do stuff
' do more stuff
Dim somevalue As Integer = DoAnApiCall(aParameter)
' do more stuff
Return
End Sub

Protected MustOverride Function DoAnAPICall (ByVal aParameter As
String) As Integer

End Class

Public Class ConcreteImplementation1
Inherits PublicAPI

Private Declare blah lib "dll1.dll"....

Friend Sub New ()
End Sub

Protected Override Function DoAnAPICall (ByVal aParameter As
String) As Integer
return blah (aParameter)
End function
End Class

Public Class ConcreteImplementation2
Inherits PublicAPI

Private Declare blah lib "dll2.dll"....

Friend Sub New ()
End Sub

Protected Override Function DoAnAPICall (ByVal aParameter As
String) As Integer
return blah (aParameter)
End function
End Class

The client would do this:
Dim api As PublicApi = PublicApi.GetImplementation ()
api.DoCoolStuff1("Hi")

The other method I can think of is to dyanmically load the dll
(loadlibrary api call) and then to generate the calling class on the
fly using System.Reflection.Emit. Though, unless you are planning to
have a bunch of implementations or there could be more in the future,
I probably wouldn't go this way. I've seen examples around, so I'm
sure you could google and find some code on this topic... Anyway,
good luck.

--
Tom Shelton

[Vince Castellano]

On Feb 2, 9:00 pm, "Tom Shelton" <[e-mail]:

On Feb 2, 4:33 pm, "Vince Castellano" <[e-mail]:

[...cut...]

Vincent...

If I understand what your trying to do, then there are a couple of
ways to go about this. If your only talking the 3 dll's, then I would
probably declare a public MustInherit (abstract) class in a class
library that exposed the api to your client application. In side, I
would create three concrete classes that contained the declares for
each dll, but had an internal constructor. These classes could be
created then by either a factory method, or you might use something
like an abstract factory pattern.

If all the calling sequences are the same, then something like the
template method pattern would be perfect for you. Simply put the
calling sequences in the public api of the MustOverride class, and
then put some protected MustOverride (abstract) methods to actually
call the api calls. Each concrete class would then call the correct
api. It would look some thing like:

Public MustInherit Class PublicApi
Public Sub DoCoolStuff1 (ByVal aParameter As String)
' do stuff
' do more stuff
Dim somevalue As Integer = DoAnApiCall(aParameter)
' do more stuff
Return
End Sub

Protected MustOverride Function DoAnAPICall (ByVal aParameter As
String) As Integer

End Class

Public Class ConcreteImplementation1
Inherits PublicAPI

Private Declare blah lib "dll1.dll"....

Friend Sub New ()
End Sub

Protected Override Function DoAnAPICall (ByVal aParameter As
String) As Integer
return blah (aParameter)
End function
End Class

Public Class ConcreteImplementation2
Inherits PublicAPI

Private Declare blah lib "dll2.dll"....

Friend Sub New ()
End Sub

Protected Override Function DoAnAPICall (ByVal aParameter As
String) As Integer
return blah (aParameter)
End function
End Class

The client would do this:
Dim api As PublicApi = PublicApi.GetImplementation ()
api.DoCoolStuff1("Hi")

The other method I can think of is to dyanmically load the dll
(loadlibrary api call) and then to generate the calling class on the
fly using System.Reflection.Emit. Though, unless you are planning to
have a bunch of implementations or there could be more in the future,
I probably wouldn't go this way. I've seen examples around, so I'm
sure you could google and find some code on this topic... Anyway,
good luck.

--
Tom Shelton

Hi Tom,

Thank you for the thorough response, it worked great for my situation.
It causes some duplication between different DLL classes, but no logic
code, which is what I wanted to avoid. Between what you said, and my
trusty Gang of Four book, was able to implement the template method
pattern as it fit for this situation well.

Hope this thread sheds light for anyone else in the same situation.

-Vince

[Tom Shelton]

On Feb 5, 4:43 pm, "Vince Castellano" <[e-mail]:

On Feb 2, 9:00 pm, "Tom Shelton" <[e-mail]:

On Feb 2, 4:33 pm, "Vince Castellano" <[e-mail]:

[...cut...]

Vincent...

If I understand what your trying to do, then there are a couple of
ways to go about this. If your only talking the 3 dll's, then I would
probably declare a public MustInherit (abstract) class in a class
library that exposed the api to your client application. In side, I
would create three concrete classes that contained the declares for
each dll, but had an internal constructor. These classes could be
created then by either a factory method, or you might use something
like an abstract factory pattern.

If all the calling sequences are the same, then something like the
template method pattern would be perfect for you. Simply put the
calling sequences in the public api of the MustOverride class, and
then put some protected MustOverride (abstract) methods to actually
call the api calls. Each concrete class would then call the correct
api. It would look some thing like:

Public MustInherit Class PublicApi
Public Sub DoCoolStuff1 (ByVal aParameter As String)
' do stuff
' do more stuff
Dim somevalue As Integer = DoAnApiCall(aParameter)
' do more stuff
Return
End Sub

Protected MustOverride Function DoAnAPICall (ByVal aParameter As
String) As Integer

End Class

Public Class ConcreteImplementation1
Inherits PublicAPI

Private Declare blah lib "dll1.dll"....

Friend Sub New ()
End Sub

Protected Override Function DoAnAPICall (ByVal aParameter As
String) As Integer
return blah (aParameter)
End function
End Class

Public Class ConcreteImplementation2
Inherits PublicAPI

Private Declare blah lib "dll2.dll"....

Friend Sub New ()
End Sub

Protected Override Function DoAnAPICall (ByVal aParameter As
String) As Integer
return blah (aParameter)
End function
End Class

The client would do this:
Dim api As PublicApi = PublicApi.GetImplementation ()
api.DoCoolStuff1("Hi")

The other method I can think of is to dyanmically load the dll
(loadlibrary api call) and then to generate the calling class on the
fly using System.Reflection.Emit. Though, unless you are planning to
have a bunch of implementations or there could be more in the future,
I probably wouldn't go this way. I've seen examples around, so I'm
sure you could google and find some code on this topic... Anyway,
good luck.

--
Tom Shelton

Hi Tom,

Thank you for the thorough response, it worked great for my situation.
It causes some duplication between different DLL classes, but no logic
code, which is what I wanted to avoid. Between what you said, and my
trusty Gang of Four book, was able to implement the template method
pattern as it fit for this situation well.

Hope this thread sheds light for anyone else in the same situation.

-Vince- Hide quoted text -

- Show quoted text -

Glad it worked for you.

--
Tom Shelton