Design patterns for creating objects that have a list of objects that also have a list of objects

Question

In terms of good OOP design, what is the best way to structure code that is just containers of list of objects that contains other lists of objects that also are just other containers?

Example: A Cookbook owns a list of Chapters that owns a list of Recipes that owns a list of Directions. Each object is a different layer within a whole. For clarity, I use the word "list" to refer to any data structure used to store multiple objects.

I've come across this Russian doll problem of nested objects inside of nested objects many times. I've tried passing the bottom level objects through the nest hierarchy and also tried writing methods that pass information down to the bottom nested object. My structure always feels messy because the intermediate classes are filled with methods that do nothing more than passing either objects or information.

An addition due to confusion expressed in the comments: I'm looking for direction in things to study for handling a general type of problem. I'm not asking for a solution to a specific coding problem that I have in front of me. I wasn't expecting a "one answer to rule them all", but more of "use A design pattern for X situations but use B design pattern for Y situations and beware of Z." The example is for providing a general context, not a specific one.

Answer 1

One way to make it easier is that all classes implement the same interface so you can treat them indistinctly. Theres a known pattern for this:

The good news is that as this creates a tree. You can then write, in an external managing class, recursive methods to look up items.

For example you could write a method findAndAdd(String tagToFind, Component componentToAdd);

To the base interfaces documented in the pattern you should add a tagMatches(String tag) as well as all common getters and setters so you can, again, treat items indistincltly of their class.

I would add hasChild() and nextChild() methods to implement iterations.

Answer 2

Do yourself a favor, and keep it simple and stupid!

In your example, you wanted to model Cookbooks, having Chapters, containing Recipes, owning Directions". In terms of good OO design, you model exactly this: a class Cookbook with an aggregate list of Chapters, having an aggregate list of Recipes, each one with a list of Directions. This is a straightforward mapping from "real world objects" to "OOP objects", which is one of the core ideas of object oriented modeling. It is easy to understand and maintain for you and anyone else who has to deal with this data.

At this point, your code is not yet messy. It might become messy if you often have to write methods like

 // inside a Cookbook method:
 foreach chapter in listChapters
     foreach recipe in  chapter.listRecipes
          foreach  direction in  recipe.listDirection
              // do something with direction                

You can avoid writing such code more than once if your programming language has good support for creating your own iterator function (like C# or Python). Then you can easily provide resuable helper functions once for getting, for example, all directions in a cookbook. Another approach it to utilize the visitor pattern, it will allow you to provide different operations "visiting" all objects in that hierarchy and do "something" during the visit.

Of course, when you have uniform containers, where on each level of the hierarchy a container can hold a list of containers of the same type, then the composite pattern suggested in @TulainsCórdova answer makes sense. Examples for this are a file/folder hierarchy, or a tree structure for abstract syntax trees, where expressions contain subexpressions which contain subexpressions, and so on. But in your example, each of the container object you described on each level is different from each object on another level, it has a different name, probably a different behaviour, and contains only sub containers of one specific type. So trying to shoehorn the described case into the composite pattern will probably make your code really messy.