Science of Software - Computing Education Research

Learning Outcomes

Create an Eclipse project
Create a package
Create a class
Execute a program in Eclipse

Best Practice: Integrated Development Environments

When you first learned how to write Java programs, you probably started by writing code in a text file, compiling using the javac command, then running your program from the command line using the java command. This form of programming is what we’ll refer to as command-line programming, and it follows the practice of write/edit-compile-execute. While command-line programming has many advantages, it can be quite tedious. After all, your text editor doesn’t usually provide much outside of… well… editing. Professional developers gravitate toward integrated development environments (IDE) for their programming. The idea of an IDE is to integrate many different developer tools into a single program (such as code editing, compiling, running, file management, code navigation, documenting, version control, and so on). Programming with an IDE can provide some of the following advantages over command-line programming:

Compiling is built-in. Whenever you click Save, your code is compiled for you.
A controlled execution environment means that you can control how exactly your program will be executed without changing what your current system is configured for (such as running your program using different Java virtual machines).
A Graphical User Interface (GUI) provides immediate feedback on compile errors, warnings, and other problems with your project.
IDEs are highly customizable. From formatting and coloring preferences to programming in various languages and technologies, IDEs are extremely extensible.
Code editing and navigation is much easier because the IDE “understands” the language you’re working with (you’ll understand more of what this means with a few examples).
IDEs support large projects by providing many other tools not related directly to programming, but with software development in general.

In this Guided Project we’ll be covering Eclipse, a professional-grade, open-source development platform for Java (and many other languages!). While reviewing prerequisite materials, we’ll focus on some of the features found in Eclipse that are not found in command-line programming.

A note about audience. We assume the users for this tutorial are working on their own machines and can devote permanent space to their Eclipse work.

Conceptual Knowledge: Access Control

In Java, you can provide modifiers to fields, constants, and methods that determine whether other classes are able to access those elements. The public modifier, typically used on methods, means that any other class can call the method on an instance of the object (or in the case of a static method, on the class itself). The private modifier encapsulates or hides fields from direct access by other classes. The private access modifier is helpful for auxiliary methods that do not need to be exposed to a client class.

There are two other modifiers that you need to know about: no modifier (or default level access) and protected. If a Java element has no modifier, it has default level access, which means that elements of the class itself can access the given element AND methods of any other class in the same package can access the elements with default level access! Protected level access means that elements of the class, the same package, and any subclass can access the protected element (you’ll work with subclasses in GP2). The table below summarizes the access control modifiers.

Modifier	Class	Package	Subclass	World
`private`	Y	N	N	N
No modifier	Y	Y	N	N
`protected`	Y	Y	Y	N
`public`	Y	Y	Y	Y

Best Practice: IDE Customization

IDEs allow for customization of the workspace to help developers be more productive. Eclipse is a highly configurable IDE. You may find the following customization useful if you find the package names are too long for disambiguation in the Package Explorer view.

You can shorten the way that package names are displayed in the Package Explorer by selecting Window > Preferences > Java > Appearance. Check the box next to Compress all package name segments, except the final segment and enter 0 (zero) in the text box. Click OK. This will shorten the packages in your project to the last segment, in our case hello_world. When you look at the folder structure on the file system and the package imports in the source code, the full package remains.

Figure: Full package name in Package Explorer

Figure: Short package name in Package Explorer

Learning Outcomes

Create an Eclipse project
Create a package
Create a class

Best Practice: Integrated Development Environments (IDEs)

Use the Eclipse IDE to create a Java project, package, and class!

Learning Outcomes

Clone a GitHub repository
Share a project with a GitHub repository
Push changes to a remote GitHub repository

Best Practice: Version Control

