You can use policies to affect how the strategies performs their tasks in ObjectBuilder. For example, for the SingletonStrategy to consider any object to be a singleton you need to use the SingletonPolicy. Since policies affect how strategies do their work, it's easier to create more general purpose strategies, that are then informed of the details through policies.

There are two ways to set policies. One is through the Policies property of the Builder object and the other is by using the transientPolicies parameter of the BuildUp method. The policies applied through the transientPolicies argument will always take presence over the policies set on the Policies collection property. Internally the object builder (aka the classes derived from ReflectionStrategy) detects attributes like CreateNew and Dependency and creates policies (for example PropertySetterPolicy) of them.

Now, lets look at an example. The class below has two construtors, one that is used normally, but sometimes another View opens the CustomerView and then wants to directly open a specific customer and for that case we have a second constructor, which take the customerId as parameter.

 

public partial class CustomerView : Form, ICustomerView
{
    [InjectionConstructor()]
    public CustomerView()
    {
        InitializeComponent();
    }

    public CustomerView(int customerId)
        : this()
    {
    }
}

 

When this class is instantiated through the default setup of the Builder object, the constructor marked with the InjectionConstructor attribute will be used (as I blogged about here). With a little help of policies this can be changed though, so that the constructor that takes the customerId as a parameter will be called instead.

 

 

Here a ConstrutorPolicy is set up and added to a PolicyList. By passing this to the transientPolicies argument of the Buildup method this will be used instead of the default creation policy.