How To Manage Library Functions

  • Thread starter Thread starter Jeff Gaines
  • Start date Start date
J

Jeff Gaines

I have set up a number of frequently used functions in separate
classes in a folder called 'Jlib'. Each class is in its own file all
with the Namespace 'Jlib'.

To avoid duplication they often refer to other classes in the same
folder, i.e. my file functions are in a class called JGFF in their own
file. However some of the JGFF functions rely on, say, a DLL prototype
whose definition is in a class called JGAPI which is in its own file.

This all works fine in testing but when used in an app I have to set
up a link to both JGFF and JGAPI. Ideally I would like to just set up
a link to JGFF and have that automatically find/refer to JGAPI.

The solutions I have come up with are:
build all the functions into a DLL and use that - it works but it is
quite a large DLL.
put all the classes in to one file - I guess that would work but it
would be unwieldy.
Make each class self contained - but that leads to lots of
duplication.

Does anybody have any other suggestions/thoughts on a layout/structure
that would only require one reference in an app?
 
Jeff,

The only way I can think to get around this would be to use a class
factory pattern of some sort. Basically, you would have a class in the one
referenced assembly which would create the instances of the classes for you.

On top of that, you would have to create interface definitions/base type
definitions all in that one assembly. These would be needed so you can cast
the objects returned from the class factory.

Because of this, the assembly referenced would have to load the
implementations dynamically, and not set a reference (because you can not
have circular references).

It can be done, but would require a lot of work.

Hope this helps.
 
Jeff,

The only way I can think to get around this would be to use a class
factory pattern of some sort. Basically, you would have a class in the one
referenced assembly which would create the instances of the classes for you.

On top of that, you would have to create interface definitions/base type
definitions all in that one assembly. These would be needed so you can cast
the objects returned from the class factory.

Because of this, the assembly referenced would have to load the
implementations dynamically, and not set a reference (because you can not
have circular references).

It can be done, but would require a lot of work.

Hope this helps.
Click to expand...

Nicholas

Many thanks for that, I think it's probably a bit complex for home
use, a pity we don't have '#include' or Delphi's 'uses' :-))

I've gone the DLL route for now. It was 'only' 75k and by including it
in all my apps I have immediate access to all my frequently used
functions.

Thanks again.
 
Back
Top