Originally posted by Pho Tek:
I wonder if my aforementioned design fall into this category of constructors with "complex assemblies".
Domain-Driven Design is a very good book, and I agree with the general advice here.
The key to that quote is "constructors of other classes." As I said, you cannot avoid calling the superclass's constructor from the subclass's constructor. Well, you can actually, by calling a different constructor of the subclass which will then call a superclass constructor.
One goal of the Factory
pattern is to have the Factory create classes and wire them together. This is unrelated to the discussion regarding abstract classes, though it is a worthy discussion.
An example would be a business object that requires two DAOs to do its work. The business object should not instantiate the two DAOs. Rather a BO Factory (or a framework like Spring) should instantiate the objects individually and set references between them appropriately. The following code is extremely trivial just to show how this applies.
Of course, as with any design pattern you want to make sure you don't go off the deep end. If you have a class that uses an internal HashMap to fulfill its contract, you don't need a separate Factory to build that class and hand it a HashMap; that's going too far.