Q:

First timer Swing application, need help implementing the application logic

I've made the Swing 'face' for a program that does electrical calculations. It's looking great, but I now seem faced with a bewildering set of options as to how to implement the underlying calculation. The code is getting alittle long, so I will try to describe in general terms. 
The panel I'm working on calculates voltage drop: 

The user can select from a group of two radio buttons which chooses the type of formula for the calculation. 
The user chooses values for (7) different variables, (3) of which are only present in one of the types of the formula. User chooses with editable and non-editable combo boxes. 
There are an additional (4) variables, and the user chooses which one these will be solved for with more radio buttons. There are also some additional radio buttons next to these which change the format (ie feet, meters) of the variables. 
The result is displayed in a text field, and updated whenever the user changes a value. 

I don't think this requires much processing power so this is all being done in the event dispatch thread - good because I don't know much about threads yet. 
There are a few different ways with my limited knowledge of Java and programming that I can think of the implement this, and probably a few I don't know about yet. Even the ones I know about still seem a little 'hazy' to me. 
A. Use event listeners that fire when basically any legal change is made to the panel, and pass all of the variables as pretty much string literals to a monolithic logic class constructor that parses everything and figures out the result and has a method to return the result. I guess it could have different constructor signatures that could help in figuring out what to do. Every time the user changes the panel a new object is created that figures out the result. This seems like it might be ugly and hard to work with. 
B. "Parent Factory" - Do pretty much the same as (A.) except pass the variables as arguments to a method in an abstract class that figures out what to do and creates an instance of one of its subclasses. This will at least make working on the application logic a little easier, I think. 
C. Observer and Observable? I don't really know much about how this works yet. 
D. Bindings? Same thing - I don't really know much about this yet. 
I will also need to string calculations of this type together in a different module. So I want to be reuse the logic. 
So - which rabbit hole should I be jumping down? I don't want to code myself into a corner. 

A:

It has been discovered to be useful, in general, to separate the user interaction logic (which corresponds, nicely it seems, to what you have described already) from the "business logic" (which appears to be what you're asking for).  The important thing is keeping them separate from each other, and you seem to have done that by writing one of them first.  So far, so good.
I don't think you need a "single backing object" as another answer suggested, but I agree that you need a single "model" in your code.  This could be one class or a number of classes; the important thing here is that they implement your logic without any dependence on the presentation to or interaction with the user.  The user could provide the numbers in any fashion and get them passed to the model, and it would return its answer, and something besides the model would determine how to present that answer.
So the listeners, for instance, that are part and parcel of a swing application (the user does something and a listener method fires): those are part of the user interaction.  If you got the input for your problem a different way, you wouldn't have those listeners, so they aren't part of the business logic.
I also think validation is part of your user interaction code, because if you change the way someone enters the numbers, then validation changes without having to know anything about how those numbers are used.  So I would validate the user's input before I fed numbers to the model doing the calculation; I would document that the inputs to that code are expected to be validated already, in case they're used again later by someone who doesn't realize it.
So when someone changes a value, I would expect there to be a listener (or some equivalent) fired that would validate input and produce a message for the user if there was invalid data; if the input is valid, I would expect it to call a method to do the calculation and return the value, and then that listener (or a listener for a SwingWorker thread, look that up if you don't know about it) to update the result on the screen (which should ALSO be done only in the user interaction logic.
You mention passing strings; I would also program the user interaction code, after validation, to convert string values to numbers where they are supposed to represent numbers.  The fact that they are strings on input is part of how the user interacts with your code, not part of the business logic.  If a program which got numbers from somewhere else wanted to use your calculation model, it would be odd and silly if it had to convert its numbers to strings just because your model was used to getting strings from users in this context.
I hope that's helpful.

