Re: Overwhelmed by choices of Design Patterns

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.
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 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.
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....

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....




Nick Malik [Microsoft] wrote:
Interesting. I'm going to assume that this is homework, so I'll respond
with thought points instead of detailed answers. I hope that is OK.

1. you will store section/key/value into a dictionary. This is INI file
thinking. It is interesting that you had to reduce your configuration to
the least common denominator. You have a problem with how data can be
represented, but you also need to consider how the data is used. Will you
make it generic for the use of the data to vary as well? If so, what
pattern allows double-dispatch?

2. What varies and what stays the same? You have format that varies, so the
ability to read the format varies. (a variation on ability... perhaps a
strategy pattern?) Will the structure in which the data is stored also
vary? Will it vary independently of the mechanism to read it? You may want
to look at the bridge pattern to find mechanisms to vary two variables
independently of one another.

Just for fun, if you visit Huston's design patterns page, you will find a
little online quiz that helps to learn the patterns and what they are for.

--- Nick

--
--- 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.
--
"oopstudent" <edwardt.tril@xxxxxxxxx> wrote in message
news:1152633170.618935.149720@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
To all the experienced design pattern users, I am very new to deisng
pattern and have a great difficulty to decide which pattern to use.
Please help. I will list the points that I have gone through and please
critque.
Problem:
A tool reads an init file to retrieve its initial starting state. The
tool will also have a set of internal initial state which will be used
IF it finds there is no init file to read from. The current requirement
of the init file can be INI file or XML file. There may be future new
init file format.
My old way is to have a method to read and parse the file within a
configurator class, and by parsing I mean read the "section\key\value"
into a dictionary. The tool should always query the dictionary for
values.
But to accomdate these different init file formats I need to change the
config class. I do not believe it is a good isolation case if I need to
do that.

My thinking:
1. ini and XML file has different parser out there and they offer
different interface. For XML I am going to use Expat. for Ini a open
source c++ ini class(CIniParser). the CIniParser has built-in hash
table. Expat does not saves the state because of its stream-oriented
parser. So some how I need to save it? (should I care or )

2. the tool concerns about:
-- tool gives the configurator a file name, you open and parse it.
The tool does not care
-- tool queries the section or element name too see if it exists
before ask for the values
(shoult it even care? )
-- tool queries the values witin the section or element name.. e.g.
for ini:
[section]
value1 =val2 ;comment1

for XML:
<element>
<blar>val1</bar>
</element>
-- confgiruator do all the opening, closing file, parsing ....
3. I though about factory method and abstract factory. but since the
nature of the interface of CINIParser and EXpat is so different.. how
can they be children of a common base class, required by
factory/abstract method? Or should I make a interface and then make
another interface that uses CINI , one uses Expat? then do the abstract
factory thing on those interfaces?

I am very confused. Please help.


.

Relevant Pages

  • Re: Overwhelmed by choices of Design Patterns
    ... pattern and have a great difficulty to decide which pattern to use. ... You mean the "configurator" class returns a dictionnary-like object to ... it should not require interface change AFAICT from your description. ... For XML I am going to use Expat. ...
    (comp.object)
  • Re: What doesnt lend itself to OO?
    ... >>server is a pure data transfer interface. ... essentially exposing the client or service implementation. ... >>paradigms can be abstracted just like any other problem space in an OO ...
    (comp.object)
  • Re: Text terminal rendering design
    ... free to give it any object that satisfies that interface. ... giving it a real facade object if I choose. ... Facade to avoid touching the client. ... completely incompatible with this subsystem interface. ...
    (comp.object)
  • Re: Abstract public member variales?
    ... Entity has no encapsulation and no real methods, but the great thing about it is that its public interface will never have to change during maintenance. ... Assuming there is at most only one Property instance for each property type, then the R1 collection class would own the smarts for finding the right one. ... However, I would point out that the client of the getter is someone who needs to collaborate with a specific Property, not the Entity itself. ... The second line generates a message to the Property for the collaboration. ...
    (comp.object)
  • Re: Text terminal rendering design
    ... Which is exactly what would happen in your case when the interface of the implementation object changes. ... But then you need a new object to own the actual responsibility within the subsystem implementation. ... I can pop in a facade in a completely painless manner without being forced to rename or kludge anything. ... Facade to avoid touching the client. ...
    (comp.object)