Extends OldKnowledge;

As it turns out, there is a flip side to feeling smart by virtue of ‘relearning’ things you’ve learned long ago. And that is the wonder that comes from pondering the question of, ‘Was I just very, very stupid back then?’ (No answer necessary. :P)

I was forced to consider the question as I went through the section on inheritance and interfaces. Concepts that, right now, seem incredibly basic but were two concepts I essentially ignored in my first year of Uni. Threw them into the ‘too hard and not needed’ bucket quicksmart. The coursework we were given never required their usage, even when it came to the year 1 magnum opus, the final assignment — every young developer’s dream: Make. A. Game.

I did a rather basic Tower Defense game, which I probably spent at least as much time on the art for, as I did the actual code. I no longer have that code, but I do distinctly remember making some rather… interesting… shall we say, decisions around the structure of the project.

I created classes for Towers, Bullets and the Enemies; and had a supporting GameMath static class which I called to perform calculations such as moving bullets along the path of two points. I believe my thinking was that this GameMath class might be something I would reuse for other projects which is probably fair enough. It was the rest of my implementation which was questionable.

The short version is that the Main Class owned everything. It did way more of the program’s lifting than it should have. So I had odd constructs like the array of bullets for each tower being moved across the screen space by Main. Things that, even at the time, struck me as unnatural.

This is not to say that inheritance or interfaces were necessarily the answer here. The problems I’m describing are much more fundamental to a misapplication of Object Orientated Programming principles than that — but if I had spent the required time and effort to understand these principles then, I would’ve done things quite differently.

Circling back to the opening question (turns out I’m going to give it an answer after all) — unfortunately… the answer is ‘Yes’. Yes, I was very, very stupid back then. Although perhaps not in the way you might expect. It was less about ability or inability to understand and more the fact I made some rather foolish decisions about where to focus my attention. That linked post talks mostly to the extreme issues of year 2, but… Honestly? Even by the end of Year 1, I was starting to make less than wise decisions.

After how well I did in CompSci 101; I started paying less attention to lectures. Because… ‘I didn’t need to’. As I recall, World of Goo featured heavily in my lectures as something that would run well on my laptop. A laptop I bought specifically with low specs to prevent myself from gaming on, I might add. D’oh.

Who knows how long my current focus on relearning all this will last. Certainly for the time being it is eliminating time to play games, which makes it somewhat difficult to write about them!

For any future me, that might’ve put this aside again and is restarting the process, here are the basics!

Inheritance, Interfaces and Inner Classes

Inheritance (IS-A relationship)

Unlike the more common Composition (HAS-A relationship), Inheritance describes the IS-A. A Car is a Vehicle. A Tesla is a Car. Or, for some reason, animals are very common in explaining the ‘is-a’ or inheritance linkage, so a Horse is an Animal.

The linkage is easy enough to think about, the main thing I missed early on in my formal education on inheritance?

I missed when defining such a relationship would be practically useful.

And the reason I missed that, I think, was not understanding the use of the super keyword in the context of extending the function of methods defined in the parent class, including chaining class constructors up the chain, requiring you only to write the code to define new class member variables.

As a simple example of this, here’s a chain of toString methods from the Vehicle -> Car -> Tesla example I first noted:

// From the Vehicle class (Override directive is applying to the Java default Object class)
    @Override
    public String toString() {
        return "This Vehicle is manufactured by " + manufacturer + " and is a " + modelName
                + ". It has a max speed of " + maxSpeed + "km/h, and a current speed of "
                + currSpeed + "km/h.\n";
    }

// From the Car class - extends Vehicle
    @Override
    public String toString() {
        return super.toString() + "This car uses the " + gearType + " gear type, and has " 
               + gears + " gears.\n";
    }

// From the Tesla class - extends Car
    @Override
    public String toString() {
        return super.toString() + "The current battery level is: " + batteryPercent + "\n";
    }

Interfaces (Forming a Contract)

It took a group project where we didn’t use or agree on interfaces upfront to really make me appreciate their value. But even when we did then utilise interfaces, it was in a very rudimentary way.

We did so as an additional form of documentation, really. As a means of agreeing our method naming nomenclature. Note: We didn’t have the same degree of IntelliSense/autocomplete available to us then as we do now.

Using interfaces still requires some discipline — if you’re going to change the interface around willy-nilly, it isn’t going to do you any better than just not having one in the first place if your intent is to make your classes usable by anyone other than yourself.

Although another benefit I’m relearning at the moment — not limited to just Interfaces though, any parent-child relationship, including inheritance can do this — is the ability to create methods that explicitly expect the parent class but will accept any of the children class, too.

Inner Classes (Hide the Detail)

Inner Classes are something I do legitimately, even now, think have somewhat limited utility.

The use case is where the wrapping class is the only class you ever expect to have any real knowledge of the workings of the inner, or nested class.

The example the Java course I’m doing used is the construction of a Gearbox class, which held a Gear inner class. The Gearbox then had an ArrayList of Gears as a member variable.

The Gears themselves were of no interest to anything outside of the GearBox, now, or ever — so the construct worked.

Next Up

The remainder of Section 9 focuses on Abstract Classes and Methods.

Following that, Section 10 focuses entirely on Generics.

More generally though — I am, at last, almost finished reading The Core, the final entry in Peter V. Brett’s Demon War Saga. After which, I can do a review of that whole series.

I’m also wanting to find a new balance between this burst of learning and gaming. Mostly for the benefit of here, so I have more to write about — but I do also have Riftbreaker sitting on the sidelines waiting for more attention, too!