When writing code, we want to reuse much of the old code we've written as possible. We shouldn't have to constantly re-invent the wheel and rewrite the same code over and over, nor should we take old code and copy-and-paste it everywhere we need it. After all, having to both copy and maintain copy-pasted code is tedious. If we were to copy-and-paste, and later discover a bug in our code, we'd suddenly have to go back everywhere we copied-and-pasted and fix every instance of the bug which is boring and error-prone.

We call repeated code redundant code, and a large part of this class is oriented around being able to detect and eliminate redundancy.

As an example, consider the following code:

// Produces the following output: 
// 171717171717
// 444444444
// 00000000 
public static void main(String[] args) {
    for (int i = 1; i <= 6; i++) {
        System.out.print(17);
    } 
    System.out.println();
    for (int i = 1; i <= 9; i++) {
        System.out.print(4);
    } 
    System.out.println();
    for (int i = 1; i <= 8; i++) {
        System.out.print(0);
    } 
    System.out.println();
}

If we look at the expected output, we can see that there's a definite pattern and a fair bit of redundancy: we print a value a certain number of times. We consider this sort of repetition redundant and not very concise. The code in the above sample also happens to look very similar to each other, though that is not always the case – code does not need to look similar to be considered redundant. Consider:

// Produces the same output as above
public static void main(String[] args) {
    System.out.println(171717171717);
    for (int i = 1; i <= 9; i++) {
        System.out.print(4);
    } 
    System.out.println();
    int i = 0;
    while (i < 8) {
        System.out.print(0);
    }
    System.out.println();
}

While this code snippit doesn't really have "repeated code," it should be clear that both blocks are redundant.

We can improve on both versions by making use of methods to eliminate redundancy like so:

public static void main(String[] args) {
     printNumber(4, 9);
     printNumber(17, 6);
     printNumber(0, 8); 
}

public static void printNumber(int number, int count) {
    for (int i = 1; i <= count; i++) {
        System.out.print(number);
    }
    System.out.println();
}

This code is pretty simple, but illustrates our goal when dealing with redundancy. In many programs, we have tasks that we need to perform more than once – if there is such a task, it's important to make sure we don't write the same code for it twice.

This is usually more straightforward in 142, but as code gets more complex, we occasionally have two code blocks that are similar enough to seem redundant, but different enough to make us pause before creating a generalized function to handle both cases.

In these cases, it's helpful to think about your methods not in terms of their similar code, but in terms of their purpose – if the code blocks are performing the same task, such as printNumbers above, it's probably a good idea to reduce the code. However, if the code blocks are performing fundamentally different tasks, you should pause before creating a generalized method. A method should stand alone and have a single purpose.

For example, let's say that I have the following method:

public static void printTree() {
    System.out.println("  **  ");
    System.out.println(" **** ");
    System.out.println("******");
    System.out.println("  **  ");
    System.out.println(" **** ");
    System.out.println("******");
}

The redundancy in this method is pretty obvious: we're repeat the exact same set of printlns twice. Now, let's say we refactor that:

public static void printTree() {
    printTriangle();
    printTriangle();
}

public static void printTriangle() {
    System.out.println("  **  ");
    System.out.println(" **** ");
    System.out.println("******");
}

If we take a look at our original method, we were in essence performing exactly six logical operations: we had six printlns.

Now, if we look at our newly refactored printTree method, it looks as if we've simplified it down to just two operations: two method calls.

Of course, in the end, we still need to run six println statements, but within the context of printTree we've turned six "operations" into just two, which is a net improvement. As a result, we know that this was a good refactoring to have performed.

What if instead we tried refactoring printTree to look like this?

public static void printTree() {
    myPrintln("  **  ");
    myPrintln(" **** ");
    myPrintln("******");
    myPrintln("  **  ");
    myPrintln(" **** ");
    myPrintln("******");
}

public static void myPrintln(String line) {
    System.out.println(line);
}

In this case, we didn't end up reducing the logical redundancy at all. Our printTree method started off with six operations, and after our refactoring, it still performs six operations. The method didn't end up getting any simpler, and we ended up gaining a method in the process, which is a slight net loss.

