1

I'm currently working through some old code and I started to wonder, is there actually any difference between:

public class XmlExport : IXmlExport
{
    private readonly IJobRepository jobRepository = new JobRepository();
}

and

public class XmlExport : IXmlExport
{
    private readonly IJobRepository jobRepository;

    public XmlExport()
    {
        jobRepository = new JobRepository();
    }
}

Are there any advantages to initializing inside the constructor? or is it just the same code?

Lobsterpants
  • 1,188
  • 2
  • 13
  • 33
  • 1
    The first option might be a better choice in case you have several independent constructors and you want to factorize the repo creation – vc 74 Mar 22 '18 at 09:18
  • 1
    There are differences: 1. When you initialize using the constructor, you can pass parameters to the `JobRepository` that are unknown at compile time. 2. When you have multiple constructors, inline initialization might be a better choice, because you don't need to chain the constructors or initialize in each one... – Zohar Peled Mar 22 '18 at 09:18

2 Answers2

2

one advantage of using at constructor level , is you can pass dependency from outside and change your code easily.

you can do this

public class XmlExport : IXmlExport
{
    private readonly IJobRepository _jobRepository;

    public XmlExport(IJobRepository jobRepository)
    {
        _jobRepository = jobRepository;
    }
}

this is called as Dependency injection termed as Constructor Level Dependancy Injection.

I don't like declare and initialize field at class level it , and i don't see advantage of doing it. If you want to do initialization than Constructor is in class it for that purpose only , this is as per my reading of C++ book.

Pranay Rana
  • 175,020
  • 35
  • 237
  • 263
  • Yeah, I'm actually preparing the code for dependency injection and the code will eventually look like that. My first pass is to get everything initialized at the top of the module. – Lobsterpants Mar 22 '18 at 09:23
  • 1
    While I agree that DI is a good idea, this does not really answer the question. – Paul Kertscher Mar 22 '18 at 09:24
2

The question already has answers here, I just wanted to add my 2p.


If in your example

public class XmlExport : IXmlExport
{
    private readonly IJobRepository jobRepository = new JobRepository();
}

the JobRepository constructor throws an exception, you will get

the application is in break mode.


However, if the jobRepository is initialized in the constructor like this

public class XmlExport : IXmlExport
{
    private readonly IJobRepository jobRepository;

    public XmlExport()
    {
        jobRepository = new JobRepository();
    }
}

you will get the exact exception, stack trace, etc. This is also the only location where you can actually catch the exception.


Therefore, in my opinion it is better to initialize

  • simple objects (int, bool, types you know won't throw) on declaration
  • objects that might throw in the constructor.
Thomas Flinkow
  • 4,845
  • 5
  • 29
  • 65
  • 1
    Exception handling is a really good point - thanks. – Lobsterpants Mar 22 '18 at 09:33
  • @Lobsterpants thank you for your feedback & the accepted answer. I just recently came across this issue when I initialized WPF `Image`s at declaration instead of in the constructor. Generally, constructors shouldn't throw, but it's better to be safe than sorry. – Thomas Flinkow Mar 22 '18 at 09:34