Object Configuration Layer

An ObjectConfigurationLayer is a means of declaratively composing multiple objects and linking them together. There are many techniques for this, especially common to GraphicalProgrammingLanguage and DataflowProgramming. The ObjectConfigurationLayer in many popular OO languages is conspicuously absent, often requiring patterns like SetterInjection and complex frameworks for DependencyInjection or MultiCaster to resolve for larger projects. For smaller projects, one procedurally (and painfully) hooks objects together, possibly following a discipline like ObserverPattern.

In the absence of an ObjectConfigurationLayer, OO provides the primitives (objects) but NOT the means of composition. (see PrimitivesAndMeansOfComposition for details).

Development of an ObjectConfigurationLayer is hindered by use of constructors-with-SideEffects (which might try talking to other objects while only half-finished), and hindered by the stack-based messaging semantics (asynchronous messaging is far more amenable to large, possibly cyclic, configurations and ObserverPatterns).

The "data ownership" common to OO designs is problematic, as it forces 'classes' to serve triple-duty as configuration, data-manager, and capability. OO languages are much more flexible when they're free to override any 'slot' - i.e. changing the state slots so the object represents a view of another system - without any changes to the programmer interface to access the object.

AlanKayOnMessaging suggests a focus on the 'ma' or 'interstitial' areas between objects. I imagine the sort of configuration and plumbing necessary to configure objects would qualify.

Also, use of objects for "data management" is a serious CodeSmell. Consider TellDontAsk or LawOfDemeter to be rules advising in essence: if correctness of code depends on the structure of another object, that's a bad thing. Data shouldn't be managed as object structure.

The only good reason to manage data as object-structure is the engineering reason: that it's the least evil thing you can do in the language and still accomplish your goals (i.e. it is often needed to do LockFreeSynchronization). Just because that's a good reason doesn't mean the need to apply that reason is a good thing, though.