Be wary of constructors invoking virtual methods directly or indirectly!

wonder if a limited static method breaks this problem down better

one that allows post construction tasks that might allow virtual methods...

Object may have separate constraints around how it should be constructed and how it is used.

Usually both these contracts are coded into a single object except where factories are used as a way to separate these.

It is not uncommon when creating graphs of objects that their interrelationship is baked into the object itself.

This will force a number of organizational methods, such as add, remove, child, parent, into an objects contract when perhaps it should be the perview of a single manager or multiple managers with multiple strategies.

The con is there is more hoopla and code to accomodate this. The pro is the object contracts can stay small and more focussed.


Construction Contract
Usage Contract
Organizational Contract

After constructing an object of this type, call this virtual method. This may be a formalization of the general factory pattern with an init() method that can honor virtual calls.