We may have less redundancy if we look at the amount of literal characters that make up our code, but that sort of redundancy is incidental to what the code is actually logically doing.

Let's take another example: the Pythagorean Theorem. It looks something like this:

double sideA = 3;
double sideB = 4;
double hyp = Math.sqrt(sideA * sideA + sideB * sideB);

Ignoring the variable assignment, this would be about four "operations" – we call Math.sqrt once, we multiply two times, and we add once.

Now, let's replace this with a method call:

double sideA = 3;
double sideB = 4;
double hyp = pythagorean(sideA, sideB);

This is a net gain for us – we've turned four operations into just a single one again. And if we're repeating the same calculation all over our code, we've just simplified every single one of them down into a single operation.

We can even be pseudo-mathematical if we want – let's say we want to compute the hypotenuse 10 times throughout our code. That means before refactoring, we had about 40 operations scattered throughout our code in order to compute the answer. After refactoring it into a method, we call the method 10 times and have the 4 operations inside the method – we're now performing about 14 operations in total. We've saved 26 operations in total, which is fantastic.

Of course, counting the number of "operations" is a bit of a fuzzy and subjective metric. It's also sort of pointless in the sense that the computer will run 40 operations regardless or not if we refactor. Reducing the number of operations is mostly something we do for the sake of readability and concision, and so you should use the number of operation simply as a rule of thumb to help you refactor. Eventually, you'll get to the point where you do not have to explicitly compute some arbitrary number and will instinctively feel when it's appropriate to refactor.

Now, let's take this from a different perspective. Let's say that we have the following code:

int a = 1;
int b = 2;
int c = a + b;

Setting aside the variable assignment, we have only a single operation – the addition. We could refactor this into a method, and do something like this:

int a = 1;
int b = 2;
int c = add(a, b);

...but that was pretty pointless – we're still doing only one operation, so never really reduced the complexity at all. We might be doing addition all over the place, but replacing every instance of addition with our `add` method doesn't simplify the code the same way it did with the Pythagorean Theorem algorithm. There's no net gain, and using `add` methods would most likely obfuscate and confuse the code.

Now, on rare occasion, it might still be good to make a method to wrap around a single operation, especially if that operation is really confusing -- see the section on trivial methods for more discussion on this topic.

However, this is really something you need to evaluate on a case-by-case basis. Would sticking your code into a method reduce the number of "operations", reducing the redundancy? And if not, is there some other technique you could be using instead? And finally, does the advantages in your case of sticking a single operation in a method cancel out the badness of having a trivial method with only one operation?

It really depends, and being able to determine when it's appropriate and when it's not appropriate to pull a chunk of code into a separate method is an important part of what we try and teach in CSE 142 and 143.

More specifically, we are not saying that each method has to be made up of literally a single operation or component – that would be silly. Rather, what we're saying is that your method should be responsible for doing only a single thing, and should delegate everything else to other methods and classes.

For example, take the following method which prints out a staircase, square, and rectangle in succession:

public static void drawArt() {
    for (int i = 1; i <= 5; i++) {
        for (int j = 0; j < i; j++) {
            System.out.print("*");
        }
        System.out.println();
    }
    
    for (int i = 1; i <= 5; i++) {
        for (int j = 1; j <= 5; j++) {
            System.out.print("#");
        }
        System.out.println();
    }
    
    for (int i = 1; i <= 5; i++) {
        for (int j = 1; j <= 20; j++) {
            System.out.print("@");
        }
        System.out.println();
    }
}

The code is really doing three separate things here: drawing a staircase, drawing a square, and drawing a rectangle. Forcing the method to explicitly handle all three of these things is giving it too much to do. When you're trying to draw art, you shouldn't have to worry how exactly a square is drawn. A better version would look something like this:

public static void drawArt() {
    drawStaircase(5);
    drawSquare(5);
    drawRectangle(5, 20);
}

// etc

Now, our drawArt is directly responsible for one and only one thing: drawing something. Our helper methods have now been placed in charge of drawing a staircase, drawing a square, and drawing a rectangle respectively.