A version control system stores the history of development on a given project in a central location. Additionally, a version control system provides mechanisms for teams to collaborate on the same code base. In a version control system, there is typically a remote repository that contains the main copy of the code and all of the development history or contributions of the developers. Developers have a local copy of the remote’s code where they can make changes to fix bugs or add new functionality. Those changes are then copied or pushed to the remote’s repository and are integrated into the main code base. Other team members can checkout or pull the changes from the remote to their local copies of the code and continue working on their development tasks. If there are major issues with a system, a development team can roll back to an earlier version of the code base.

Tools: Git and GitHub

Git is a distributed version control system. Git supports the creation of repositories, copying of repositories (cloning), committing changes, working with remote repositories, and merging changes. In Git, all repositories are considered equal and each maintain their own history. You can move information between connected repositories through pulling and pushing any changes.

When using Git, you will have a remote Git repository that exists on NCSU’s Enterprise GitHub server. That remote repository is where all of your files must end up for grading. You will have a local repository that is cloned from the provided remote repository. You will develop in your local repository and push your changes to the remote repository. If you’re working with a partner, your partner can pull your changes into their local repository and continue development. The workflow is similar if you’re using Git Bash or Eclipse EGit.

You will be using NCSU’s Enterprise GitHub, which is a web interface for working with Git repositories. The web interface provides a mechanism for viewing your remote Git repository (where all your work is submitted). Additionally, GitHub provides functionality for providing feedback on code and tracking issues.

To be assigned a repository, you must log into NCSU’s GitHub system with your unity id and password.

Learning Outcomes

Create fields
Generate getters and setters for fields
Generate a constructor for the fields
Generate overridden Object methods equals(), hashCode(), and toString().

Best Practice: IDE Code Generation

Many IDEs have tools that help with common tasks, and some of those tools can help you generate code. You learned how to write these code statements manually in your introductory programming class so that you would fully understand their purpose. Now you can use Eclipse’s code generation tools to help you write common statements. A benefit of using code generation tool, besides saving time, is that the code is more likely to be correct. However, you should always test the generated code to make sure that it meets the requirements of the larger program.

Conceptual Knowledge: Encapsulation - `private` Fields

An important concept in object-oriented programming is the idea of encapsulation. Encapsulation is the protection of an object’s state. Encapsulated classes are achieved through private fields. If a field is private, that means it can be changed only through the object’s methods (or behaviors). The methods provide a controlled way to change the object’s field and can help ensure that any object invariants (e.g., rules about the object’s state that must be true at all times) are not violated by a client.

That’s why all of the fields listed below are private.

Conceptual Knowledge: Encapsulation - Getters and Setters

Since methods provide the mechanism of mutating or changing the contents of a field, you should write them carefully in order to control the change that a client can make to the private fields. One example is to make fields that might mutate an object’s data private or not add them to the class.

As you design a class, you should think about when a class should and should not be able to access and change a field and plan accordingly.

For your Course class, you will provide getters and setters for all the fields. The setters will be implemented to ensure that clients of Course are unable to change Course fields to invalid values.

Best Practice: Comment Code as You Implement!

Commenting code is important to let others know what your classes, fields, and methods do. It is also important for reminding future you about you implementation.

Do not wait until the last minute to comment your code; comment as you work on things. Even better, you can write your code skeleton and comment the skeleton before you begin writing code. That helpe you think about what a method should do or what a field means before you start trying to implement something!

Conceptual Knowledge: The Java Invariant of Overriding `equals()` and `hashCode()` Methods

The specifications of the Java programming language state that both the equals() and hashCode() methods should be overridden. Additionally, the same fields considered for equality in the equals() method should be used to generate the object’s hashCode().

A hashCode is a numerical value for an Object that is generated from the Object’s fields. The algorithm to create the hashCode is such that every distinct object should hash to a different value and objects that are the same should hash to the same value. This means that every Object can be identified by its unique hashCode.

The default implementation of hashCode() uses the Object’s memory location to generate the hashCode(). But if we want to provide a different definition of equality to our objects, we should also ensure that those same objects have the same hashCode!

To ensure this, Eclipse requires us to override equals() and hashCode() at the same time using the same fields.

