1. CISC124 Assignment 4 on Inheritance due next Friday.
Fall 2018 CISC124
1/11/2019
CISC124
Assignment 4 on Inheritance due next Friday.
Quiz 2 this week in the lab. Topics in Oct. 22 lecture notes. At least 78 people left to write on Friday. The lab holds 60 maximum…
Fall 2018
CISC124 - Prof. McLeod
Prof. Alan McLeod

2. Today Example: Polymorphism Using an Interface.
Modules – first used in Java 9.
Start Inheritance.
Fall 2018
CISC124 - Prof. McLeod

3. Questions from Last Time…
Let’s first create a bunch of classes that implement the DoRunRun interface.
Create a collection of instances of these classes.
Feed the collection to two methods:
One that accepts a DoRunRun[] array, and
One that accepts an Object[] array.
What’s the difference in how the two methods operate?
Fall 2018
CISC124 - Prof. McLeod

4. Noteable: See how DoRunRun can be used as a type.
The DoRunRun[] array type can hold instances of any class that implements DoRunRun.
The Object[] array type can hold any Object…
If the method accepts DoRunRun[], then each element can be of the type DoRunRun, and we know that each element will have a concrete version of the run() method.
Fall 2018
CISC124 - Prof. McLeod

5. Noteable, Cont.:
As you iterate through the collection, the variable “one” morphs into its actual object at run-time, so you know the correct run() method will be invoked.
If the argument to the method is of type Object[], the elements in the collection are also of type Object.
An Object does not have a run() method. Early binding will fail if you try to invoke run() from a variable of type Object.
Fall 2018
CISC124 - Prof. McLeod

6. Noteable, Cont.:
So, first you have to cast the variable to a type that does have a run() method.
What happens if the Object[] array has something in it that does not implement DoRunRun?
Which method version is more prone to failure?
We will see (soon!) that the mechanism for Polymorphism can be achieved through inheritance as well, not just through implementation.
Fall 2018
CISC124 - Prof. McLeod

7. Java Modules
This new system of organizing large numbers of Java source code files was introduced in Java 9.
Modules are a way to organize many packages into a single module. But there is a little more to it than just grouping packages and files together.
Each module must have a module-info.java file:
Fall 2018
CISC124 - Prof. McLeod

8. module-info.java
The module can be built with a large set of packages in a folder structure. The module-info file goes in the root folder of this structure.
This file contains information about the name of the module, the packages that are available, and the packages that are required.
Basically, the info file supplies all the needed information about how the module interacts with other modules.
Fall 2018
CISC124 - Prof. McLeod

9. module-info.java, Cont. The format of the file is:
module module_name {
requires module_name; …
exports package_name; }
You can have as many requires and exports lines as needed (and some others).
Fall 2018
CISC124 - Prof. McLeod

10. module-info.java, Cont.
requires identifies modules on which this module depends.
exports identifies packages in the current module that are available to other modules. This provides encapsulation at the package level!
uses identifies specific interfaces and abstract classes or “services” that are used by this module.
Fall 2018
CISC124 - Prof. McLeod

11. open, opens, provides, with, to, transitive
module-info.java, Cont.
Other keywords that can be used in the info file:
open, opens, provides, with, to, transitive
See help docs such as the API docs for the java.lang.module package. Or:
Fall 2018
CISC124 - Prof. McLeod

12. Java Modules, Cont.
You can also restrict what other modules can see using Reflection. (More on reflection later…)
Dependencies can be specified for use at compilation or at run time or both.
Encapsulation is a big advantage.
The specification of dependencies reduces the run time size of the program and will speed up execution as a result.
A module name must be unique.
Fall 2018
CISC124 - Prof. McLeod

13. Java Modules, Cont.
In this course we won’t need to create modules for our little projects…
The Java platform itself is now organized into at least 95 modules.
Each module can contain many packages.
A lot of the stuff we have been using is in the java.base module.
Fall 2018
CISC124 - Prof. McLeod

14. Java Libraries
A library is distributed and used from a *.jar file (“Java Archive”) on the classpath.
It is a compressed file containing only *.class bytecode files organized into the package folder structure specified by the packages.
Now, *.jar files also contain the required module-info.class files called “module descriptors”.
The *.jar file does not contain any *.java files – these will be in a file called “src.zip” that only comes with the JDK:
Fall 2018
CISC124 - Prof. McLeod

15. Aside – Viewing Java API Source Code
Open up the library link.
Most of what we are interested in, for now, will be in the java.base module.
When you locate the class or interface of interest and are doing this for the first time, you will see:
Fall 2018
CISC124 - Prof. McLeod

16. Aside – Viewing Java API Source Code, Cont.
Click on “Attach Source…” Choose “External location”, and click on “External File”.
Fill out the dialog by providing the location of the src.zip file for the JDK you are using:
Fall 2018
CISC124 - Prof. McLeod

