SplitTreeFromLeaves is a pattern described in DesignPatternsForDistributedObjects.
This page is presently a discussion page, and will become more formalized over time. 

'''Intent'''

Avoid the cost of updating entire hierarchical data structures by updating the structure separately from the content.

'''Description'''

Consider the case where a BagOfJumpingBeans consists of beans which are
related to each other in some way; in this case in a hierarchy.
For example, the beans may be class definitions, which are related to the definitions of their superclass and others.
It's very common that hierarchical data will be rendered on a client as some sort of tree control, in which the structure of the relationships is rendered, but the details of the leaves are not.
To assist in client-side rendering of the hierarchy, without the overhead of
transmitting serialized representations of the leaves, separate access to the
tree structure of the data from access to the leaves.
The leaves can then be handled as a BagOfJumpingBeans.
----
''...maybe '''SeparateStructureFromContent'''?''

"For example, '''in Java''', make the reference to the leaf ''transient.''"

I think you've hit upon an interesting and fundamental idea here, but I wonder if we're approaching it wrong:
Maybe it's an attribute of individual objects rather than of collections (like the "tree").
The HalfObjectPlusProtocol assumes that the division of responsibilities between systems is fixed, but the "Split Tree From Leaves" pattern approaches "quantum transitions" of object state -- where parts of an object come across when needed, rather than being remote invocations.
-- JeffGrigg
----
I'd like to add two aspects to the discussion (a principle, and a practical):

	1. SplitTreeFromLeaves is a good solution to something I have experienced on a broader scope: That ModelViewController doesn't work in non-trivial cases when done according to the book. Your model might be perfectly ok, with respect to the application logic, your UseCases, Scenarios, etc.. But still, you application suffers. Something which I try to avoid with RecursiveModelViewController.

	1. Most list, tree, and table widgets are simply broken, esp. because they read the whole data before displaying a tree, etc. You are lucky if you have a widget which really browses the model (the data) instead of first reading in everything, then calculating a tree layout, then displaying it. Even if you have such a widget, SplitTreeFromLeaves is a good idea.

-- ThomasWeidenfeller

----

When you separate the leaf data from the hierarchical structure, that makes it easier for one to have *several* hierarchies refer to the same data. For example, one can have a patrilineal hierarchy (based on father), a matrilineal hierarchy (based on mother), a geographic hierarchy (based on continent / nation / region / city / house), and military hierarchy. All of those structures could point into the same set of people.

Separating leaf data from hierarchical structure also makes it easier to try out a non-hierarchical structure -- see LimitsOfHierarchies.