ECS414U/A - Object Oriented Programming

Miniproject guidelines

Lecturers: Bruno Ordozgoiti & Matthew Huntbach

Where to start

If you don’t even know where to start, read this. The purpose of this section is to get you unstuck.

Start by thinking about what you want your program to look like in the simplest version imaginable.
For example, if you are implementing the investment trading app, perhaps you want users to have the
option to buy shares, sell shares, and see their portfolio.

With this in mind, you can already start writing some code. Write a program that prints a menu with
the available options and reads the user input, as follows:

Choose an option an press ENTER:

1. Buy shares.
2. Sell shares.
3. See portfolio.

You can see how to read keyboard input here:

• https://stackoverflow.com/questions/17538182/getting-keyboard-input
• https://docs.oracle.com/javase/8/docs/api/java/util/Scanner.html

This would not yet constitute a valid submission, but it is a way to break the ice. Now that you have a
working program—even though it is an empty shell—, you can start thinking about the design. What
entities could be modeled as objects? What attributes and behaviour do they have? What relationships
are there between them? For instance, here you may consider users and shares. Shares have a price, and
users have a list of shares they own. If a user chooses to “Buy shares”, a share is added to their list.
The next step could be, for example, to display the list of available shares and their prices, so that the
user can choose.

You must spend some time thinking about how you want to represent these entities with classes and
objects, depending on the features you want to implement. Note that you can also define classes for
more abstract notions, or simply to help organize your code. E.g. some class could just hold some useful
constants and static helper methods, like the class Math in Java.

Once you’re done with this, you may be getting close to a Level 1 submission!

Remember: keep it simple. This is a class exercise, so your project does not need to be completely
realistic.

This “ice-breaking” exercise applies to the other themes. For the game, you may at first have the
option of, say, “Attack enemy”, “Retreat” and “See HP”. For the business dashboard it could be “Hire
employee”, “Fire employee” and “See list of staff”.

1
Guidelines for the different levels

As specified in the instructions, in order to be eligible for the marks at each level you will need to satisfy
certain requirements. If you are unsure about what is required exactly, this section may help you.

For each level we provide a brief explanation of how to satisfy the requirements, as well as a non-
exhaustive list of mistakes that will result in point deductions. It is impossible to explicitly list all the
mistakes you could possibly make, so you may also get deductions for other clear deficiencies, which
show that you have not understood basic concepts taught in this course. Nevertheless, since this is your
first OOP course, we will be flexible with regards to some of the more subtle and advanced principles of
OO design.

Level 1

At this level you should show that you understand basic OOP and good programming principles. We
will illustrate this with an example.

Suppose we want to simulate an app for a veterinarian clinic. We want to keep records of the different
dogs we treat, and for each dog we keep its name and breed.

The following is an example of a bad submission, at risk of obtaining 0 marks (as it makes no use of
OOP):

public class VetApp{

static String[] dogNames = new String[10];

static String[] dogBreeds = new String[10];
static int dogCount=0;

public static void main (String[] args){

while (true){
System.out.println("Choose an option;");
System.out.println("1. Add dog.");
System.out.println("2. See dogs.");
System.out.println("3. Exit.");
... // Handle input here
if (userInput == 1){
... // Read input for name and breed
dogNames[dogCount] = dogName;
dogBreeds[dogCount] = dogBreed;
dogCount++;
} else {
...
}
}
}
}

The example above is bad for various reasons. Among others:

• It makes no use of object-oriented principles.

• The whole program is in one big class.

• Literals are used where variables or constants should be (10 dogs max).

2
 • It doesn’t handle potential errors and may crash (what happens if I try to add 11 dogs?).

A better version of this program would introduce a class to model dogs, with the corresponding fields to
model their attributes. As mentioned in the previous section, note that you can also define classes for
more abstract notions, or simply to help organize your code. E.g. some class could just hold some useful
constants and static helper methods, like the class Math in Java. Not every class needs to correspond to
a distinct object of the real world.

Other examples of mistakes that will result in point deductions at this level are the following:

• Breaking encapsulation. E.g. declaring fields with non-private visibility without providing a good
reason; or exposing a private array, so that it can be modified from outside the class definition
unintendedly (see the solution of lab 3, in class Agent).
• Unnecessary code duplication. For instance, if you have overloaded methods or constructors, any
common behaviour inside them should be factored out whenever possible.
• Your program crashes when carrying out one of the intended functionalities, in a way that could
be prevented without the use of exceptions.

Level 2

At this level you should show that you understand inheritance and polymorphism.

Try to think of the inheritance hierarchy. Are there entities in your project that obey the is-a
relationship represented by inheritance? E.g. stocks and bonds are types of assets, orcs and trolls are
types of enemies, directors and assistants are types of employees.

Remember that the important thing is to get the code right. For instance, if you don’t quite get the
difference between stocks and bonds right, it’s fine. We are not evaluating your knowledge of financial
markets.

However, your inheritance structure must make sense. For instance, it seems rather bizarre that Animal
should inherit from Dog, or Dog from Cat. Non-sensical relationships like those may be severely penalized,
unless you can provide a good reason. You must also avoid the common mistake of using inheritance to
model a has-a or belongs-to relationship (e.g. Wheel extends Car).

Polymorphism is a key requirement at this level. Incorrect or missing polymorphism will result in
major deductions.

Examples of mistakes that will result in point deductions at this level are the following:

• Non-sensical inheritance relationships such as the ones above.

• Failure to factor common class members out to a superclass when appropriate. E.g. you have a
Dog and a Cat class, both with field String name, and a method public void eat().
• Failure to use the keyword abstract correctly. E.g. a superclass is never meant to be instantiated,
but is not declared as abstract.
• Failure to implement polymorphism correctly. Note that polymorphism requires a superclass ref-
erence, which can dynamically point to objects of subclasses with different behaviour (i.e. that
override some method of the superclass, or implement an abstract method in different ways).

Level 3

At this level you should show proficient use of the more advanced constructs seen in class, such as file
I/O, generic collections, exceptions and GUIs.

3
You should use exceptions judiciously, so that they do not clutter your code. A rule of thumb is that
you should handle an exception if it is reasonable to expect the program to recover from it. Incorrect
user input and non-existent files are examples of good opportunities for exception handling.

Generic collections should always be used instead of arrays, unless you have a good reason.

Examples of mistakes that will result in point deductions at this level are the following:

• Not handling exceptions that the program should recover from, such as user input mistakes.
• Incorrectly modifying ArrayList objects. E.g. removing items while traversing the collection with-
out using the adequate iterator method.

• Inadequately handling stream resources, such as failing to call close on a reader.

• Failing to implement basic GUI features, such as the ability to close a window.
• Unstable GUI (make sure you test it thoroughly).
• Plaguing the code with unnecessary exception handling, making it hard to read.

General recommendations

Remember to keep it simple. Your goal is to show your understanding and mastery of the concepts seen
in class. If you make your code overly complex, or rely too much on external libraries, it may become
difficult for you to guarantee the stability and correctness of your project.

Remember that your program must compile with javac on the ITL machines, so think twice before using
external libraries.

Remember as well to seek feedback from the module staff to evaluate your progress.