created: 20200702091026430
modified: 20200707005526287
section: 3.1
tags: lab02
title: /Labs/02/Create the Product Domain Class
type: text/x-markdown

The following is the domain model for the course project.  This is a subset of the project that was designed in INFO201.  It is enough to be reasonable representation of the much larger INFO201 project, but without a few of the bells and whistles.

{{/Labs/02/images/Project Domain Model}}

1. Create a new class that represents the `Product` domain class.

    You use <<menu "File > New File > Java > Java Class">> to create a regular class.

    Domain classes should be placed in a package named `domain`.  You can type the package name directly into the <<menu "Package">> text field.

    Remember to stick to the naming conventions described in lab 1.  Classes should start with an uppercase letter, and packages should be entirely lowercase.

    It is important that you get this right before committing since trying to change the case of committed files/packages can be tricky due to some of the systems we are using being case sensitive (Git and Java), and others being case insensitive (file systems).  Always take the time to double check your spelling, and capitalisation before clicking the <<menu "Finish">> button when creating new files.

1. Add fields to the class as shown in the class diagram.

    Remember that the industry convention for naming fields, methods, and variables in Java is to use a lowercase first letter.  The only things that should start with an uppercase letter are type names (such as classes and interfaces).

1.  Get NetBeans to insert getters and setters for these fields by using <<keys "Alt > Insert">>.

1.  Add a `toString` method that returns the ID and name. You can use <<keys "Alt > Insert">> again to generate the method.

1.  Now would be a good time to commit.  Replace the commit message each time, do not append to the existing message --- NetBeans annoyingly remembers the last message that you used which is rarely useful --- just delete it each time and start from scratch.

    Since we are now using the issue management features of GitBucket we should link our commits to our issues.  You can do this in the body of the commit message:

    ```
    Add product domain class

    References #1.
    ```
    The hash character is important.  The number relates to the issue number which you can see by viewing the issues on GitBucket.  If you get this right then GitBucket will link between the commits and issues so that you can navigate from one to the other.  This is quite powerful --- it allows you to see the commits (and the code that was changed by that commit) that relate to a particular issue.

1.  Look at the branches in the repository browser again.  We now have a commit that only resides in the local `master`.  You can see the local `master` is `ahead` of the remote `origin/master`.  The commit IDs for the most recent commits to each branch are also different.

    This is how you can tell if you need to push --- if your local branch is ahead of the remote branch then you have commits that need to be pushed.

1. Push to upstream. We are pushing now because we want to see the issue/commit integration on GitBucket.

   Now is a good time to discuss *upstream* and *origin*.  In most cases they are the same thing.  Origin is the name that Git uses to represent the remote server that your cloned from.

   NetBeans uses the term *upstream* since you are able to have many remote servers attached to the same repository.  NetBeans uses *upstream* to refer to whatever remote server you have set as the default remote --- in most cases it is the same as *origin*, but it doesn't have to be.

1. Browse the issues for your repository on GitBucket.  Click the title for issue \#1 to view the details.  You should see the commits that have been associated with this issue.  If you click the commit ID (the 7-digit ID on the right) you will see the code for this commit.

    This is a powerful combination.  You can now easily answer questions from your team mates such as:

    * How did we fix that data corruption bug we had a few weeks ago?

        You can look at the issue for that bug and then look at the linked commits.  You will be able to see the code that fixed the bug.

    * Did we remember to fix bug X?  I feel like we might have accidentally closed the issue without ever getting around to it.

         Look at the issue for X and see if any of the commit messages explicitly state 'Fixed bug X'.  Then look at the code associated with those commits and triple check.

    * Why did we implement feature Z this non-standard way?

         Find the issue for Z.  If your team is following good code review and documentation practices then there should be a comment thread associated with the issue that discusses/explains the reason for the non-standard implementation.

    We are only able to see the commits for an issue if we remember to reference the issue in the commit messages.  Remember to do this!

When you come to create the other domain classes, the commit messages for those should also reference this issue.