public class Connection : IConnection { public Connection(Uri baseAddress, ISerializer serializer) { BaseAddress = baseAddress; Serializer = serializer; ResponseFactory = new ResponseFactory(serializer); } private Uri BaseAddress { get; set; } public IResponseFactory ResponseFactory { get; set; } private ISerializer Serializer { get; } } In this code (redacted for brevity), the Connection class has two dependencies that it gets via constructor injection.
It has a third dependency, on IResponseFactory, where property injection is available but a default is created via the line ResponseFactory = new ResponseFactory(serializer) in the constructor. I suppose the view was that ResponseFactory is a suitable 'local default', to use Mark Seemann's terminology, but a user of the Connection class is free to provide an alternative IResponseFactory should they wish.
On revisiting this code after some time, I'm ambivalent about the the creation of the local default in the constructor and its dependency on ISerializer. While ISerializer is required in its on right by the Connection class, 'chaining' it together with ResponseFactory seems wrong. It feels like the Connection class should require an IResponseFactory via the constructor and forego the convenience of the local default and its dependency on ISerializer, that just happens to also be injected into this class.
What do you think? Is this a defined 'smell'?
{ get; private set; }set only in a constructor, unless we really know that we want this aspect of the object to be (dynamically) mutable.