Design Question

[Jack]

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]

Re: Design Question

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.ShowMan ual
'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.ShowManu al


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

[Jack]

Re: Design Question

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" wrote:
[color=blue]
> 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.ShowMan ual
> '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.ShowManu al
>
>
> 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
>
>[/color]

[Chris Dunaway]

Re: Design Question

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.

[Jack]

Re: Design Question

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

"Chris Dunaway" wrote:
[color=blue]
> 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.
>
>[/color]