Hiding dialogs behind an abstraction. Does this pattern have a name?

Question

Here's the deal. I've got user input coming from a bunch of different sources, a dozen dialogs, console etc. The standard way to get something from a dialog is buy reading it's attribute after it's closed.
e.g.
dialogInstance.setModal(true);
dialogInstance.setVisible(true);
String s = dialogInstance.getUserInput();Now, I find this very ugly as it ties you tightly to the implementation of the class that accepts the input (a dialog in this case). In order to loosen the coupling, I came up with the following pattern. Components that are used to accept input (dialogs) are required to bind that input to a previously specified variable in the "global context" that is also available to the main program (that instantiated the dialog in the first place). So, it looks like this:
initInputGatheringComponent(); //this is also abstracted but details are not relevant at the moment, see below if you care for more info
UserInput input = Context.get("variableName")
...And the dialog does this:
//OK button is pressed
Context.set("variableName", UserInput) //UserInput comes from reading a text field value or something like that. This way, the main program has no idea how the variable got it's value, be it from a dialog, console or whatever. And if I change the way I get data, I don't have to change the main program, as long as the same variable is populated.
Now, what I want to know is if this pattern has a name and what it might be? I'm sure I haven't invented anything new, but I want to know what have I reinvented...
Also, I'm interested in the opinions on my approach... Hopefully, the topic is at least a bit interesting to discuss.

Answer 1

Implementation details, for those who care
Every class that is used for accepting input is associated with a name (through an XML config file, I'll see if I know how to change this to annotations), and the method that starts it is annotated with @Run. When requested by the main program, using the name of the component, like this:
Context.start("componentName")the class associated with this name is instantiated by reflection, and it's @Run method is executed. So, for the dialog example, it looks like this:
XML:
<component name="loginDialog" class="javax.swing.JDialog">Code:
@Run
public void display() {
    init();
    setModal(true);
    setVisible(true);
public void btnOKMouseClick(...) {
    Context.set("userName", txtUserName.getText()); //reads the value of the text field and binds it to a context variable named "userName"
    Context.set("password", txtPassword.getPassword()); //same with password field
}and the main program would look something like this:
//the user needs to login
Context.start("loginDialog"); //finds out the class of the component named "loginDialog" (JDialog in this case) from the XML config, instantiates it through reflection,
//and runs it's annotated method (display() in this case)
String userName = Context.get("userName"); //gets the value of "userName" from the context, without being aware how it got there
String pass = Context.get("password"); //same here with "password"