|
| 1 | +# Ch 04. Inheritance, Implements |
| 2 | + |
| 3 | +### Hypernyms, Hyponyms, and Interface Inheritance |
| 4 | + |
| 5 | +**Hypernyms:** “<blank> is what’s called a *hypernym* of …” means hypernym is the **********************superclass********************** of (…) |
| 6 | + |
| 7 | +********************Hyponyms:******************** the (…) above are the *hyponyms* of <blank>, or ******************subclass.****************** |
| 8 | + |
| 9 | +As an example from lecture, we created two different data structures `SLList` and `AList`. These are hyponyms of a more general list, we’ll call it `List61B` |
| 10 | + |
| 11 | +using **interfaces**: |
| 12 | + |
| 13 | +```java |
| 14 | +public interface List61B<Item> { |
| 15 | + public void addFirst(Item x); |
| 16 | + public int size(); |
| 17 | + ... |
| 18 | +} |
| 19 | +``` |
| 20 | + |
| 21 | +************************************interface************************************ defines a type for a general list hypernym. It is essentially a contract that specifies what a list must be able to do, *but it doesn’t provide any implementation for those behaviors.* |
| 22 | + |
| 23 | +Now to tell Java that `AList` and `SLList` are hyponyms, we use a relationship-defining word: ******************`**implements**`****************** |
| 24 | + |
| 25 | +```java |
| 26 | +public class AList<Item> implements List61B<Item>{...} |
| 27 | +``` |
| 28 | + |
| 29 | +`implements List61B<Item>` is essentially a promise. `AList` is saying “I promise I will have and define all the attributes and behaviors specified in the `List61B` interface” |
| 30 | + |
| 31 | +### Overriding |
| 32 | + |
| 33 | +When fulfilling the promise in the subclass to implement the methods defined in the interface, it’s useful (and actually required in this class) to include `@Override` tag above the method signature. ***********Note if you don’t include this tag, you’re still overriding the method.*********** |
| 34 | + |
| 35 | +## Implementation Inheritance |
| 36 | + |
| 37 | +Unlike an interface inheritance which just tells the subclass ***what*** to do, we can do something called implementation inheritance which allows to tell the subclasses *********how******* how to behave, |
| 38 | + |
| 39 | +To do this, we must include `default` keyword in the method signature we define in the super class, where if the subclasses don’t override it, it will default to use its parent method. |
| 40 | + |
| 41 | +Now, when we call an overridden method from an instance of the subclass, Java able know which method to call due to something called **************************************************dynamic method selection.************************************************** |
| 42 | + |
| 43 | +## Dynamic method selection |
| 44 | + |
| 45 | +`List61B<String> lst = new SLList<String>();` |
| 46 | + |
| 47 | +in the above declaration, `lst` is of type `List61B` . This is called the “static type”. |
| 48 | + |
| 49 | +However, object themselves have types as well. The object that `lst` points to is of type `SLList` . (**********Note it’s also a `List61B` because of the “is-a” relationship).* But because the object itself was instantiated using the `SLList` constructor, we call this its “dynamic type.” |
| 50 | + |
| 51 | +We say it’s dynamic type because should `lst` be reassigned to point to an object of another type, say `AList` object, `lst` dynamic type would now be `AList` and not `SLList`! it’s dynamic because it changes based on the type of the object it’s currently referring to. |
| 52 | + |
| 53 | +When Java runs a method that is overridden, it searched for the appropriate method signature in its **dynamic type** and runs it. |
| 54 | + |
| 55 | +However for overloaded methods, Java checks to see which method to call by checking the **********************static type********************** and calls the method with the **parameter of the same type.** |
| 56 | + |
| 57 | +## Questions |
| 58 | + |
| 59 | +- [ ] What happens when we pass in a superclass to an argument that’s suppose to take a subclass? |
| 60 | +- [ ] What about when we pass in a subclass into an argument that takes in a parent class? |
| 61 | + - This is fine because when you pass in the subclass to a function, it shares an “************is-a************” relationship with it’s parent class, which means that it should be able to fit into the parents box. |
| 62 | +- [ ] What happens when you use `Parent p = new Child();` |
| 63 | +- [ ] What about when you use `Child c = new Parent();` |
| 64 | +- [ ] Or finally? `Child c = new Child();` |
| 65 | +- [ ] Can you use `implements` on a superclass that’s not an interface? |
0 commit comments