 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / September 2005Lot of classes
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 > 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. [quoted text clipped - 9 lines] > 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.  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too 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 ernesto bascón pantoja <ebasconp@gmail.com> wrote: > I am writing an application that will handle plugins, every plugin will > have [quoted text clipped - 12 lines] > 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. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too > 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? SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too >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 SignatureMattias Sjögren [MVP] mattias @ mvps.org http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com Please reply only to the newsgroup. Hi Mattias: >>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 [quoted text clipped - 3 lines] > > 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. [quoted text clipped - 3 lines] > 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. > Mattias Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.