Lot of classes

[ernesto bascón pantoja]

Hi everybody:

I am writing an application that will handle plugins, every plugin will have
a lot of "utilities" that the user can select from and execute.

The first time my application is up, all the plugins are loaded and all its
utilities are loaded in order to get registered into my application.

I am implementing every plugin as an assembly and every "utility" as a
subclass derived from a "Utility" class.

Talking with another developer, he suggested me that I should not create a
subclass for every Utility that I have, because every class has a big
footprint and as my application has a lot of utilities, my overall resource
usage will be dramatically high. Instead of do this, I could implement every
basic utility as subclasses from Utility and create instances of my basic
utilities, passing them delegates that will perform the required job (à la C
programming).

I suppose that the footprint for every class is a little greater than the
lot of methods I will have, but I am not happy with the delegation scheme
(and my class containing all the delegate implementations will be huge).

Any hint, tip or trick will be superhelpful. Saludos




ernesto

 

[Jon Skeet [C# MVP]]

I am writing an application that will handle plugins, every plugin will have
a lot of "utilities" that the user can select from and execute.

The first time my application is up, all the plugins are loaded and all its
utilities are loaded in order to get registered into my application.

I am implementing every plugin as an assembly and every "utility" as a
subclass derived from a "Utility" class.

Talking with another developer, he suggested me that I should not create a
subclass for every Utility that I have, because every class has a big
footprint and as my application has a lot of utilities, my overall resource
usage will be dramatically high.

Why? The footprint from the classes themselves is likely to be
insignificant compared with the *instances* of the classes - and there,
the number of different classes you've got is pretty much irrelevant.

 

[Mattias Sjögren]

Talking with another developer, he suggested me that I should not create a
subclass for every Utility that I have, because every class has a big
footprint and as my application has a lot of utilities, my overall resource
usage will be dramatically high.

How many are "a lot"? Tens, hundreds, thousands?

I wouldn't worry about it unless you have actual profiling and memory
usage data that indicates it's a problem.


Now, if you want to reduce the memory footprint of your app, perhaps
you should consider a design where you don't have to load the plugin
assemblies until they are actually needed. Or will the user actually
use all "utilities"?


Mattias

 

[ernesto bascón pantoja]

Hi Mattias:

How many are "a lot"? Tens, hundreds, thousands?

Maybe thousands (I will have plugins with near one hundred utilities).

I wouldn't worry about it unless you have actual profiling and memory
usage data that indicates it's a problem.


Now, if you want to reduce the memory footprint of your app, perhaps
you should consider a design where you don't have to load the plugin
assemblies until they are actually needed. Or will the user actually
use all "utilities"?

The user will not use all utilities at the same time, but all the utilities
must be instantiated the first time to get registered into the application
data base, so, the next time the application will be executed, only the
really needed plugins will get loaded, but.... what for the first time? I
could provide a kind of "UtilityInfo" class that could contain the
information needed to allow the utility to get registered into my app, but
it makes the utility development more complex, I guess.

 

[ernesto bascón pantoja]

So, do you consider that implement this solution with subclass of Utility
should be a better solution instead of using a lot of delegates?



ernesto

I am writing an application that will handle plugins, every plugin will
have
a lot of "utilities" that the user can select from and execute.

The first time my application is up, all the plugins are loaded and all
its
utilities are loaded in order to get registered into my application.

I am implementing every plugin as an assembly and every "utility" as a
subclass derived from a "Utility" class.

Talking with another developer, he suggested me that I should not create a
subclass for every Utility that I have, because every class has a big
footprint and as my application has a lot of utilities, my overall
resource
usage will be dramatically high.

Why? The footprint from the classes themselves is likely to be
insignificant compared with the *instances* of the classes - and there,
the number of different classes you've got is pretty much irrelevant.

 

[Jon Skeet [C# MVP]]

So, do you consider that implement this solution with subclass of Utility
should be a better solution instead of using a lot of delegates?

I'd use each where it's appropriate. I wouldn't *force* deriving from
Utility though - why not use an interface, then you can derive from
Utility where it makes sense to do so, but implement the interface in a
different way where things are different?