Using a model to represent the overall state of a view

Is there a standard practise for representing the state of a user interface that is not linked to a single Component?

For example, a Swing interface could have a series of tabs with a constraint that a single tab should only be displayed once per开发者_如何学Python a given entity type (this could be represented as a HashSet). Or a message could give the result of the last operation carried out. Or a JPanel could be linked to a single entity instance for editing purposes.

---

I think what you are describing is the Model-View-ViewModel pattern. This is all the rage in dot-net land. The top google link for mvvm is also an MSDN article giving a fairly decent overview.

---

Yes, it's perfectly acceptable to create a model for the view itself, which is completely separate from the application model. Swing already does this internally, keeping track of how elements are laid out, rows and columns in tables and the cursor position in text fields.

I would recommend keeping your view-model logic as loosely coupled from the actual component code as possible to make it easier to maintain e.g. make a separate class for each responsibility or behaviour that doesn't extend an actual Swing object.

For example, if we wanted to make sure we only ever have one instance of a certain type of JFrame, such as an Options dialog or even the main application window, this could be done with a singleton-style class which holds a reference to the frame and returns it when someone calls your method, creating it if it doesn't exist, and making it visible if it is hidden. This is very common.