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

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

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

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

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

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

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

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

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

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

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: https://www.oracle.com/corporate/features/understanding-java-9-modules.html Fall 2018 CISC124 - Prof. McLeod

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

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

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

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

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

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

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

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>

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

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

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

https://en.wikipedia.org/wiki/List_of_popular_music_genres Music Hierarchy For example, see: https://en.wikipedia.org/wiki/List_of_popular_music_genres 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

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

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

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

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

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

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

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

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