Ist es eine schlechte Praxis, eine Menge Code in den Konstruktor zu packen?
Ja.
Der Grund ist einfach: Ein Konstruktor hat nur einen Zweck: Er soll ein neu erzeugtes Objekt initialisieren, nicht mehr und nicht weniger.
Es ist natürlich Ansichtssache, was zu dieser Initialisierung alles dazugehört, aber ein paar Sachen sollte man beachten:
Wenn ein Konstruktor Fehlerzustände erzeugt, muss dafür eine Exception geworfen werden, damit die Instanziierung des neuen Objekts komplett abgebrochen wird. Ganz schlecht wäre es, die Fehler irgendwo im Konstruktor abzufangen, sich dann irgendwie durchzuwurschteln und dann ein nicht korrekt initialisiertes Objekt existieren zu lassen. Ein Konstruktor MUSS immer ein korrekt initialisiertes Objekt hinterlassen. Das schränkt die Art von Code, die darin steht, deutlich ein.
Konstruktoren sind einer der wenigen Fälle, in denen, wenn man nach funktionalen Prinzipien programmiert, schreibend auf Member zugegriffen werden kann, und das sollte auch so sein. Im Java-Bereich ist heutzutage jede Klasse, die außer "getter"-Methoden für die Properties auch noch "setter" hat, strengstens zu hinterfragen. Ein Stück Code, das "setter" hat, gehört in den meisten Fällen auf den Müll. Somit ist der Konstruktor die einzige Routine, die schreibend auf Member zugreift, und viel mehr sollte er auch nicht tun, denn das ist schon schlimm genug.
Viel Code in den Konstruktor zu packen, ist vor allem auch deshalb schlecht, weil es immer schlecht ist, viel Code in eine einzige Routine zu packen.