Here's an example of the S''''''howTheUserOurPrivateObjectModelAndNothingElseAntiPattern. Suppose our private object
model looks like this:

    [Root Object] 1---->0,1 [Tier Object] 1--->* [Leaf Objects]

The right way might be to present that in a UI is to show the Root,
fields representing the Tier, and a list box with the Leafs. The
last two segments are ghosted if the Tier does not exist.

The [presumptively] wrong way to manipulate this UI is to force the
users to add bogus details to the Tier before they add a Leaf. The
ultimately wrong way is to ghost the Add button on the list box, and
give the users no clue they need to put something in the fields that
we know represent the Tier first before the Leaf system becomes
available.

The Right Way depends entirely on what UseCase or UserStory you need to render. If the story says they must add a Tier before adding a Leaf, so be it. But, following the rule that "The Actors in a Story are _Not_ the Objects in a Program", then the Right Way must be considered in isolation from the object model on the inside. This is exactly where user-involvement in GUI building is so totally important.

We usually get the CDB when we take an entry-level programmer (maybe
one who got the job by demonstrating the ability to run a GUI forms
editor), and tell them to write a UI for this Object Model that
someone else created. Then we tell them they are too junior and
unimportant to be allowed to disturb the August User with their
distastefully neophytic presence.

Junior now goes and, after a few days struggling with SDK example
code that raises a blank frame window with a menu, makes a menu item
raise a dialog that represents the Root. (Keep in mind that the
blank white client area in the middle of this frame window will
probably remain blank forever.)

Then they put a button on this dialog that says Tier, and this
raises a dialog showing the Tier object.

Then (can you guess?) they put a button on that dialog that says
Leaves, and this raises a dialog showing the list of Leaf objects!

Then, in an ultimate fit of championship hacking, Junior puts a
button on THAT dialog that raises a dialog showing a LEAF!!!

(Obviously, along the way, these dialogs interact with global data
structures that non-robustly parallel what's displayed, because in
Junior's GUI classes in college they never told anyone that each
dialog can remember its own private data chunk to support these
kinds of problems. But they did teach global variables.)

Of course you can get the CDBAP in many other ways, but you can
always bet on the combination of no UI design, a junior GUI programmer
at the helm, and no OnsiteCustomer involvement.

--PhlIp

''Not entirely an AntiPattern if the cardinality on the first relationship is not 1->0/1 but 1->*, as there are few ways to achieve all of this in ''one'' screen which are both usable and not unnecessarily complicated.  You also end up violating OnceAndOnlyOnce and the LawOfDemeter if you try and map two one-to-many relationships with lots of associated data onto one screen.  Not to mention confusing the user when you suddenly take everything away from them for seemingly no apparent reason.''
-----
See also: GooglifyDeepMenus