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.
You will create a finite state machine diagram or, if you prefer, a UML statechart. This diagram will be the state machine for the code that has been provided to you.
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. You will need to refactor the provided class into a new design. If you find it easier to copy the files into an IntelliJ project (or some other IDE), feel free to do so.
The VendingMachine.java source file contains a class that simulates a simple vending machine that dispenses products such as soda or candy. All of the products in this vending machine cost exactly $1.00. The behavior of the vending machine's various methods to insert coins, dispense products, or refund coins that have been inserted depends on the amount of money that has been inserted.
You will refactor the VendingMachine class to use the State pattern. You will first need to analyze the code to determine what the possible states are, and what events trigger transitions from one state to another. You should capture this behavior as a finite state machine diagram (or UML statechart, if you prefer) before you attempt to refactor the code into the new design.
You have been provided with a JUnit 4 unit test that tests the various vending machine methods in different states and verifies the expected output from the machine. Feel free to examine this test class if you'd like, but don't worry if you don't understand what it does or how it does it. You will need to run this test after you have completed your refactored design to verify that the vending machine's observable behavior has not changed.
If you are using IntelliJ, support for JUnit 4 is integrated into the development environment. The JUnit test file will not compile by default in a new project. In IntelliJ, you will need to open the test file in the editor and click to place your cursor on one of the @Test attributes. Then use alt-enter to add JUnit 4 as a dependency to your project. If you are using an IDE other than IntelliJ, you are on your own to figure out how to get JUnit 4 to work with your IDE.
By the time specified in the course schedule, submit your refactored design document, and your refactored source code State Refactoring dropbox.