Lab Coding Exercise: Separating the Model and View

This exercise is intended to help you to learn to separate a program's concerns by focusing on modern program's two major parts: the model, typically called the backend, is the dynamic data structure, its "knowledge", logic and rules; the view, typically called the frontend, is a visual representation of the model and can be any number of output representations of information and ways to interact with the data. One feature of this de facto design standard is that these parts can typically be developed and tested separately.

Submission

While there will not be an official submission for this exercise, this code will be the basis for this week's programming exercise.

Lab Workflow

Here is a review of the steps you will use to work with GIT during lab (as distinct from assigned team projects):

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 Settings -> Members 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, both 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, both students should Open the cloned folder to create a new project on their personal machine
4. In IntelliJ, add the names and NetIDs of everyone in your group at the top of the DISCUSSION.md file included in the repository
5. As a group, discuss how to change features in the current code and what design issues that reveals using the questions below as a guide
• Report your ideas, reasoning, and the main conclusions in the file DISCUSSION.md using Gitlab's Markdown format
6. In IntelliJ, refactor the code to improve its design (i.e., edit the code) using Pair Programming
7. In Terminal, use GIT to
• git add changed files
• git commit -m to describe your changes
• git push changes back to Gitlab
• git pull changes from Gitlab back to the local machine (if you are not sharing a single computer)
• Repeat as many times as needed, letting each person try the changes/GIT steps in related chunks
8. As a group, discuss the refactored design using the questions below as a guide.
   • Report your ideas, reasoning, and the main conclusions in the file DISCUSSION.md using Gitlab's Markdown format

Specification

This project implements a basic (nano-small) web browser where OpenJFX handles all the work to display the website's HTML and your code handles the data structures to model different ways to work with the websites (represented as URLs) such as: history of sites visited, favorite sites, most visited sites, etc. Currently, only history is implemented but adding the other features is complicated because the model and view code are mixed together.

Take some time to play with the program and also explore the code to make sure you understand how it works.

Discussion

As a reminder, the goal of separating these two concepts is to create a "backend" model that has no dependencies on specific view classes (like OpenJFX) so that the "frontend" 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 the javafx package (sometimes java.awt is okay since its utility classes are used in all modern Java frameworks) and instead return requested or computed data when needed by the view.

Examine the code to identify what behaviors are associated with URL data and what are associated with the display of the URL's contents. Note, methods may interact with both sides and will likely need to separated out themselves to achieve your goals.

Here are some questions to get your discussion started:

• In the maze project (and in general), the view references the model but the model does not reference the view. How would you justify this design choice?
• What behaviors should the model have that will be called by the view?
• What instance variables will be needed to support those behaviors?
• What values should the model return that can be used appropriately in the view?
• What values should the model return if you cannot return a proper URL (i.e., it does not exist or the given one was malformed).
• How will you test the model?

Finally, consider adding common modern browser features (like a favorites map of title to URL) to the program:

• What common abstraction would help you implement new browser features (like favorites, most viewed, etc.)?
• How would the model manage the concrete implementations?
• How would the features follow the goal of separating the model from the view?

Refactoring

Refactor the NanoBrowser class based on your discussion to thoughtfully, deliberately, split it into separate model and view classes in separate packages.

The following example steps show moving the existing code to a new class and then calling the new methods in place of the old code so that you always feel in control of the changes being made to the code when refactoring:

• Create a new class, NanoBroswerModel, and rename the existing NanoBrowser class to NanoBrowserView.
• Create an instance of the NanoBroswerModel class (even though it has no methods) in the main() method, pass it to the NanoBrowserView class's constructor, and assign it to an instance variable.
• Move the instance variable you have identified as the responsibility of the model that is least used to the NanoBroswerModel class and the active method(s) that use it (rather than simply making a passive getter/setter for the variable).
• Fix the syntax errors by changing direct uses of that instance variable to public method calls on the model's method that return a useful value to the view.

Practice using refactoring safely so you are not stuck with a lot of syntax and logic errors that ruin your larger design goals!

Pair Programming

Labs in this course expect you to work either in pairs or with your project team.

Professionally, this practice is called Pair Programming: working closely with another programmer, sharing a "single computer" that we will simulate using a shared computer, shared repository or use IntelliJ's new Code With Me feature. To ensure both people do some coding, you will switch which person actually writes the code every 10-15 minutes (in industry this switch happens only 1-3 times per day). The person who is not actively coding can be advising, suggesting better names, looking up documentation, or searching the Internet for solutions to small problems you are likely to face, but not multi-tasking (i.e., doing their own work or socializing).