is a means of declaratively composing multiple objects and linking them together. There are many techniques for this, especially common to GraphicalProgrammingLanguage
. The ObjectConfigurationLayer
in many popular OO languages is conspicuously absent, often requiring patterns like SetterInjection
and complex frameworks for DependencyInjection
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
Development of an ObjectConfigurationLayer
is hindered by use of constructors-with-SideEffect
s (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 ObserverPattern
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.
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
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.