17. Aside – Viewing Java API Source Code, Cont.
Let’s look something up!
Fall 2018
CISC124 - Prof. McLeod

18. Hierarchy Example from the Java API
Fall 2018 CISC124
Hierarchy Example from the Java API
A quick look at part of an existing hierarchy – the Collection<T> hierarchy – it won’t hurt and it shows the use of Interfaces and Abstract classes:
Fall 2018
CISC124 - Prof. McLeod
Prof. Alan McLeod

19. Interface Implement Abstract Class Extend Concrete Class
Collection<T>
Abstract Class
Extend
Concrete Class
Set<T>
List<T>
Queue<T>
AbstractCollection<T>
SortedSet<T>
AbstractQueue<T>
AbstractSet<T>
AbstractList<T>
PriorityQueue<T>
EnumSet<T>
TreeSet<T>
AbstractSequentialList<T>
ArrayList<T>
HashSet<T>
Vector<T>
LinkedList<T>
LinkedHashSet<T>
Fall 2018
CISC124 - Prof. McLeod
Stack<T>

20. Fall 2018 CISC124
Inheritance
An OOP design technique that allows you to add to, modify, replace or simply adopt the methods and attributes in an existing class.
The class that you are modifying is called the parent or super class, and the resulting class is called the child or sub class.
The child or sub-class inherits all the public attributes and methods of the parent or superclass.
The child class extends the parent class.
The sub-class is always more concrete or less abstract than the super class.
Fall 2018
CISC124 - Prof. McLeod
Prof. Alan McLeod

21. Why Bother? One reason is code re-use.
It is also a design tool that allows the coder to more easily model a real-life structure.
You can also use inheritance to enforce code structure on child objects (using interfaces and abstract classes).
And it is part of the polymorphism mechanism.
Many classes in the Java API are intended for use as parent classes.
Fall 2018
CISC124 - Prof. McLeod

22. Real Life Hierarchies Can you think of any? Flora, Fauna
Rocks & Minerals
Food Menus
Fasteners
Vehicles
Computers
etc!
Fall 2018
CISC124 - Prof. McLeod

23. https://en.wikipedia.org/wiki/List_of_popular_music_genres
Music Hierarchy
For example, see:
Almost everything must belong to a hierarchy.
We often need to model real-world hierarchies in code. Easier to do because we already have the model.
Fall 2018
CISC124 - Prof. McLeod

24. Example Our classroom: Person Professor Student
Both Professor and Student are sub-classes (or children) of the super-class or (parent) Person.
Fall 2018
CISC124 - Prof. McLeod

25. Example, Cont. Person Professor Student Note that:
Professor “is a” Person.
Student “is a” Person.
Professor “is not a” Student.
Student “is not a” Professor.
Fall 2018
CISC124 - Prof. McLeod

26. Example, Cont.
Child Objects always have an “is a” relationship with the Parent Object.
In the Person class you would code all the attributes (age, gender, hair colour, etc.) that describe a person.
The sub-classes only need to hold those attributes that are specific to them (such as numExamsToCreate in the Professor Object and numExamsToWrite in the Student Object.)
The sub-classes do not have to repeat any of the code in the super-class.
Fall 2018
CISC124 - Prof. McLeod

27. Some Goals of Hierarchy Design
All attributes in an instance (its “state”) should be defined with meaningful values.
Minimize code repetition.
The same attribute should not be declared in more than one class.
A child class should be more concrete than its parent class.
Design for polymorphism:
Use abstraction (abstract classes and interfaces) to ensure common behaviour and to allow for polymorphism.
Fall 2018
CISC124 - Prof. McLeod

28. Some Goals of Hierarchy Design, Cont.
Control and minimize the public interface of all classes.
Try not to have any “pass through” classes that do not contribute anything.
Make sure the structure is extensible.
Use a consistent variable and method naming scheme throughout the hierarchy.
Follow the “real world” hierarchy as closely as possible.
Fall 2018
CISC124 - Prof. McLeod

29. Back to the Example
In Java, every new object you define is automatically a child of the Object class.
So our actual structure is:
Object
Person
Professor
Student
Fall 2018
CISC124 - Prof. McLeod

30. Example, Cont.
This is a simplified UML Class Diagram. The upward pointing arrow shows the “is a” relationship.
So:
Person is a Object
Professor is a Person
Student is a Person
Professor is a Object
Student is a Object
Fall 2018
CISC124 - Prof. McLeod

31. Aside - the Object Class
Object is the “Universal” parent class for every object in Java – in your code, in the API, everything!
So, we are inheriting all the public members of this class – whether we want this stuff or not.
What members are we getting and how do we find out?
Fall 2018
CISC124 - Prof. McLeod