Your conditions are not hugely well defined, but it sounds like a map of states to actions, where a state is defined by a number of simple conditions, and each state only has one action. So why not actually represent it like that?
Here's a simple LinqPad example:
void Main()
{
Dictionary<Cond, Action> d = new Dictionary<Cond, Action>()
{
{ new Cond(waterproof:true, shockproof:true, freezeproof:false), delegate() { "Action1".Dump(); } },
{ new Cond(waterproof:false, shockproof:true, freezeproof:true), delegate() { "Action2".Dump(); } },
{ new Cond(waterproof:true, shockproof:true, freezeproof:true), delegate() { "Action3".Dump(); } }
};
d[new Cond(true, true, false)]();
d[new Cond(false, true, true)]();
d[new Cond(true, true, true)]();
}
public class Cond : Tuple<bool, bool, bool>
{
public Cond(bool waterproof, bool shockproof, bool freezeproof) : base(waterproof, shockproof, freezeproof)
{
}
}
Output:
Action1
Action2
Action3
The subclass of Tuple<>
is because:
It makes everything much more readable rather than having the generic arguments everywhere.
You can use named parameters as I have done to make the map logic very clear.
You can swap it out with a custom class if you need more complex logic, like varying numbers of conditions in each state.
You will probably need to override Equals
and GetHashCode
in that case.
(You obviously don't need to use the anonymous delegates; you can just pass a direct reference to the method you want to use)