Read: 06 - Inheritance and Interfaces
Review of Objects and Classes
Objects is the idea behind OOP (object-oriented programming), that all things are modeled like real world objects - “things” that have properties and do things. And all objects live within classes, that can be extended, instantiated, and customized accordingly as the programmer builds out (or in).
Inheritance
Objects created directly from a Class are of that class. But, you want to make a new class that is similar, and shares many of the same states and functions, you can
class NEW CLASS extends SUPER CLASS now the NEW CLASS takes on all variables of the SUPER CLASS. But, you need to be careful: all those properties from the superclass are not written into the subclass, so documentation that follows the new class and outlines what it inherited from the superclass is readily available. Above quote from here
Interface
An interface is a group of related methods with empty bodies.
These interfaces then become the means with which to manipulate and edit objects of that specific class, and inform the outside context what “is” the class and it’s objects. They contain only constants, method signatures (?), defaults (ie default methods), static methods, and nested types. They are not instantiated, only ever implemented by classes or further extended by other interfaces.
These interfaces can then be used to “power” many different classes and objects by implementing them. Interfaces can be used as APIs (Application Programming Interfaces) also. Unlike in packages below, this use - even it’s definition, and the fact that the word interface is in the acronym - makes since: you input values, the interface takes those values, sends it to/through the class, and outputs it. That checks out.
Interfaces are created by declating them as such (likely declared as public, unless it is to be used only within packages as included), then with any of it’s internal variables (as noted above). Of note, default methods are defined with the default modifier, and unless otherwise stated, all methods within an interface are public, so the public modifier can be omitted, as it’s inclusion is implied.
The Oracle docs on “implementing an interface” dive into the nuts and bolts of how to use an interface, and I do not see how it is different, or how the interface interacts with other classes. Taking in an object named as the interface is key here, and then “casting” it to that type so as to match other items as a 1:1 ration, but the exact why the data would need to be formed like such eludes me yet. In the example, the need to cast a number to another number seems redundant, but no doubt I’m missing something. It might have to do with the benefit of using an interface as to allowing multiple otherwise different classes, to interact in safe, measured ways.
Evolving interfaces is interesting in how it manages changes to an interface, where a 2.0 version of an API is “merely” version 1.0 then extended by another interface. This is definitely the most meaningful way I’ve seen extends used.
How a default is used, I can’t parse the code in the example, or what default accomplishes, if it forces specific methods to be used, or if it sets certain variables to defaults. Best I can tell, default methods allow a programmer to sidestep issues that might arise in the future when modifying code. But otherwise their example goes - at this point - waaaay into the weeds, and brings in many different tools of Java that weren’t explained anywhere. (If documentation is to explain a single concept, then this page at Oracle’s website gets a fail grade.)
Package
A package is a namespace that organizes a set of related classes and interfaces.
Basically, a way to organize your codebase. Application Programming Interface (API) is also mentioned here, and I’m not certain how a package is equivalent to an API yet exactly. I see “package” just that - a way to bundle code together so that everything can be properly bundled to insure that it properly functions.
======
Inheritance
Classes can be created and inherit the fields and methods from another class by the inherit modifier. From there, subclasses can add their unique variables, and if it is in the same package, inherits anything package-private as well. Also, subclasses (or, children) has access to all private members of its enclosing class, so children have access to the parent’s private classes (which seems like that could be an issue). There’s also mention of casting a class as an Object but… aren’t all things Java objects already?
One thing that Java does not allow is multiple inheritance from multiple classes, so that such isses of same name methods (from different superclasses) and other ambiquities don’t arise, but it does allow multiple inheritance of type - the ability to impliment more than one interface - which does allow similar issues.
Overriding and hiding methods allow subclasses to properly modify them to best fit their (the subclass’s) intended state.
Polymorphism - allows for subclasses to have unique behaviors, but share some same functionality of the parent class. But if/when you rename a subclass’ field as the same name as the super class, you can still access the super class’ field by using the super keyword. OR if you want something to be certain it is never hidden or overridden you can use the final keyword in the method declaration, at which point no subclass can modify it and must impliment it as such.
Abstract classes are only ever super classes, cannot be instantiated (as they have no implementation), but can be subclasses, and there are benefits and issues to consider using an abstract class instead of an interface (and those differences are considered in the linked documentation).