I faced the following problems when I put too much code into the constructor:
- It was hard to write unit tests for other methods of that class,
because it wanted to do a lots of things in the constructor, thus, I
had to set up a lots of valid things or at least mocks (DB, file,
whatever) for the simplest unit tests.
- It was hard to write unit tests for the constructor itself. Anyway,
putting a lots of code with diversified responsibilites into one
block is even a bad idea. (Single Responsibility Principle.)
- For the former reasons, it was hard to use that class. For example,
it completely prevented me to implement some deferred init methods,
because it needed everything in the moment of invoking the
constructor. Ok, I could write the lazy init method into the
constructor, nice.
- Sooner or later I realized that it had sense to reuse some code parts
which are placed in the constructor. Well, when I first wrote the
constructor I also thought that those code parts will be used just
there, forever.
- When I wanted to extend that class and insert some logic before or
into the super constructor's logic, it simply didn't work because the
first thing to do in the extended class' constructor is to invoke the
super's one.
So yes, doing a lot in constructor is a bad idea in my opinion.
Generally I just put some field initializations into the constructor and make an init method to invoke when everybody is on board.
