Design Question

[Guest]

Hello,

I have several manuals for which I'm developing a query tool. There will be
others that need to be plugged in sometime in the future. To streamline the
integration of those manuals in the future, I would like to make my interface
seemlessly know all the manuals currently available at any given time. I have
what I think is a pretty good foundation design but it lacks the ability to
use intellisense and I'd like advice on how to approach this issue.

I currently have developed a DLL project that contains properties and
methods generic across all manuals. I've also developed a DLL project for
each of the individual manuals to handle properties and methods unique to a
given manual.

The generic project has virtual classes with mustinherit methods and
protected properties. Those classes will be inherited by each of the manual
specific project classes.

I think the best way to seemlessly integrate new manuals if by using
createobject with the progid of the user specific manual stored in an xml
file. So, I use CreateObject to instantiate the manual specific classes into
a variable of the generic class type to get intellisense help with the
properties and methods that are consistent across all manuals. Because I get
the combo boxes loaded via an xml file and other important information, such
as the progid for the CreateObject from the xml file, I have architected this
app to seemlessly accept manuals as they are developed.

Unfortunately, because I use CreateObject for the manual specific classes, I
can't seem to design an architecture that will provide me the seemless
integration and the intellisense for development.

Any advice?

Jack

 

[Chris Dunaway]

I think you would be better served by creating an Interface and have
each of the specific manual .dll's implement that interface.

That makes it easy to add more manuals and the app does not have to be
recompiled to be able to load those .dll's. Also, since the app
references the interface, you get intellisense when working with the
interface.

Instead of using CreateObject, you just dim an object of the Interface
type.

For example:

'Interface definition
Public Interface IManual
sub ShowManual()
End Interface

'Manual 1 .dll
Public Class Manual1
Implements IManual

Public Sub ShowManual() Implements IManual.ShowManual
'Code to show manual here
End Sub
End Class


'In the app, you can use this code:

Dim Manual as IManual 'Note it is using the Interface here

'Code to load the .dll with the correct manual and assign it to the
Manual variable

Manual.ShowManual


You can use reflection to query .dll's to see if they implement the
interface or you could have a folder which contains all the manual
..dll's and just load them from there.

Hope this helps

Chris

 

[Guest]

Thanks for the response, I appreciate it.

That sounds promising. The only thing is that using interfaces will require
me to create a new one everytime a manual with unique properties and/or
methods is added to the application. Thus the application will need to be
recompiled each time a new manual is added. Am I reading your suggestion
correctly?

 

[Chris Dunaway]

You might wish to check out the Adapter design pattern. I think you
could define a common interface that would handle the majority of the
manuals but for those that require special treatment, use the Adapter
pattern to create a dll that can translate between the interface and
the manuals that have non standard interfaces.

Without knowing more about how the manuals differ, it's difficult to
visualize.

 

[Guest]

I'll check into it. Thanks a lot for your advice. I really appreciate it!