what is this design pattern?

[soupy]

this was originally posted here http://lavag.org/topic/17852-what-is-this-design-pattern/

i'm doing something, but i don't know what to call it. is this an accepted design pattern? any caveats?

background:

• i have a configuration class for my application
• the configuration class contains paths to external (excel) files
• you must parse out the external files and put their information back into the configuration class. i refer to this step as "parsing"
• i'm passing the parsed configuration class over the network to an RT system, so my configuration class can't have any dependencies to non-RT stuff (e.g. Excel (ActiveX))
• everything is dynamic dispatch so i can get some reuse out of this design pattern

explanation:

• in this example, i have an array of configuration classes
• all parsing functions are in methods of a "parser" class (chain link wire)
• there is one parser class for each configuration class
• the configuration class knows the path to the parser class

So, does anyone have an official name for this sort of thing? I've been referring it as "side loading". Anyone have any lessons learned on this approach? Am i running head first into any traps?

[David_Staab]

Could you provide a UML class diagram to help us understand what you're describing? Natural language isn't working for me here.

[soupy]

oh man. UML isn't going to do us much good here since the config and parser classes are decoupled. here is a more generic example of what i'm trying to do

[PaulLotz]

OK, can you clarify: Are you sending the data over the network as objects only because the RT system can't call Excel, or is there another reason?

(In other words, an RT app can read a .csv, .xml, or other file, so that you could copy the configuration files themselves to the RT side.  This isn't necessarily better--well, you gain independence of the RT side at the cost of duplicating files--but I am trying to understand better what your goals are.)

Also, just to be sure, Parser.parse() presumably opens the file, parses the information, and stores the data in the worksheetData attribute of the Config class.  Then the application serializes the Config class and sends it to the RT side.  Yes?

OK, one more thing.  You say the config and parser classes are decoupled, but the code shows a cast to a Parser class, and earlier you wrote that, "there is one parser class for each configuration class".  Does Parser have children, or simply different instantiations (objects)?

[soupy]

1) yes, because the RT system can't parse excel. we'd love to do it a different way, but we're dealing with a volume of legacy configuration files and this is the less risky option (versus refactoring, revalidating, etc.).

2) yes. 100% correct

3) each config class has a corresponding parser class. the class heirarchy of these two classes are mirrored. the parent of the parser class would correspond to the parent of the config class being parsed. The interface for parser.parse() will be the same for all parser classes. you'll have to internally cast cfg to the correct class.

Note that this being used in an upgrade to an existing sytem to get it ready for RT compatibility. our application currently runs on windows servers and is not compatible with RT due to the use of activex (for parsing excel). we think that the shortest path to success is to move config parsing over the network to a GUI running on a windows machine. Recoding should be less risky than refactoring 150MB of excel config files and 100+ trained users.

[PaulLotz]

OK, I think that it is probably OK for the reasons you state to do the reading and parsing on the nonRT side and then send the data to the RT side as you are doing.  The only thing to keep in mind is that then the RT system must have the nonRT view code running to operate.  That's probably not a serious drawback in your situation.  Good!

The mirrored hierarchies one might build via the Bridge Pattern (which I haven't used before, so I can't say much about).  Are you doing something like that?

The follow-up on the Config/Parser relationship is where do you do the casting?  I take it this must be in a layer/class in the nonRT application that knows about the particular Config and Parser classes, so that the Config class (which can run on RT) does not have any link to the Parser class.

[OK, your Config class, from what you have shown so far, only encapsulates data.  Are there any methods besides accessor methods?  If not, you could (definitely not saying you should) replace the class with a cluster of the same name.  This is only mildly relevant to the discussion. I just want to make sure I understand the role of Config correctly.  Well, the other thing is that the only thing that the RT application really needs, perhaps, is the worksheet_data string.]

It seems, then, the interesting part of the question is on the nonRT side, in that the Config and Parser classes have a relationship, and a third party (another class) must know about and maintain this relationship (and assemble the appropriate Config and Parser objects).  Presumably this third class could even have a collection of Config and another collection of Parser classes in its class private data.  Anyway, without knowing more, I would suggest taking a look at the Bridge Pattern, to see if it kind of matches what you are doing--or at least the intent.  (The Builder and Abstract Factory patterns are also of interest in this context.  I have yet to use any of these in my actual applications, so I won't be able to say much more about them right now.)