Re: Overwhelmed by choices of Design Patterns
- From: "Nick Malik [Microsoft]" <nickmalik@xxxxxxxxxxxxxxxxxx>
- Date: Tue, 11 Jul 2006 23:58:25 -0700
<asianmuscle@xxxxxxxxx> wrote in message
news:1152661228.025661.171930@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
thanks for you response...
no this is not a homework just something I need to learn DP while I am
doing something I can resue for other tools in the future.
OK. I assume you are writing in Java then? I ask because I'm a C# person,
so I cannot help with the specifics of your language/platform. This problem
is solved in the C# class library, so while this is an interesting problem
from a DP standpoint, it is pretty useless in actual production. That's why
I assumed it was a homework assignment.
In reply to your question, I call all the settings section:key/value
tuple in ini and from XML element:attribute/value tuple as DATA. Since
I am very new, I am truly sorry for a the hand holding work and my
questions.
I guess I wasn't clear. Config settings do not have to be a simple list of
name-value pairs. You could have substantial heirarchies of information in
your configuration. For example, one app that I used provides a service
host that can call an class that inherits from a simple base type. The
class is called periodically, based on either time or the results of a
database query. The host can support up to about 40 concurrent classes,
each configured differently. The database condition allows for a list of
queries, any of which can be true and if so, the results of which are fed to
the class. The class is not known to the code of the service and is loaded
dynamically at run time. For this app, the configuration looked something
like this:
<service-host>
<service classid="Internal.MyApp.MyExecutor" source="Myapp.dll">
<timecondition period=600 duration=30 timeout=100 />
</service>
<service classid="Internal.MyApp.MyExecutor2" source="Mysecondapp.dll">
<dbcondition checkfrequency=900>
<connection server="DIVECHAMBER" database="DEMO" />
<SQLcondition query="Select au_id, au_name from pubs.authors
where informed=false" minrows=1 passdata=all />
<SQLcondition query="Select Error_id from pubs.errortable where
displayed=false" minrows=1 passdata=all />
</dbcondition>
</service>
</service-host>
It would be pretty difficult to store that well in a name-value pair. That
is why I asked what format the data will be stored in. I don't mean "what
format on disk?" I mean "what data structure will be returned to the
calling app?" In the above code, using built-in features of .Net, you can
return the data already preloaded into an object that contains a list of
service objects which can contain any number of dbconditions or
timeconditions, etc.
I have done a bit of thinking and here is the list:
How data(settings from ini/XML) is used?
--- the client of the configurator most query the data out of the
config file, then do:
1. it compares against some set of range values to see if they are
valida settings, if yes change its own state for further action within
the client
2. client can update the configure file but since not ALL client
will do this. I will keep this as seperate further down the chain. I am
focusing that this is only a configurator that clients reads for its
initial state.
How data is represented?
1. client does not care how the data is represented. As long as it can
correctly query the needed data, client does't care how they are
represented within the CINI class or XML Parser class, or some other
format class. I doubt client should even know about <vector> or <List>
or <hash> inside CINI and XML. But please advise if not.
see above. I asked an incorrect question... to be clear, I meant to ask:
how will the returned data be represented? I was not asking about simple
types (like integer or string) but rather heirarchical types as above. Will
you know this in advance?
Since off-the-shelf parser: CINI and expat already has built-in
container to hold the values, I won't parser those elements again into
another container. I am thinking of using Adapter PAttern.
So after reading more info: I may need to use Adaptor
Pattern at this point. Reasons:
- because CINI and Expat is already provided. The new unknown
probably need to program to that interface.
- from Hudson's link it seems like that there still a close
similarity from the adapter interface and the adaptee interface .. but
I don't think there is much similarity in terms of interface between
existing Parser classes and Configurator interface.
So now I am seeing that there may be a IConfigReader then there is
a IniConfigReader that uses CINI to get the "Data" out
then there is an XMLConfigReader that uses Expat to get the
"Data" out
- the clients only know IConfigReader .. Why all this
suddenly looks a lot like Strategy Pattern? I only see Strategy pattern
has more than 1 "branch" under the Interface. ... Frustrated and
Confused....
It is a strategy pattern if you have only one variation: in this case, the
algorithm used to read the data. If you intend to manipulate all data,
regardless of how it is read, in the same manner, then this works. On the
other hand, if you intend to allow more complex configuration, like that
above, then you will want to dig into the reflection capabilities of your
platform. That will allow you to load types that you were not aware of when
you wrote your code, and will allow you to deserialize data into those types
without first knowing anything about the types themselves.
If you have two variations, for example the tool that reads from the file
and the structure by which the configuration data is returned, then you have
a bridge pattern.
2. How is the data used?
Now your question gets me think about the RETURN data type after
the client queries the Configurator for values:
-- reading from the config file will always return string but
-- Now should the configReader do the conversion from string
to built-in types of:
-- integer, double, float, string, hex, boolean, binary before
giving it back to client?
Or should client do it?
The client will take the value and do comparisons,
seraching, store into some state variable, printing to log etc.
-- Is using Template somewhere a good possbility? Oh
gosh....
This is the fun part, actually.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
.
- References:
- Overwhelmed by choices of Design Patterns
- From: oopstudent
- Re: Overwhelmed by choices of Design Patterns
- From: Nick Malik [Microsoft]
- Re: Overwhelmed by choices of Design Patterns
- From: asianmuscle
- Overwhelmed by choices of Design Patterns
- Prev by Date: Re: Observer pattern limitations
- Next by Date: Re: Observer pattern limitations
- Previous by thread: Re: Overwhelmed by choices of Design Patterns
- Next by thread: Re: Overwhelmed by choices of Design Patterns
- Index(es):
Relevant Pages
|