Note that after completing this refactoring, we haven't decreased the amount of redundancy at all. This is ok – we did end up improving the overall readability, so we've experienced a net gain on that front.

In general, you should feel free to use methods to either reduce redundance or to help organize your code, or both.

In some cases, it can be more subtle and difficult to tell when it's a good idea to split apart an existing method. For example, take the following method, which prompts the user if they want to change their email address:

public static String tryGettingNewEmail(Scanner scan, String oldEmail) {
    System.out.println("Old email: " + oldEmail);
    String answer = "";
    while (!answer.startsWith("Y") || !answer.startsWith("N")) {
        System.out.print("Change email? (Y/N): ");
        answer = scan.nextLine().toUpperCase();
    }
    if (answer.startsWith("Y")) {
        System.out.print("New email: ");
        return scan.nextLine();
    } else {
        return oldEmail;
    }
}

An added complication to this method is that it will only let the user continue if they type in a string starting with either "Y" or "N". If they type in something like "maybe", this code snippit will treat that as an error and ask them again.

Should this method be refactored? At first glance, it seems like the method is already responsible for one single thing, and doesn't contain any obvious redundancy.

As it turns out, we can, if we treat the "select Y or N" part of the method as a distinct subtask:

public static String tryGettingNewEmail(Scanner scan, String oldEmail) {
    System.out.println("Old email: " + oldEmail);
    boolean userWantsChange = userSelectedYes(scan, "Change email?");

    if (userWantsChange) {
        System.out.print("New email: ");
        return scan.nextLine();
    } else {
        return oldEmail;
    }
}

public static boolean userSelectedYes(Scanner scan, String prompt) {
    String answer = "";
    while (!answer.startsWith("Y") || !answer.startsWith("N")) {
        System.out.print(prompt + " (Y/N): ");
        answer = scan.nextLine().toUpperCase();
    }
    return answer.startswith("Y");
}

Once we make this change, it's much easier to tell what each method is individually doing. Our tryGettingNewEmail email is also much more readable since we were able to take the subproblem of validating user input and split it off into a separate helper and use readable method and variable names.

This rule is really a logical extension of the previous rule, but it bears repeating.

You should resist the urge to try and cram too much code into your main method, since it'll then become too crowded and too difficult to read.

For example, you don't want your main method to look like this:

public static void main(String[] args) {
    for (int i = 1; i <= 5; i++) {
        for (int j = 0; j < i; j++) {
            System.out.print("*");
        }
        System.out.println();
    }
    
    for (int i = 1; i <= 5; i++) {
        for (int j = 1; j <= 5; j++) {
            System.out.print("#");
        }
        System.out.println();
    }
    
    for (int i = 1; i <= 5; i++) {
        for (int j = 1; j <= 20; j++) {
            System.out.print("@");
        }
        System.out.println();
    }
}

This is the same example as before. A good main method would look like this:

public static void main(String[] args) {
    drawStaircase(5);
    drawSquare(5);
    drawRectangle(5, 20);
}

// etc

Reading a main method should feel akin to reading a table of contents, and less like reading the entire book.

Be careful not to err to the other extreme. Don't write code that looks like this:

public static void main(String[] args) {
    doSomethingMinor();
    doEverythingElse();
}

public static void doSomethingMinor() {
    // ...etc
}

public static void doEverything() {
    // ...etc
}
// etc

While your main method is technically now summarizing your program, it's a very poor summary. To continue using our metaphor of the book, this is like seeing a table of contents with exactly two entries: "Introduction" and "Rest of Book". While you could technically write a book with such a table of contents, it'd be pretty useless.

This is an example of what a trivial method looks like:

public static void myPrintln(String line) {
    System.out.println(line);
}

