I wasn’t aware my mediocrity was on display. 😅

Honestly, I liked the professor. When he had time to teach something he was clearly interested in, he did a great job of connecting. He didn’t get to teach us OOP though because there was a staffing emergency. The person we did get normally taught Hardware, so he was basically just reading aloud the textbook. Poor guy.

And you’re right, the professor did let us know that there was going to be a change of requirements partway through. But it wouldn’t be a good lesson if he told us what was going to change, although he did give some examples from previous times he’d taught the course.

A lot of people got burned when the change came. For my part I thought I did pretty okay, the refactor didn’t go perfectly but it was better than if I hadn’t been prepared. But I’ve also written a bunch of really gross objects that served no purpose just because they might change later. As anything is, it’s all about finding that happy medium

You’re not wrong but I think when you’re teaching someone just having 1 parent and 1 child class makes for a bad example I generally prefer to use something with a lot of different children.

My go-to is exporters. We have the exporter interface, the generic exporter, the accounting exporter and the payroll exporter, to explain it.

At school, the only time I used inheritance was 1 parent (booking) and 1 child (luxury) this is a terrible example imo.

I mostly come to prefer composition, this approach apparently even has a wiki page. But that’s in part because I use Rust that forbids inheritance, and don’t have such bullshit (from delegation wiki page):

class A {
    void foo() {
        // "this" also known under the names "current", "me" and "self" in other languages
        this.bar();
    }

    void bar() {
        print("a.bar");
    }
}

class B {
    private delegate A a; // delegation link

    public B(A a) {
        this.a = a;
    }

    void foo() {
        a.foo(); // call foo() on the a-instance
    }

    void bar() {
        print("b.bar");
    }
}

a = new A();
b = new B(a); // establish delegation between two objects

Calling b.foo() will result in b.bar being printed, since this refers to the original receiver object, b, within the context of a. The resulting ambiguity of this is referred to as object schizophrenia

Translating the implicit this into an explicit parameter, the call (in B, with a a delegate) a.foo() translates to A.foo(b), using the type of a for method resolution, but the delegating object b for the this argument.

Why would one substitute b as this when called from b.a is beyond me, seriously.

Depends on what was the course about. If it’s about computation, then sure. If it’s about OOP or architecture design (this one I wouldn’t expect, unfortunately, but would be nice if it was taught somewhere), then the point is not just to run something.

Is the class declared static? I assume the “…ic class Answer07” at the top stands for “public class Answer07”.

I don’t think java supports top level static classes (it does have nested static classes, though).