It many different types of applications, you may have a GUI which is responsible for displaying data to the user. Most applications today have this information.
For instance, Facebook takes comments that are probably stored in a database in some data warehouse, somewhere and is responsible for stitching this information to display to the user.
Often, the GUI has the capability to allow the user to change the data. For example, a user may be able to change their home address, thus storing different data.
For sake of this discussion, we will call the underlying data the MODEL and the GUI, the GUI. It may be possible that there are multiple GUIs that can change the MODEL. In addition, maybe certain command line tools have the capability to change the MODEL. You may also have loading data files, open, save, etc.
So, realizing this, lets say, a user interacts with the GUI to make a change. Most developers would make the changes to the MODEL and in addition also make the changes to the GUI. The natural way to update the GUI would then have three different code based to maintain.
1. Update the GUI when the GUI is initialized.
2. Update the GUI when the user makes a change through the GUI.
3. Update the GUI when a user makes a change to the MODEL, through an external source.
The external source as mentioned above may be another GUI, load, command line tool, etc.
Is it wise to maintain three different code bases which all do basically the same thing. The better design choice is to place an emphasis on what the user is trying to do. Make sure the interactions with the GUI focus on changing the MODEL. After all, when your emphasis is here, when bugs occur and they always do, you can just reuse the code base for 1 to refresh the GUI and view the data.
Always focus on changing the MODEL and let the GUI figure out how to update changes to the model. Include enough tracking information so that the GUI may do minimal effort through notification to update itself.
Now, your design should be like this.
1. Initialization code focuses on intializing the GUI with placeholders for data. After initialization, a method focuses on refreshing the data from the MODEL. The GUI may hold some state information, but the ultimate truth of what the data is comes from the MODEL. If the GUI and MODEL both hold the same flag, and they are out of sync, the MODEL is always right.
2. Interactions with the GUI focus on changing the MODEL. After the MODEL is changed internally from the GUI, a method focuses on refreshing the data from the MODEL. Even if the GUI “knows” what the data values are, the GUI pulls the information through the MODEL. For example, a user may click the link “Add Friend”. It is natural to then have the GUI automatically change to “Friend Request Sent”. However, this is a mistake. The internet connection may go down and the change may never be added to the backend database. In this sense, even though the GUI might “know” that a “Friend Request Sent” should be displayed, it may use this as a placeholder, but it should go to the MODEL to check the actual state.
3. Interactions from other tools or GUIs do their own thing. After the MODEL is changed externally, from another GUI, a method focuses on refreshing the data from the MODEL. This may be done via subscription to notifications. The GUI itself may affect the resolution of various notifications that are sent. For instance, a customer can always let the editor of a newsletter what they appreciate or additional news or information they might need. However, it is always up to the editor to determine if the newsletter changes will be welcomed by all customers. A GUI always has the option to pull all data being displayed instead of focusing on changing a small piece. In addition, a GUI always displays a subset of the actual data available. In this sense, the MODEL is the truth. The GUI is just a perspective.
There is always three sides to a story. What he said, what she said and the truth.