0

Suppose I've two settings (for sake of simplicity) that alters behaviour of my types in a reusable library.

I can define a configuration class:

class Config {
  public bool Behaviour1 { get; set; }
  public bool Behaviour2 { get; set; }
}

Than if I do such thing I must propagate the instance from the composition root (no matter if handled with IoC) to the whole hierarchy.

The code will be invaded by an horde of conditional statements, reducing readability, maintainability and extensibility.

Would not be better to define two behavioural types?

public class Behaviour1 : IBehaviour1 {}

public class Behaviour2 : IBehaviour2 {}

Remove global dependency the other types have from Config. Than each class that need a behaviour will depends on IBehaviourX and its factory will inject a proper concrete on the basis of Config type.

In this way only few top level types will depends on Config and behaviour of assigning behaviour (pardon the pun) will not propagate to the whole hierarchy.

I'm interested on your solutions in such case.

jay
  • 1,510
  • 2
  • 11
  • 19

2 Answers2

1

you may think about the Creation Method design pattern .

Having to change the behavior of the class based upon the configuration parameters will present the problem because then your class will violate SRP rule clearly , create sub classes and use virtual /override methods to get desired behavior related to the configuration the and use Creation Method patten to get the correct object

TalentTuner
  • 17,262
  • 5
  • 38
  • 63
  • What do you mean? Singleton or Factory or Abstract Method Factory or Builder or Prototype !? Please correct your answer. – hackp0int Mar 08 '13 at 07:16
  • +1 for link with sample, @Saurabh. Don't sure this pattern fits my solution. Can you suggest a pattern that favor _composition over inheritance_? – jay Mar 08 '13 at 07:20
  • 1
    What i understood is the fact that you are using the configuration properties to define / alter behavior of a class which leads to the violation of SRP someway down the road for sure, what i am suggesting is to move the code which changes based on the configuration properties into specific classes and then again refactor to move common code into base classes. Certainly after some point of time you need to get the proper object based upon the configuration then Creation Method will be helpful. This is what i understood from the question. – TalentTuner Mar 08 '13 at 07:31
  • +1 @Saurabh, clarification helps and it's appreciated; anyway I'm curious to see alternate ways (if do exists, without violating SOLID). – jay Mar 08 '13 at 07:40
1

I would say that you're on the right track with implementing your behaviors as classes/interfaces rather than handling differences with conditionals and the like.

You might want to have a look at the Strategy Pattern as your current idea seems to be heading in that direction. And using IoC your idea should work just fine as is and it's probably what I would settle for.

Peter Karlsson
  • 1,170
  • 7
  • 15
  • +1 @pmacnaughton and this replies because this is the closest pattern that fits my question. About IoC in that case I'll do it without a framework. As explained [here](http://stackoverflow.com/questions/14681779/locate-the-correct-composition-root-for-a-net-library) _poor-man-injection_ could be good for reusable libraries. – jay Mar 09 '13 at 07:43