Best Practice: Comment `equals()` and `hashCode()`!

You should always comment overridden methods to provide details about the specific of the override and why the method was overridden. This will help others (and future you) understand the customizations of the overridden method for your class.

Learning Outcomes

Use private methods to hide setters from a client
Call setter methods from a constructor
Follow one path of construction paradigm

Best Practice: Reducing Redundancy

You learned in your introductory programming course that methods or procedures were created to provide a name for a related set of program statements that are likely to be used over and over. While there is a small cost to every method call, the gains in code readability, understandability, and maintenance are critical for teams of software developers working on large programming projects. When working on code, you should remove redundant code as often as you can!

Best Practice: Use the Outline

The Outline View provides a list of the fields and methods in the class that is currently in focus in the Editor. You can sort the members listed in the outline view in several different ways. By clicking a member in the outline view, the editor will be updated to display that element. It’s a lot faster to click a method in the outline view than to scroll through your code. Give it a try to select setName().

Conceptual Knowledge: Encapsulation - `private` Setters

Setter methods are convenient for wrapping up all the (potentially complex) functionality for checking that a value is valid for storage in a class’s field. However, you may not want to expose that functionality to a client. private methods provide a mechanism for wrapping up functionality in a method that can be used internally within the class as a helper method for setting the values for a given field.

Conceptual Knowledge: Reducing Redundancy

Another consideration when designing classes is that if you do have code that checks if a field receives a correct value, you should have that code in only one place. A setter method for a field may be appropriate. Other methods that change the field can call the setter with the appropriate value and handle an incorrect value as needed for the calling method’s goals.

Conceptual Knowledge: One Path of Construction

When writing a class, you want to minimize redundancy. That is one reason why you want to create setters for checking that the values stored in a field are appropriate for the class. Another way to minimize redundancy is to create one path of construction for a class. In Java, a class can have multiple constructors with different sets of parameters to initialize a class. One constructor should call another constructor (with appropriate default values for any missing fields) so that there is the main construction code in only one location. And that code can call (or delegate to) the appropriate setters for setting field values so that the code for checking for a valid field value is in only one location.

You call another constructor in a Java class using the keyword this().

By having one location for functionality, it’s much easier to maintain your code. If there’s a bug, you only have one place that you need to look to find and fix it!

Learning Outcomes

Create a test/ source folder
Create a package in the test/ folder
Create a class for testing
Run JUnit tests

Best Practice: Unit Testing

During the test phase of development, you execute the program against a variety of inputs to evaluate if the program generates the correct or expected output. You can determine the expected output by reading the requirements as well as the design documentation and APIs that define what the smallest program units (methods) should do.

Unit testing focuses on testing the smallest units of a program: methods and classes. The premise is that by ensuring the smallest portions of the programs work correctly, you can have increased confidence that the whole program will work correctly.

When you unit test for CSC 216/217, you are actually doing a combination of unit testing and integration testing. Integration testing is when you test things in combination. You will test methods in combination (e.g., adding something to a list and then removing it) and you will test methods that call other methods (e.g., a constructor calls a setter method). However, your focus is on the very local functionality of that method or combinations of methods within a class and not the program as a whole.

Tool: JUnit

JUnit is an automated unit testing tool for Java. JUnit is a set of libraries that include classes, like TestCase, and methods, like assertEquals(), that help with unit testing Java code.

For Guided Project 1, all unit tests will be provided so you will be able to assess the quality of your work as you progress through the tasks. Later, you will be expected to write your own tests and your implementation will be exercised against a hidden suite of teaching staff tests that will assess how well you meet the teaching staff design on the project!

Best Practice: Use the Java Perspective

Running PMD will switch you to the PMD perspective, which doesn’t have some of the helpful tools for developing Java code. Switch back to the Java Perspective after running PMD!

Best Practice: Using .gitignore

We recommend adding the configuration files associated with the static analysis tools to your project’s .gitignore file. This is especially helpful when working on teams!

