push vs pull : Java Glossary

Inside Java, you run into the push-pull quandary all the time. All your classes are bristling with get/set methods, but whose job it is to call the get method of class A and relay the information to the corresponding set method of class B? E.g. where A is a data object and B is the corresponding GUI (Graphic User Interface) object. If A does it, you are pushing. If B does it you are pulling. If class C does it you are controlling.

GUI objects are usually tree structured, Panels within Frames. Frequently, data passed to a Frame gets then passed to a Panel and finally to some Component, with often many more layers than that. Should data be relayed down the hierarchy or passed directly?

You can see there many possible combinations of push/pull and indirect/direct, all of which would technically work. However, if you are not careful, you will create a rat’s nest and you will have no idea how to find the code you are looking for.

Here are some rules of thumb to help create order:

• Stick with the MVC (Model-View-Controller) paradigm, e.g. JTree, JTable. The Controller pushes data into the Model and the Model in turn notifies View of changes via events and the View pulls data from the model as needed to update the display.
• Use Listener interfaces to push data back from the GUI to the data objects. Don’t push some data and pull other.
• Avoid duplicating data in RAM (Random Access Memory). It will only get out of sync. Instead, have consumers get it each time from the master copy, however, indirectly. In some multithreading applications performance may force you to cache multiple copies, but don’t do that routinely.
• Decide on a convention. Who sets the Frame setSize, setLocation, setTitle? Who does the validate and setVisible( true )? the caller or the Frame. Then stick to it. The usual convention is to have the caller do the validate and setVisible.