This method does only a single thing – print a message. While on the surface, this method appears to simplify things (now, we don't have to keep typing System.out when we want to print things), this would NOT be a good method to write.

This is because if our method does only one thing, then it's sort of useless, since we could have just done that "one thing" up in the caller. Remember, we want to keep code logically concise and reduce redundancy, but don't really care about keeping code literally concise and doing things solely for the sake of lowering the character count.

This method also does not enhance readability in any appreciable way: the method name does not make it easier to understand what the underlying code is doing.

So, since this method does not enhance readability or reduce redundancy in any meaningful way, we call this a trivial method.

However, do note that not all one-line methods are trivial methods – this is a common misconception many students have. For example, take the following:

public static double pythagoreanTheorem(double sideA, double sideB) {
    return Math.sqrt(sideA * sideA + sideB * sideB);
}

Even though this method is only one line long, it's doing 4 separate operations (two multiplications, one addition, and one square root) so is definitely worthy of being refactored into a helper method.

However, it can sometimes on rare occasion be acceptable to write a method to wrap around an operation which does only a single thing if we gain some other tangible benefit as a result. For example, take the following segment of code:

public int foo() {
    // ...
    if (symbol == '~') { 
        // ...
    }
    // ...
}

Why are we comparing the symbol variable to a tilde? What is the significance of the tilde? We could leave an inline comment explaining, or wrap the comparison in a helper method instead:

public int foo() {
    // ...
    if (isStart(symbol)) { 
        // ...
    }
    // ...
}

public boolean isStart(char symbol) {
    return symbol == '~';
}

This is a trivial method, but we've redeemed it somewhat by giving it a more useful name which makes understanding the intent of the caller more clear. Contrast this to the initial println example – we gain zero clarity by wrapping System.out.println in a println method.

Also note that both versions of the above code would be acceptable. We don't need to wrap symbol == '~' in a method, after all. You also shouldn't go overboard on doing this sort of thing – new semantic name notwithstanding, this is still a trivial method.

In particular, you should:

1. Remove any parameters you've never used
2. Avoid passing in information that could be derived from other parameters
3. Avoid passing in information that could be derived from existing constants
4. Avoid passing in information that is already directly contained within fields (when working with objects)

The reasoning behind minimizing your parameters is it helps to minimize the overall complexity of your method. The more parameters you give a method, the more potential interactions (and therefore potential bugs) there will be between each kind of input you could possibly give the method.

You should adopt a mindset where you carefully consider each and every parameter you need to determine whether or not it's necessary, and not fall into the bad habit of adding parameters essentially at whim.

Note that we deliberately do not enforce any sort of limit on how many parameters a method is allowed. Some methods require none, others require one or two, and even more will require seven or more. Again, our emphasis is on whether or not each parameter is necessary or not, not on how many of them there are.

For example, it would be good style to return early in a scenario such as this:

public static String foobar(List<String> myCollection) {
    for (String s : myCollection) {
        if (checkSomething(s)) {
            return s;
        }
        // do something else with s
    }
    return defaultValue;
}

It would be inefficient to store the result in a variable and wait to go through the entire list if we didn't need to.

So, full disclosure. I personally hate the name "method chaining". I don't know if it's because of the name we gave it, or if it's because of how we teach it, but I've seen way too many students who seem to have a misunderstanding of what method chaining is, and actually end up writing code worse then they would have otherwise.

In fairness, this might be because it's rather difficult to explain what method chaining actually is without resorting to loads of diagrams and pictures. Let me start with what method chaining is NOT. The term "method chaining", as we use it in this class, does not refer to code that looks like this:

String bar = foo.method1().method2().method3().method4();

Code which looks like this is perfectly fine. It might be a good idea to split it up into several lines and use variables to help make it more readable, depending on what exactly you're doing, but there's nothing inherently wrong with this sort of code.

Method chaining also does not mean "helper methods calling helper methods". To the contrary, it's very much good style to have helper methods calling other helpers, especially if it helps reduce redundancy or helps make your code more readable.

So, what actually is method chaining? Well, I think it's something which is best explained visually. Let's say that I have a method named myMethod, and it does tasks A, B, and C. It doesn't matter what those tasks are – perhaps they're printlns, perhaps they're if statements, perhaps it's a return statement. Well, we can represent that method like so:

We have a single method, and it does four tasks in succession. In code, it would look something like this:

public void myMethod(){
    taskA;
    taskB;
    taskC;
    taskD;
}

This is good, regular, code. We want to do four things, and we do them one after the other. So far, everything's good.

Now, let's say that for whatever reason, you decide to write your code like this:

public void myMethod(){
    taskA;
    methodB();
}

private void methodB() {
    taskB;
    methodC();
}

private void methodC() {
    taskC;
    methodD();
}

private void methodD() {
    taskD;
}

Well, if we represent it as a flowchart, we basically get this:

Notice how that we've taken what's essentially a linear task, and arbitrarily made one method call another method call another method instead of taking the first approach.

THIS is what method chaining is – it's not private methods calling other private methods. Rather, it's taking what should be an inherently linear task and stringing it along, making the linearity non-obvious. What your code does is starting to become misaligned compared to the "form" or "shape" of your code.

It also makes your code far less modular. Previously, all four tasks were kept independent from one another, and could be rearranged, moved, and deleted at whim. Now, if you want to perform task A, you're forced to also perform tasks B, C, and D whether you want to or not.

90% of the time, the reason why students end up doing method chaining is because they want to pipe data from one function to another, but are afraid of using return statements. For example, they'll do this:

public void myMethod(){
    taskA;
    methodB(something);
}

private void methodB(String param) {
    taskB;
    methodC(something);
}

private void methodC(String param) {
    taskC;
    methodD(something);
}

private void methodD(String param) {
    taskD;
}

...when they really ought to be using returns, and do something like this:

public void myMethod(){
    taskA;
    something = methodB(something);
    something = methodC(something);
    methodD(something);
}

private void methodB(String param) {
    taskB;
    return something;
}

private void methodC(String param) {
    taskC;
    return something;
}

private void methodD(String param) {
    taskD;
}

...and linearize it. So really, if you look closely at it, method chaining often stems from a misunderstanding or reluctance to use parameters and returns. However, both students AND TAs seem to instead look at the most obvious issue (methods calling other methods) and think that's the main issue when really it's just a symptom of an underlying problem.

As a result, many students end up picking up the wrong instinct and become too paranoid about their code – they grow to incorrectly assume that method chaining is when methods call other methods or something, and that going too deep is bad. Again, there's nothing wrong with methods calling other methods. Take the following flowchart, for example:

This has method calling method after method – it's as deeply nested, if not more, as the previous flowchart. However, this would NOT constitute method chaining. Because the tasks that we're trying to do are inherently non-linear, it makes sense to have multiple helper methods and nesting. What the code is intending to do aligns well with the shape of the code.

So basically, method chaining is whenever you take an inherently non-linear task, and decide to string it along a series of methods (most likely due to misunderstanding how to use parameters and returns) and force a previously independent series of operations to become tangled and dependent – the net result is that you end up with a program with a poor "shape". It feels unbalanced and unhealthy.

If we think about it visually, healthy code is either flat (like a stick resting peacefully on the ground) or like a tree with lots of leaves and branches.

On the other hand, method chaining is like a dead tree, withered and decaying, about to topple over:

So basically, if your code looks like a forest fire hit it, you'll get deducted points for method chaining.

The reasons why we want you to minimize the number of fields you need to use are identical to those outlined in the section on Minimizing scope – the more fields you have, the more potential interactions there are between methods, and the higher the odds are of your program developing bugs.

Having multiple fields unnecessary fields also starts to violate the principle of modularity. If your method is dependent on 5-6 different fields to be in some particular state in order to function effectively, we really cannot say that the method is all that modular. Parameters and returns are the key mechanisms we should be using to pass data back and forth.

Fields should be reserved to store data which must be persisted between multiple independent calls to that method or other methods within the class, or when not using a field would result in drop in efficiency.

While making fields public may seem convenient at first, it frequently results in the client and implementor classes becoming tangled together. For example, say I wanted to create a Point class to represent an x-y pair of coordinates. In that case, I could naively do something like this:

public class Point {
    public double x;
    public double y;
    
    public Point(double x, double y) {
        this.x = x;
        this.y = y;
    }
    
    public double getMagnitude() {
        return Math.sqrt(x * x + y * y);
    }
    
    public double getAngle() {
        return Math.atan2(this.y, this.x);
    }
}

Point p = new Point(3.2, -6.6);
double newX = p.x * 2;
p.y = foo(p, bar);

And this might work, for a little while. But then, let's say that as I kept working on my program, I slowly started to realize that it would have been better for me to store the data directly as a magnitude and value – doing so would dramatically simply the math and angle calculations I'm doing.

But now I'm stuck. If change my fields to magnitude and angle, all of the client code I wrote before would no longer work since they were all directly accessing those fields. If I keep the x and y fields, and add the magnitude and angle fields on top of that, then my data would fall out of sync since some clients would modify some the data, but not all of them.

However, if I had forced the clients to manipulate my class exclusively through public methods, then this problem would have been a much easier problem to solve:

public class Point {
    private double magnitude;
    private double angle;
    
    public Point(int x, int y) {
        this.setXY(x, y);
    }
    
    public getMagnitude() {
        return this.magnitude;
    }
    
    public setMagnitude(double magnitude) {
        this.magnitude = magnitude;
    }
    
    public getAngle() {
        return this.angle;
    }
    
    public setAngle(double angle) {
        this.angle = angle;
    }
    
    public getX() {
        return Math.cos(angle) * magnitude;
    }
    
    public setX(int x) {
        this.setXY(x, this.getY());
    }
    
    public getY() {
        return Math.sin(angle) * magnitude;
    }
    
    public setY(int y) {
        this.setXY(this.getX(), y);
    }
    
    public setXY(int x, int y) {
        this.magnitude = Math.sqrt(x * x + y * y);
        this.angle = Math.atan2(y, x);
    }
}

Now, no matter what fields we use, we can always adjust our methods so that they continue work and the client can still use our Point class uninterrupted. If the client wants to do mostly x/y manipulations, they can still do so.

Unfortunately, in the pursuit of good style, we've ended up making our code fairly bloated, and a common question many students will have is if there's a way of accomplishing the same thing without having to tediously write multiple getter and setter methods.

There is such a way in other programming languages using something called properties, but alas, Java currently doesn't have properties, so we're stuck with writing out getters and setters for the foreseeable future.

Because writing getters and setters can often be tedious, we will on occasion explicitly grant you permission to make classes with public fields when the vast majority of the manipulations you do to that class is on those fields. Usually, we allow public fields on classes such as LinkedListNode or TreeNode which are primarily implementation detail anyway, are likely to be private inner classes to some LinkedList or Tree class, and so do not need a stringent interface.

You should never directly initialize your field, like so:

public class Foo {
    private int myField = 3;
    private Random rand = new Random();
    
    public Foo() {
        // ...
    }
    
    // ...
}

Rather, you should initialize everything inside of your constructor, like so:

public class Foo {
    private int myField;
    private Random rand;
    
    public Foo() {
        this.myField = 3;
        this.rand = new Random();
    }
    
    // ...
}

There are several reasons for this. One reason is that it's not always possible to directly declare and initialize certain fields, especially when our initialization code requires some additional logic.

The other reason is for consistency. In many cases, we need to initialize fields based on parameters that we pass into our constructor. In those cases, the only place where we can initialize our fields is inside the constructor itself, and having some fields be initialized in the constructor vs directly looks inconsistent:

public class Foo {
    private Scanner input;
    private int size;
    private Random rand = new Random();
    
    public Foo(Scanner input, int size) {
        this.input = input;
        this.size = size;
    }
    
    // ...
}

Again, an important aspect of style is consistency. If some of our fields need to be initialized in the constructor, then it's best to make all of them be initialized there:

public class Foo {
    private Scanner input;
    private int size;
    private Random rand;
    
    public Foo(Scanner input, int size) {
        this.input = input;
        this.size = size;
        this.rand = new Random();
    }
    
    // ...
}

However, do note that it is ok to directly declare constants like we always have been doing so far:

public class Foo {
    public static final int MY_CONSTANT_VALUE = 42;

    private Scanner input;
    private int size;
    private Random rand;
    
    public Foo(Scanner input, int size) {
        this.input = input;
        this.size = size;
        this.rand = new Random();
    }
    
    // ...
}

The reason for this is because there's no other way to do this: it's impossible to set a constant inside a constructor, or any other method (if you could, they wouldn't be constants).

The reasoning here is that by making helper methods public, you're exposing implementation detail that the client shouldn't be really need to know about.

If you want to intentionally add public functionality to extend the behavior of your class, you should not do that. When grading we have to be very strict to ensure that we're equally fair to all students, and even if your extension is a good idea, we'll probably have to dock you points because you've ended up ignoring portions of the spec.

For example, we would consider the following to be bad style:

public class Foo {
    private int myField;
    
    public class Foo(int data) {
        myField = transform(data);
    }
    
    private int transform(int data) {
        // ...
    }
}

The corrected version would look like this:

public class Foo {
    private int myField;
    
    public class Foo(int data) {
        this.myField = this.transform(data);
    }
    
    private int transform(int data) {
        // ...
    }
}

Both the field and the method belong to the instance, so we'll use the this keyword to explicitly indicate so.

The reason we are making you do this is because doing so will force you to explicitly think about what exactly an object is and how it works whereas omitting the this keyword will make it easier to forget.

For example, say we had an object which we use to represent a spaceship, like so:

public class Spaceship {
    private List<String> crew;
    private double fuelLeft;
    private String name;
    
    public Spaceship() {
        // ???
    }
}

There are multiple valid ways we could initialize the initial state of this spaceship. We might want to start by simply give the spaceship a name, leaving the crew and fuel remaining empty to start with. Alternatively, we might want to be super-detailed and give the spaceship the amount of fuel it has and its crew members to start with. Or perhaps we want to make use of some futuristic cloning technology and copy another spaceship and its crew outright. Each of these are valid (though possibly ethically dubious) ways of setting up the initial state of a spaceship, which means we should have a constructor for each:

public class Spaceship {
    private List<String> crew;
    private double fuelLeft;
    private String name;
    
    public Spaceship(String name) {
        this.crew = new ArrayList<String>();
        this.fuelLeft = 0;
        this.name = name;
    }
    
    public Spaceship(Spaceship other) {
        // clone the crew
        this.crew = new ArrayList<String>(other.crew); 
        
        // violate conservation of energy because science
        this.fuelLeft = other.fuelLeft;  
        
        // copyright violation?
        this.name = other.name;
    }
    
    public Spaceship(List<String> crew, int fuelLeft, String name) {
        if (fuelLeft < 0) {
            throw new IllegalArgumentException("Cannot provide negative fuel");
        }
        this.crew = crew;
        this.fuelLeft = fuelLEft;
        this.name = name;
    }
}

However, the problem with doing something like this is that we have a lot of redundancy and duplicate code. We can fix this by using the this keyword like so:

public class Spaceship {
    private List<String> crew;
    private double fuelLeft;
    private String name;
    
    public Spaceship(String name) {
        this(new ArrayList<String<(), 0, name);
    }
    
    public Spaceship(Spaceship other) {
        // clone the crew, violate conservation of energy, violate copyright
        this(new ArrayList<String>(other.crew), other.fuelLeft, other.name);
    }
    
    public Spaceship(List<String> crew, int fuelLeft, String name) {
        if (fuelLeft < 0) {
            throw new IllegalArgumentException("Cannot provide negative fuel");
        }
        this.crew = crew;
        this.fuelLeft = fuelLEft;
        this.name = name;
    }
}

Now, we've isolated all of our initialization and setup logic into a single constructor, almost completely reducing all redundancy in the process.

A common mistake students make is to assume that the objects they're writing will always be called and executed in some specific order. However, that is not the case.

While the test classes we give you will call your methods in a specific order, you should design your classes so that they don't rely on that and could work with any arbitrary client.

So, if you have a class with three methods named methodA, methodB, and methodC, you should be prepared for the client to do something crazy like call methodA 1000 times in a row, or alternate between calling methodB and methodC three hundred times, pause for a minute, repeat, etc...

No matter what the client tries, your code must do something reasonable in response.