CODEWITHSUNDEEP
vb.netvisual-studiodllinterfaceinstantiation
gutisg
gutisg

Reputation: 73

Creating 2 DLLs sharing an Interface on Visual Basic, is it possible/good idea?

I'm designing a Visual Basic application on that uses one DLL created also by me (both on Visual Studio). In the app, there's an object that instantiates one class defined by the DLL.

Friend WithEvents robot As New DLL1class

There are new needs on the project so this object should be able to instantiate one class from a different new DLL. Since I am designing this new DLL, I want to make this change transparent to the app, so it is the same for me to do:

Friend WithEvents robot As New DLL1class

OR

Friend WithEvents robot As New DLL2class

My idea is to create an Interface IOperations and make two DLLs implement it, so there are no problems on the code.

Since I NEED to instantiate the object during runtime, my question is, which class should I create it with?

Friend WithEvents robot As ¿?¿?¿?
' ...
If xxxxx Then
    robot = New DLLXClass
End If

I don't want to use As Object because during programming you do not see the list of functions when you write robot. and the code and DLL functions are too complex to accept this.

Is there any way I can define an object that implements an Interface? Something similar to this idea:

Friend WithEvents robot As ClassX "that implements IOperations"

If you think there is a better way to afford this problem it's OK to me! Since I think it could be a question you make: yes, it is necessary to use DLLs because we need to send them to external people that use the DLL on their own applications.

Upvotes: 2

Views: 1016

Answers (1)

Steven Doggart
Steven Doggart

Reputation: 43743

You need to declare the variable as the interface rather than as one of the concrete classes, for instance:

Friend WithEvents robot as IOperations

Now, the robot variable can reference an object of any type that happens to implement that interface. Next, you need to conditionally set the robot variable to the correct type of object depending on the situation. For instance, in the constructor, you could do something like this:

If UsingDll1 Then
    robot = New DLL1class()
Else
    robot = New DLL2class()
End If

As long as both of those classes implement the IOpertions interface, it will compile and work correctly.

Rant

Now it's time for my DI rant. If you don't care what I think, skip this part :)

Having the class create its own dependencies like this is bad practice. As the project grows, it will become more and more complicated and it will lead to spaghetti-code. The way to avoid that is to use dependency-injection (DI). For instance, in this case, you could design your class like this:

Public Class MyClass
    Public Sub New(robot As IOperations)
        Me.robot = robot
    End Sub

    Friend WithEvents robot as IOperations
End Class

Now, rather than creating it's own robot object, the class requests that the robot be given to it. In that way, it's dependency (the robot) is injected into it.

Think of it this way: if you have a car class, should it create it's own engine object? In real life, does a car create it's own engine, or is it given one by the car factory? Just as creating a car that can create it's own engine would be very complicated and silly, having classes create their own dependencies is complicated and silly.

Upvotes: 1

Related Questions