Return to Answer

Identity the hidden business concept

class ProductFactory { private static readonly Dictionary<bool, Dictionary<bool, Func<IProduct>>> _products = new Dictionary<bool, Dictionary<bool, Func<IProduct>>>(); static ProductFactory() { _products.Add(false, new Dictionary<bool, Func<IProduct>> { { true, () => new ProductSingleWithChildren() }, { false, () => new ProductSingle() } }); _products.Add(true, new Dictionary<bool, Func<IProduct>> { { true, () => new ProductMarriedWithChildren() }, { false, () => new ProductMarried() } }); } public IProduct GetProduct(bool isMarried, bool hasChildren) { return _products[isMarried][hasChildren](); } } 

You'll notice in the end we not only got rid of the duplicate if condition, there are in fact ZERO if statements in the whole solution!!! :) Pretty neat, and will get you a low cyclomatic complexity score and a nice clean CPU pipeline. Plus much more readable code.

Identify the hidden business concept

class ProductFactory { private static readonly Dictionary<bool, Dictionary<bool, Func<IProduct>>> _products  = new Dictionary<bool, Dictionary<bool, Func<IProduct>>>(); static ProductFactory() { _products.Add(false, new Dictionary<bool, Func<IProduct>> { { true, () => new ProductSingleWithChildren() }, { false, () => new ProductSingle() } }); _products.Add(true, new Dictionary<bool, Func<IProduct>> { { true, () => new ProductMarriedWithChildren() }, { false, () => new ProductMarried() } }); } public IProduct GetProduct(bool isMarried, bool hasChildren) { return _products[isMarried][hasChildren](); } } 

You'll notice in the end we not only got rid of the duplicate if condition, there are in fact ZERO if statements in the whole solution!!! :) Pretty neat, and will get you a low cyclomatic complexity score and a nice clean CPU pipeline. Plus much more readable code.

Then again, we just wrote a LOT more lines of code than the original example. So, depending on context, maybe the nested if statements would be better, in certain cases, e.g. the combination of the flags is arbitrary or doesn't map to a logical concept within the business problem, or the extra readability isn't necessary for a certain small problem. It's up to you, of course.

Dictionaries with a key of bool seem a little weird, so in an actual piece of code you might lean toward using an enum instead, or possible a string containing a code. I would suggest using an identifier that is aligned with the business/domain.

Dictionaries with a key of bool seem a little weird, so in an actual piece of code you might lean toward using an enum instead, or possible a string containing a code. I would suggest using an identifier that is aligned with the business/domain; make it easy for other developers to understand what is going on.

For completeness, here is an idea what the classes would look like:

interface IProduct { void Execute(); } class ProductSingle : IProduct { public void Execute() { a(); } } class ProductSingleWithChildren : IProduct { public void Execute() { a(); b(); } } class ProductMarried: IProduct { public void Execute() { c(); } } class ProductMarriedWithChildren : IProduct { public void Execute() { //No operation } } 

You'll notice in the end we not only got rid of the duplicate if condition, there are in fact ZERO if statements in the whole solution!!! :) Pretty neat, and will get you a low cyclomatic complexity score and a nice clean CPU pipeline. Plus much more readable code.

public IProduct GetProduct(q, p) { return _products[q][p](); } 

...where _products is a list of lists, each item containing a Func<IProduct> that will instantiate the appropriate type.

class ProductFactory { private static readonly Dictionary<bool, Dictionary<bool, Func<IProduct>>> _products = new Dictionary<bool, Dictionary<bool, Func<IProduct>>>(); static ProductFactory() { _products.Add(false, new Dictionary<bool, Func<IProduct>> { { true, () => new ProductSingleWithChildren() }, { false, () => new ProductSingle() } }); _products.Add(true, new Dictionary<bool, Func<IProduct>> { { true, () => new ProductMarriedWithChildren() }, { false, () => new ProductMarried() } }); } public IProduct GetProduct(bool isMarried, bool hasChildren)  {   return _products[isMarried][hasChildren](); } } 

...where _products is a list of lists, each item containing a Func<IProduct> that will instantiate the appropriate type.

Dictionaries with a key of bool seem a little weird, so in an actual piece of code you might lean toward using an enum instead, or possible a string containing a code. I would suggest using an identifier that is aligned with the business/domain.