Cody Wade wrote:I didn't want to post the code because it is badly done, a stupid project, and I'm frankly a bit embarrassed.
You wouldn't be the first programmer to do that. Hands up anybody who never did that? Anybody? ...... Nobody? ..... Okay then.
And this is where my issue is. I want the XMLParser to write its output to the JTextArea from FirstClass.
But you shouldn't want that. The job of the XMLParser is to parse an XML document and (from what you say) to produce some output. You shouldn't also make it responsible for writing its output to some GUI component; if you do that then you don't have a simple description of what it's responsible for, and that's a symptom of poor object-oriented design. (The description would say "Must parse an XML document into (some text format) and write that text into a text area"; when you see the
word "and" in a description you know it isn't right.)
That's really what we are talking about here, object-oriented design. You haven't done that yet (not surprisingly for a beginner) and so now you're stuck in the mud. You're still talking about classes calling classes (again, not surprisingly for a beginner) and that isn't all that helpful once you get more than one class.
So let me see if I can say something useful about the classes you have there. You've got a Menubar object. You say it creates a menu bar, and then it's also calling an XML parser when some menu option is selected. There's that word "and" again... but really the creation of the GUI components is incidental. Let's just say it has a menu bar; it might create that itself in its constructor, or it might get it in some other way. Its main purpose is to act on menu-bar clicks.
And when one particular menu item is clicked, it's supposed to act on that by calling an XML parser and dealing with the output of that parser. Specifically it's supposed to deal with that output by writing it to some other GUI component. But that GUI component isn't part of the Menubar class, so it's the responsibility of some other object. Therefore to deal with the output, the Menubar object has to contact that other object and say "Hey! Here's the text you need!". It isn't up to the Menubar object to know that it's going to be put into a GUI component, that's not Menubar's business. It's up to that other object to know what to do with the text. Let's call it a TextHandler for now. Since it's nobody else's business what a TextHandler is going to do with that text, TextHandler just needs a method which accepts a
String.
Now notice I've been talking about objects and not about classes. All of the work in your system is going to be done by objects and not by classes. So you'll need a Menubar object to do Menubar stuff, and a TextHandler object to do TextHandler stuff. And since the Menubar object needs to pass information to the TextHandler object, it needs to keep a reference to the TextHandler. That way it can call the TextHandler's method which accepts the String.
So: Object-oriented design includes a division of responsibilities. Each object has a single responsibility and each system requirement is handled by only one object. As far as possible, that is. That's what I have been describing here and it should coincide with the crude example I posted earlier. At least I hope it does.