Well, the agile, OOP way to do it would be to make each part type it's
own class, and then just have each class implement a "GetDescription "
method. Classes with common features get refactored into having common
parents, and such classes would generally have common descriptions, or
at least similar-enough descriptions that you could factor-out the
commonalities.
But that wouldn't acheive the goals you outlined - config-oriented
instead of recompile-oriented, and no searching for the description
strings if you want to change them all up. So here's my
non-polymorphic, config-oriented approach
So here's how I'd do it:
1) each object exposes a
Dictionary<stri ng, stringGetBusine ssFields()
method, thus implementing the ICanGetBusiness Fields() interface.
2) Then, you have an XML-serializable class called
DescriptionFact ory(), which is just a serliazed wrapper around a
Dictionary-based version of String.Format.. .. something like this (I
got carried away and did most of the implementation) :
interface IDescribable
{
string DescriberName() ;
Dictionary <string, stringGetBusine ssFields();
}
class Describer
{
[XmlAttribute()]
public string Name;
[XmlArrayItem("k ey", typeof(string))]
public string[] Keys;
public string Describe(string formatString, IDescribable obj)
{
Dictionary <string, stringfields =
obj.GetBusiness Fields();
string[] formatValues = new string[fields.Count];
int i=0;
foreach (string key in Keys)
{
formatValues[i] = fields[key];
i++;
}
return string.Format(f ormatString, formatValues);
}
}
class DescriberManage r
{
public Describer[] Describers;
public string FormatString;
private Dictionary<stri ng, Describerdict = null;
//The meat of the function. Call this to get description from
object.
public string GetDescription( IDescribable obj)
{
//lazily construct Description dictionary
if (dict == null)
{
foreach (Describer desc in Describers)
{
dict[desc.Name] = desc;
}
}
return dict[obj.DescriberNa me()].Describe(Forma tString,
obj);
}
}
The descriptionmana ger and it's child descriptions are serialized out
of your configuration system. IDescribable is implemented by your part
type(s). Of course, this is offered with no warranty - I haven't even
included an exception handler (or TryGetValue) for the very real
possibility of a KeyNotFoundExce ption.
Phuff wrote:
Hey all, I need some direction help. I have a switch case statement
that is seemingly my only option right now, but its too large and not
easy to maintain the code. Here goes...
I have part descriptions (ie. 3/8" X ____" NYLON ALL-THREAD RODS...or
____" x ____" X ____" ____ WRAPPED MULLION) that I need to replace the
blank lines on. I do a switch on the part id.
I have 53 in all out of the parts list. What fills the blank is
dependent on information specific to the customized product being
built. Getting the information is not a problem...the problem is that
I cannot do any generalization. Almost every part is different and
what information the blank is based on is different for each part. I
have no generalized function aside from the one that fills the blank.
I just do a switch statement and have specialized business logic code
for each part.
I'm sure you can see the problem...what happens if we change a part
description in the system, or add a new part, or remove one? I have to
change the code. This is not the best practice, but I see no
alternative at the moment. Everything is so freaking customizable
here! Please help, any ideas?
