"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem in such a way that you can use this solution a million times over, without ever doing it the same way twice" -Christopher Alexander
The core of the solution using .NET to the mapping problem between different concrete classes of a concept (a strategy) could be implemented with the following code, where fully_qualified_type_name is the key to the map of concrete classes: string fully_qualified_type_name=GetNameFrom(xmldocument); Type t=Type.GetType(fully_qualified_type_name); AbstractRootStrategy strategy=Activator.CreateInstance(t) as AbstractRootStrategy; strategy.PerfomItsOperation(); -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Chad Osgood Sent: Sunday, March 27, 2005 10:40 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Most appropriate design pattern to use for ... I wasn't familiar with the "Client-Dispatcher-Server" design pattern until you mentioned it, but after further reading it seems not to fit in this context. Googling around for the pattern found the following definition: "It provides location transparency by means of a name service, and hides the details of the establishment of the communication connection between clients and servers." The first part, "It provides location transparency by means of a name service" sounds to me like a parameterized factory method as described in GoF. It seems to me that that which makes the pattern difference is the "hides the details of the establishment of the communication connection between clients and servers" part; I would call this a service facade or a service layer in casual discussion, but the pattern makes sense. Anyway, given that his intent is to merely decouple the caller and the Strategy of the callee by way of a parameter I believe the parameterized factory method is most appropriate. Please let me know if I am missing something. Kind regards, Chad On Sun, 27 Mar 2005 10:39:05 -0500, Marco Dorantes Martinez <[EMAIL PROTECTED]> wrote: > Kinds of "The Client-Dispatcher-Server Design Pattern" by: P. Sommerlad, > M. Stal. on Pattern Languages of Program Design 2 > > Summary: A dispatcher component is an intermediary between clients and > servers. The dispatcher provides location transparency with a name > service and hides details of the communication connection. > > The point of mapping to a particular strategy object in implementation > could be done like: > > string fully_qualified_type_name=GetNameFrom(xmldocument); > Type t=Type.GetType(fully_qualified_type_name); > AbstractRootStrategy strategy=Activator.CreateInstance(t) as > AbstractRootStrategy; > strategy.PerfomItsOperation(); > > > -----Original Message----- > From: Unmoderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Bill Bassler > Sent: Friday, March 25, 2005 12:07 PM > To: [email protected] > Subject: [ADVANCED-DOTNET] Most appropriate design pattern to use for > ... > > I'm trying to determine the most appropriate design pattern to implement > for the following problem. > > I'm receiving an xml document whose structure contains an element > defining > a source. Each source's document contains a similar but distinct xml > document. Each one of the distinct documents requires a distinct set of > message processing steps. I have implemented the document specific > processing steps/algorithm using the Strategy pattern. This works well > at > cleanly encapsulating the processing logic. > > The issue I'm trying to solve is - What's the most appropriate/cleanest > way > to inspect the source element in order to route the xml message to the > appropriate Strategy for processing. Currently I use a switch statement > to > decide the processing. > > e.g. > > switch > (enrollmentDoc.SelectSingleNod("/EnrollForm/Source").InnerXml.ToUpper > ()) > { > case 1: > // Use Strategy 1 > case 2: > // Use Strategy 2 > } > > This works, but I'm looking for something a little less clunky and > hopefully more modular. I've looked at the Command pattern ... which > seems > to somewhat fit the task. Possibly the Chain of Command but I don't know > that I need that level of processing flexiblity as what I need to do can > be > encapsulated pretty well in the Strategy. > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at http://discuss.develop.com > =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
