Polymorphism using DLL Declares?

  • Thread starter Vince Castellano
  • Start date

V

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
 
Ad

Advertisements

G

Guest

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?
 
T

Tom Shelton

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.
 
V

Vince Castellano

[...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.

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
 
Ad

Advertisements

T

Tom Shelton

[...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.

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top