0

For context, I'm building a GTK+ application in C where a subclass of GtkApplicationWindow creates and displays a subclass of GtkToolbar and a GtkNotebook (a widget with multiple pages that can be displayed alternately by a member function). There are radio buttons on the toolbar to switch among the pages.

Should the toolbar hold a (duplicate) reference to the notebook (provided by the window during construction), or should it only hold a reference to its owner (the window) and call a function of its owner which in turn calls the notebook's function to switch pages? Another alternative, the toolbar might only keep a reference to window, and access the window's reference of the notebook each time it wishes to toggle pages? I have a feeling this is a case addressed by the Law of Demeter, but I'm not sure what it dictates.

2 Answers 2

2

It should only hold a reference to its owner (the window) and call a function of its owner which in turn calls the notebook's function to switch pages. The owner owns the reference to the notebook and can validate whether the pointer is still good vs. has been released.

0

Have you considered basing this on events? This would allow you to structure the publish/subscribe relationships separately from the object relationships.

1
  • 1
    Yes, that would probably be a much better option. This was some years ago, and I've done an awful lot of OOP and GUI dev since then--I definitely wouldn't keep a parent or sibling reference to do this: the toolbar really shouldn't know either of those interfaces. Passing in callback functions in the toolbar constructor (or via "event subscribe" methods or gtk's "register callback" signal mechanism) or making the parent its delegate are two other common patterns that come to mind. Sep 28, 2019 at 17:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.