Lab Exercise : Model-View Separation

This exercise is intended to help you practice clearly separate the "backend" Model (that has no dependencies on specific View classes (especially OpenJFX)) from the "frontend" View so it can more easily be varied as new frameworks or new kinds of devices are developed. The clearest way to achieve this goal is make sure none of your backend classes import anything from javafx.* (sometimes java.awt is okay since its utility classes have been used in all modern Java frameworks) and instead return requested or computed data when needed by the View.

Submitting your Work

At the end of lab, use Gitlab's Merge Request from your forked repository's master branch back to the original organization repository's master branch to submit your group's answers to the discussion questions and refactored code.

You only need to create one Merge Request, no matter how many commits you make, and you do not worry about potential conflicts since your request will not be approved (it is just an easy way for us to see changes you made).

Make sure the Title of your Merge Request is of the form "lab_browser - everyone's NetIDs".

Lab Workflow

In your Cell Society teams, complete the following activities:

1. On Gitlab, one person should fork the original project lab_browser into their own repository to allow pushing your group's changes
   • On the resulting project web page, go to Project Information → Members (in the upper left corner) to add your partner so both people in the group can access the same repository
   • Search for your partner's name and give them a Maintainer role in the project and choose Add to Project
2. In Terminal, all students should use git clone to copy the one forked repository to their individual machines so they can work on their own separate copies
3. In IntelliJ, all students should Open the cloned folder to create a new project on their personal machine
4. As a group, make specific changes to the browser code to both learn more about GUIs in OpenJFX and following a workflow to manage changes to the code as a team
   • In Terminal, practice using git push, git pull, and git merge directly AND
   • On Gitlab, practice using Merge Requests online to do the merge between branches and git pull to bring changes into your branch on your machine
   • Repeat as many times as needed, letting each person try the changes/GIT steps in related chunks

Note, there should be a LOT of GIT commits for this lab!

Principles

Individually, share your interpretation of the Single Responsibility and Open-Closed Design Principles and how they are represented in the refactorings made to the example_roulette and lab_hangman code. Collectively, try to come up with a slogan, catchphrase, or shortened description for each.

Refactoring: Encapsulating the Model

Start by using use Pair Programming to work together within one person's local repository to refactor the NanoBrowser class to split it into Model and View classes (since this is a fairly big and comprehensive change). 

Complete this refactoring in the following steps, mostly by moving the existing code to a new class and then calling the new methods in place of the old code:

• Create a new class, NanoBroswerModel, and rename the existing NanoBrowser class to NanoBrowserView.
• Analyze the NanoBrowser class to determine which instance variables should be part of the NanoBroswerModel class and which should remain in the NanoBrowserView class.
  • move the instance variables you decided on to the NanoBroswerModel class and create an appropriate constructor
• move any obvious methods over as well (those that use only the instance variables moved) and change them from private to public
• create new public methods in the NanoBroswerModel class with parts of existing methods that can be separated from the NanoBrowserView class
• Create a new instance variable within the NanoBrowserView class for the NanoBroswerModel
  • update the constructor to receive it as a parameter
  • update the Main class to create an NanoBroswerModel object to pass to the NanoBrowserView when it is created
• Fix the remaining syntax errors in the NanoBrowserView class, such as:
  • those that need to be changed to call the methods that are now in the NanoBroswerModel class
  • those that reference removed instance variables will require the creation of new methods in the NanoBroswerModel class and returning a value that can be used appropriately in the method (be careful not to introduce dependencies on any OpenJFX classes).
• Discuss what values you should return if you cannot return a proper URL (i.e., it does not exist or the given one was malformed).

Before continuing to the next part, use the suggested workflow to integrate the new version of the code with everyone else's copy of the code.

Adding and Merging New Features

Continue practicing using the suggested workflow to complete the following tasks by having each person take one set of tasks and integrating the changes after each step is complete. You are encouraged to discuss the changes with each other as you make them (either for better understanding OpenJFX or to avoid conflicts), but they should be coded independently. Note, the NanoBroswerModel changes should be very small and easy to complete (so most of the time will be spent figuring out the NanoBrowserView changes together) but doing them simultaneously will better help simulate working together in a project.