Commonly used object with configuration dependency

We have a quite common object in our application. In this case, we'll call it a Ball. Balls work fine, but in some configurations they act differently. It is currently set up like this:

class Ball
{
    private static开发者_运维问答 readonly bool BallsCanExplode;
    static Ball()
    {
        bool.TryParse(ConfigurationManager.AppSettings["ballsCanExplode"], 
            out BallsCanExplode);
    }
    public Ball(){}
}

This works completely fine in practice. If the configuration is that balls can explode, they explode, and if not, not. The problem is that it is completely non-testable. I haven't been able to figure out a good way to keep it testable, and still easy to instantiate.

The simplest solution is to just decouple the ball and the configuration:

class Ball
{
    private readonly bool CanExplode;
    public Ball(bool canExplode);
}

The problem with this is that what was once an isolated dependency in the Ball class has now spread to every single class that makes a Ball. If this gets dependency injected in, then the knowledge of exploding balls has to get injected everywhere.

The same problem exists with a BallFactory. While every class could just go new Ball(), it now has to know about a BallFactory that has to be injected everywhere. The other option is to use the Service Locator which is already baked in to the application:

class Ball
{
    private readonly bool CanExplode;
    public Ball()
    {
        CanExplode = ServiceLocator.Get<IConfiguration>().Get("ballsCanExplode");
    }
}

This still keeps the configuration dependency in the ball, but allows a test configuration to be injected in. Balls are used so much though, that it seems like overkill to locate the service on every new Ball() call.

What would be the best way to keep this testable, as well as easy to instantiate?

Note: There is both a dependency injection framework and service locator in the application, which are both used frequently.

Classes that instantiate balls should receive a BallFactory as a dependency. The BallFactory can be configured accordingly as application startup whether or not to produce exploding balls or non-exploding balls.

Don't have the BallFactory read the application configuration file to determine which types of balls to produce. That should be injected into the BallFactory.

Service locators are an anti-pattern. Don't use them.

I would use something like your ServiceLocator to set a static DefaultBallsCanExplode, then perhaps have an overloaded constructor that can take a ballsCanExplode bool as an option.

Keep it simple!

As I understand correctly, all balls in your application always act the same. Either they explode or they don't, determined by a configuration switch. What you can do is configure this in your DI framework. Depending on the framework the wiring in the application root could look like this::

bool ballsCanExplode =
    bool.Parse(ConfigurationManager.AppSettings["ballsCanExplode"]);

container.Register<Ball>(() => new Ball(ballsCanExplode)); 

When you do this you can use the Service Locator pattern to fetch a new instance of a ball as you are already used to do:

ServiceLocator.Get<Ball>();

But better would be to let the DI framework inject Ball dependencies in the constructor of some other type (much easier for testing).

I vote for the configuration service path. The overhead should not be very high for a typical service locator implementation and you can cache the configuration service if you need it later. Better yet, use a dependency-injection framework and you won't need to explicitly locate the service.

How about something like this:

internal interface IBallConfigurer
{
    bool CanExplode { get; }
}

internal class BallConfigurer : IBallConfigurer
{
    public bool CanExplode
    {
        get
        {
            bool BallsCanExplode;
            bool.TryParse(ConfigurationManager.AppSettings["ballsCanExplode"],
        out BallsCanExplode);
            return BallsCanExplode;

        }
    }
}

public class Ball
{
    private bool canExplode;

    public Ball()
        :this(new BallConfigurer())
    {

    }

    internal Ball(IBallConfigurer ballConfigurer)
    {
        this.canExplode = ballConfigurer.CanExplode;
    }
}

This way, you can make the ball class internals visible to your unit test assembly, and inject a custom ballconfigurer.