What design should I use so a class can query one of it's ancestors?

Question

I'm creating an object hierarchy that is representing a table that is draw on a control. My hierarchy looks like this :

Table has multiple pages
Page has multiple lines
Line has multiple cells
Cell has multiple glyph

I want to have an option (a parameter) on the table to filter the column (cells) displayed. The client code can do something like this:

myTable.ShowColumns(8,12) // Will display columns 8 to 12

Displaying and placing cells on the control is the responsibility of the Lines objects.How can I pass the informations of which cells are to be displayed from the Table object to the Line object?

Should I give each line a reference to the table object? Should I try to pass the informations to each lines through the hierarchy each time Table.ShowColumns() is called?

There must be an elegant way?

Answer 1

I don't think that there is need for a design pattern. (Or I wouldn't call it that way) Why don't you just use double linking where childs link to the parent and vice versa?

Answer 2

If I understand correctly, what you refer to as ancestors are actually parents in your hierarchy - which in effect if nothing more than a tree. And with trees it is common practice to have child nodes reference their respective parents.

As to the design of the ShowColumns function, I think it should modify an internal state variable of the Lines class (which holds the cells) by virtue of a similar internal function call on the Lines class.

// something like this..
Table.ShowCollumns -> Table.m_lines.SetVisibleColumns -> (modify visible columns)

Obviously, depending on the logical mapping of columns to pages, and pages to tables, you may have to interject yet another call before calling SetVisibleColumns on the Lines class, in order to find the correct page object: Table.FindPageWithColumns(...) and then operate on that one.