satya - 10/28/2013 12:04:19 PM

wonder if a limited static method breaks this problem down better

wonder if a limited static method breaks this problem down better

satya - 10/28/2013 12:06:56 PM

wonder then, if there is such a thing as a static constructor pattern

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

satya - 10/31/2013 10:45:33 AM

For an object construction contract and usage contract may be two different things

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.

satya - 10/31/2013 10:47:57 AM

Object hieararchies and objects them selves may be different

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.

satya - 10/31/2013 10:48:25 AM

So that leaves me three separate contracts for an object

Construction Contract
Usage Contract
Organizational Contract

satya - 11/3/2013 7:14:37 AM

It may be worth pursuing the post construction pattern, some qualities may be

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.