First and foremost, I don't know Swing and the capabilities or enhanceabilities of
JTextArea, so I can't comment on your decision to make it the central point of your solution (which @DanPichelman seems to question in his answer). For the argument's sake I assume that it's fine.
Whatever is wrong with it, such technical details are better discussed on StackOverflow - we focus on general design here, and thus I'll try to tackle the OOD aspect of your question.
You need to ensure that your class does not get too big. It can seriously hurt the maintanability of your code. How do you know when it's too big?
The simpliest factor is the sheer size of its code. There is no magic number that separates "overly big" from "still fine", but there's common sense and some rules of thumb. I'm quite liberal in this aspect, but by my standards any class being bigger than 200 or 300 lines of code raises a red flag.
The conceptual rule is the Single Responsibility Principle. What is the responsibility of your class - let's give it a working title of
It's displaying rich text. Displaying. That's its field of expertise. It shouldn't know a thing about the outside world, as it breaks encapsulation and adds a secondary responsibility to it.
The only form in which its "ability to be affected by button presses on the UI" should be implemented is exposing some public API allowing other agents to pass it content (in some understandable format) that it's able to display, or render. There is no reason under the sun why it would have to know about button presses on the UI, or the very existence of any buttons, for that matter.
For instance, formatting rules (that's the business logic in this case) are not of its concern.
JRichTextArea is a View, and it should be nothing but. Proper View is dumb and has no opinion about the data it displays. The alternative is known as a smart view anti-pattern.
Even rendering your content is not necessarily its job. If you wanted to add an option allowing your user to create and edit complex mathematical equations, should the mechanism be embedded in
These equations would not only be drawn on the screen, inside the text area. Printing documents would require drawing them in a graphic buffer. So the mechanism would better be moved into some separate
What about the content itself; the formatted text? It's data - it's not equal to its visual representation. The user will probably need to save formatted documents to disk. They are actually going to save the data, not its graphic representation from
The content belongs then to some sort of a Model class. That would be consistent with the MVC pattern. It's not a Holy Grail, but a good, universally recognized way to achieve separation of concerns.
Furthermore, interactions with the UI are a job for some sort of a controller class, delegating user commands to the model (eg.
RichDocument). The controller gets notified that such and such button was pressed (make the selected text bold, for example), and it tells
RichDocument what to do with the data.
JRichTextArea is at the end of this chain and its only job is to obediently display the results of this chain of operations.
This is one example of what I would call a 'serious' and 'professional' approach here.