(jeffa) 3Re: Loading a different Module depending on the Configuration

This is for a very mature, stable app, not a quick 15 minute script.

<sarcasm>Heh, he he, ha HA! HAHAHAAHA!</sarcasm>

Seriously, what school of Software Engineering did you graduate from - do you really think that using a Factory Pattern is something that a script kiddie would come up with? It's a very common Design Pattern.

i do appreciate your desire to write your app 'The Right Way' - i really do, but sounds to me like you are too worried about 'false optimization' - imagine a interstate with a lovely 8 lane bridge that has been carefully constructed to maximize car flow ... only to be followed 2 miles down the road by a one lane bridge that you have no control over - that's false optimization.

You have a lot of good clues here on this thread on how to solve your problem - take these ideas and run with 'em! Sounds to me like a factory pattern, or as dragonchild called it, a 'polymorphic constructor' - is a pretty valid idea for this problem. If you don't like that - then you might want to rack your brain against an Abstract Factory.

But as for being concerned about loading subclasses that won't be used for a particular run of the app - do you _really_ need to concern yourself with that? And even if you do - doesn't that sound like a job for the _next_ version? (nudge, nudge) ;)

jeffa

Comment on (jeffa) 3Re: Loading a different Module depending on the Configuration

Replies are listed 'Best First'.
Re: (jeffa) 3Re: Loading a different Module depending on the Configuration by skazat (Chaplain) on Sep 28, 2001 at 01:21 UTC
Seriously, what school of Software Engineering did you graduate from I'm 20 years old and going for a Bachelors in Fine Arts, I think I'm doing pretty well, I've never taken a CS class and I barely passed Algerbra 2 in High School. I have interesting ways of solving things. It seems to me that loading up each and every module that could be used is wasteful, also since I want to allow n number of different DB schemes. I'm going to solve this problem in a similar manner as AnyDBM_File does, since it pretty much has the exact mechanism that I'm looking for. I probably should have mentioned that each scheme to do the dirty work is a bit more complext than fetch() store(), there's also searches and thingies that actually print and return interesting things. do you _really_ need to concern yourself with that? And even if you do - doesn't that sound like a job for the _next_ version? (nudge, nudge) This could theoretically be the next version, although this particular app version has been going on heavy development since the .0 release last July (2000) . There is absolutely no way I'm starting from scratch, alone on a 1 meg program written in Perl I talked to my accountant (my wallet and my college bill) and thought that if I could release, say a totally Open Source and Free version of this particular program, making the Base Module LGPL'd, have a plain text version GPL'd and have, say a Postgres or MySQL version proprietary (ie, sell the SQL version) I could help myself out, and at the same time, make the transition relatively painless, if I decide to just go with a SQL backend. A pluggable achitecture will also allow other developers to create their own solutions and that'll keep the vitality alive for the program itself. I may draw pretty pictures all day, but you get a lot of thinking done in the process :) -justin simoni !skazat!	[reply]

Replies are listed 'Best First'.

Re: (jeffa) 3Re: Loading a different Module depending on the Configuration
by skazat (Chaplain) on Sep 28, 2001 at 01:21 UTC

Seriously, what school of Software Engineering did you graduate from

It seems to me that loading up each and every module that *could* be used is wasteful, also since I want to allow n number of different DB schemes.

I'm going to solve this problem in a similar manner as AnyDBM_File does, since it pretty much has the exact mechanism that I'm looking for.

I probably should have mentioned that each scheme to do the dirty work is a bit more complext than fetch() store(), there's also searches and thingies that actually print and return interesting things.

do you _really_ need to concern yourself with that? And even if you do - doesn't that sound like a job for the _next_ version? (nudge, nudge)

This could theoretically be the next version, although this particular app version has been going on heavy development since the .0 release last July (2000) . There is absolutely no way I'm starting from scratch, alone on a 1 meg program written in Perl

I talked to my accountant (my wallet and my college bill) and thought that if I could release, say a totally Open Source and Free version of this particular program, making the Base Module LGPL'd, have a plain text version GPL'd and have, say a Postgres or MySQL version proprietary (ie, sell the SQL version) I could help myself out, and at the same time, make the transition relatively painless, if I decide to just go with a SQL backend. A pluggable achitecture will also allow other developers to create their own solutions and that'll keep the vitality alive for the program itself.

I may draw pretty pictures all day, but you get a lot of thinking done in the process :)

-justin simoni
!skazat!

[reply]