For this exercise you are given Java code that has been poorly engineered. Your task is to examine the code and refactor it to use a specific design pattern.
Once you have refactored the design to use the required design pattern, complete the GoF pattern card in the refactoring design document. Remember to use context specific names for your classes (i.e. avoid using names like "Context," "Client," "Subject," etc.). You should also write at least 2-3 sentences describing each class's role in the pattern within the context of this system; do not use generic descriptions of the class roles in the pattern (i.e. "This class is the observer," or "This class is the client.").
Create a UML diagram of your refactored subsystem. Your diagram should completely capture all of the relationships between classes in the subsystem using proper UML notation. Be sure to include the pattern stereotype for any class that is playing a role in the design pattern by including the name of the role in guillemets beneath the name of the class, e.g. <<Context>>
Finally, you should implement the refactoring on the provided source code and include your refactored code as a ZIP file along with your submission.
Download the ZIP file containing the source code for the current subsystem. Compile, and run the main application class. If you find it easier to copy the files into an IntelliJ project (or some other IDE), feel free to do so.
Once the program is running, you should see a JavaFX window with two text areas separated by a horizontal button. Welcome to the world's worst messenger program!
Type a message the following (or something similar) into the top text area several times at your normal typing speed: "The quick brown fox jumped over the lazy dog." You will notice that the characters appear sporadically in the bottom half of the window; this is because a thread is polling on a pre-configured frequency to check for the most recently typed character. The goal here is to try to adjust your typing speed to match the frequency so that the words that you type appear in the bottom half of the window without any duplicates or missing characters. You should try to get the text in the bottom text area to perfectly match the text in the top text area. Any missing characters are the result of polling too slowly (missed updates), and any duplicated characters are the result of polling too quickly (wasted cycles).
For example:
"Te uik rown fx jmpd ovr te lazy dg." indicates that you are typing too fast; each missing character represents a missed update.
"Tthee qqquicckk brroooown ffoxx juuuuuumppped overrr theee laaazzzzyyy ddoogg...." indicates you are typing too slowly; each wrongly duplicated character represents a wasted cycle.
You are likely to see results that combine both errors (because your typing speed will vary even as you try to match the polling frequency).
Once you are finished playing with the messenger tool, begin working on your refactored design. You should eliminate the need to poll by introducing the observer pattern into the system so that, regardless of the speed at which the messages are typed into the top text area, the message is perfectly replicated in the bottom. You should minimize the number of classes that you touch and as much as possible preserve the observable behavior of the system.
By the time specified in the course schedule, submit your refactored design document, and your refactored source code Observer Refactoring dropbox.