I have 3 classes: a JButton extension, FButton; a JTextField; and a JPanel extension, FPanel, that would contain one instance of both.

The FButton is supposed to open a file, and make the file name and directory for the file available.

The JTextField is meant to display the file name and directory provided by FButton.

I figured FPanel should be the one containing the file name and directory. If I make FButton and JTextField private classes of FPanel, problem solved with public variables. How about if I want to separate them into a public FPanel class, a package visible FButton class, and a package visible JTextField class, within the same package? How can I make the file variables available to all classes in the package?

Should I be doing it that way?


I think the difficulty arises because you have view (Swing) objects storing application state. In a desktop application I know the controller and view sometimes are merged partially or entirely, but the model should still be separate.

When developing such applications, I like to use the following approach:

  1. Some code (could be main, an event listener, whatever) triggers a new view into existence.
  2. A factory of some sort constructs the MVC elements:
    1. View: prefer to use standard Swing classes and assemble them together.
    2. Model: create an object to handle one of two types of data. One, persistent state which was likely passed on from the enclosing controller. Two, state which is used by this new view (temporary objects that may be shared).
    3. Controller: construct more listeners and attach them to the view objects. They will also typically have references to the model objects so they can act on them.
  3. Next, wire everything up. Add listeners to the view. Use common objects between them when appropriate so they can see the same data and all update the view as necessary.

I believe you are asking the wrong question: using the above approach may be able to solve your dilemma (I cannot say for sure, I do not see your code).

I also highly recommend avoiding global variables, static state, etc. I like to create Context objects which contain state applicable to the entire application or portion thereof which would normally be a "global variable" to a less experienced developer. This context contains only those variables which are truly needed to be shared across objects, such as the current file (or file abstraction), logged in user, or other state that can legitimately affect all objects in an application or module.

Reducing coupling like that makes individual elements more reusable. While the code may be more verbose and (at first) difficult to follow, it really does streamline it and make it easier in the end. Remember your SOLID principles.

| improve this answer | |
  • So I should add a mediator class to handle data transfer between the view objects? – user2738698 Mar 28 '14 at 17:49
  • I would try to decouple the view objects. They should be dumb, just sitting there and showing data. They should not have knowledge of each other. Yes, some sort of mediator would be appropriate if e.g. changing the value in one text box needs to make a change to a different one. – user22815 Mar 28 '14 at 18:03
  • If they're dumb and just showing their data, I should at least restrict who sees such data right? – user2738698 Mar 28 '14 at 18:57
  • +1 for context objects. I tend to preach this myself; in an OOP world, a somewhat mutable stash of context-specific variables is ideal for maintaining loose coupling. Everyone's (in the enterprise space anyway) is doing it – kolossus Mar 30 '14 at 4:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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