You can edit .gitignore directly by opening the Project Explorer, selecting the filter icon, and unchecking the .* resources item. The dot-files will then display in the Project Explorer. Switch back to the Package Explorer when developing.

Learning Outcomes

Write setter methods for Course to pass the unit tests and meet the requirements.

Best Practice: Test Driven Development (TDD)

Test driven development is a software development practice where you write your test cases for a class using the requirements BEFORE you write the code for the class. The failing tests then drive the development of your class! You keep fixing your code until your tests pass.

The teaching staff has provided a set of unit tests that you must now pass!

In TDD practice, you may not always write your test cases first. Iterating between code and test (and not putting off testing) is critical for writing high quality code!

Conceptual Knowledge: UML Class Diagrams and Notation

We use a Unified Modeling Language (UML) Class Diagram to provide a visual representation of our design. Class diagram show the classes, their fields, and methods. Class diagrams also show the connection or relationships between classes. By interpreting the icons and information in the class diagram we can create a code skeleton of the classes, fields, and methods for our program. We’ll use the information in the Course class box to create our constants.

The constants are in the middle portion of the Course box, which is labeled as part of the edu.ncsu.csc216.wolf_scheduler.course package. The constants are noted in the left portion of each line by the red outline of a square labeled with an ‘S’ in the upper left corner and ‘F’ in the upper right corner. We interpret the red outline of a square as the keyword private. The ‘S’ represents static. The ‘F’ represents final. The name of the constant is next; an example is SECTION_LENGTH. This if followed by the type of int and the value it is assigned of 3. We would interpret the line in code as private static final int SECTION_LENGTH = 3;.

The other icons in the class diagram tell use different things. The outlines of circles, squares, and triangles represent fields. The solid circle, squares, and triangles represent methods. Green circles are public, red squares are private, and yellow triangles are protected. ‘S’ is static, ‘F’ is final, ‘C’ is a constructor.

The lines connecting the classes represent fields. We’ll discuss those in further detail when we get to the WolfScheduler class.

Conceptual Knowledge: Exceptions

Exceptions are objects that we can throw to let a calling method (or the client of your method) know about a problem. By throwing an exception to a client when your method can no longer execute, you are letting the client determine how to handle the problem in that class’ context.

When we want to throw an exception, we must first construct it and then use the throw keyword to send the exception to the caller (see line 9 in the code snippet below). When we see the throw keyword, the flow of control switches from the current method to the caller (if an exception is throw in setInfo(), the flow of control would switch back to line 19 and immediately transfer to the first enclosing catch block). If the caller doesn’t catch or handle the exception, then the exception propagates to the the next caller. If an exception is never caught, then program execution will end.

/**
 * An example of throwing an exception.
 * @param info additional information for the instance of a class
 * @throws IllegalArgumentException when the parameter info is null or an empty string
 */
public void setInfo(String info) {
   if ( /* something is wrong with info */ ) {
      // error path - info is null or an empty string
      throw new IllegalArgumentException(); // construct the exception and throw
   }
   // continue with happy path
}

/**
 * The calling class - it's calling a method that may thrown an exception
 */
public void processInfo() { // note that this method could be in another class, including a test class!
   try { // wrap around code that may throw an exception
      String s = setInfo();
      // continue with happy path
   } catch (IllegalArgumentException e) {
      // handle exception
   }
}

Best practice is to catch and handle exceptions rather than let them escape and stop program execution, but you don’t want to wrap all your code in try/catch blocks. There’s a balance to working with exceptions. If your code is trying things that are likely to throw an exception, then wrap in a try/catch. Otherwise, if the exception is unchecked, meaning that you are not required to handle it for compilation, you could chose not to explicitly try to catch the exception.

You should always provide documentation about exceptions that your method might throw to help clients identify if they should catch a possible exception. Use the @throws tag to document. You can also describe error paths in the main comment body.