Programming for Geographical Information Analysis: Core Skills

Programming for Geographical Information Analysis:Core Skills Lecture 5: Working with others’ code I: Inheritance

Review Classes are photocopy originals for objects. Usually we make an object from a class. The object contains all the code in the class. We can therefore call methods inside the object. pointObject.setX(200.0); We pass a method certain ‘arguments’. Can use object’s variables directly but isn’t usual. pointObject.x = 200.0;

This lecture Inheritance Extension Interfaces UML

Philosophy of Object Orientation Encapsulation. Data and the methods working on them are contained. You don’t need to know how something is done, just what does it. Indeed, you shouldn’t be able to find out. Java: private/public, static, final, class, methods. Polymorphism. One idea should be presented in a flexible form. Java: polymorphic methods. Inheritance. Classes should be able to inherit code from other classes and add their personal twist to it.

Inheritance Say you go to the ATM of BlueBank Inc. It collects a PIN in an object. But... you belong to RedBank Plc., which has its own software. How does BlueBank send RedBank your details to confirm? The object BlueBank has wasn’t written by programmers at RedBank, so it is bound to be different from what they want. BlueBank could have a class for every bank it deals with, but that would be complicated.

Instead, all the banks design a class description that has the information they need. All banks promise the objects they send will match this class description as a minimum. The objects can have other stuff as well, but they must match the description at the least.

Inheritance BlueBankRequest GenericRequest Methods demanded: getPin() Methods: getPin() setPin() Is a subtype of There’s nothing to stop RedBank developing its own version with other methods along with getPin().

Methods A method can take a subclass object where it expects the superclass. However, the method can then only use the superclass methods, and none of the subclass detail.

BlueBankRequest b1 = new BlueBankRequest(); b1.setPin (getAtmPin()); boolean pinOk = redBankConnection.isPinOk(b1); Because the isPinOk method takes in a GenericRequest and checks the things sent against that, it can guarantee that the getPin method will be there. As long as it just uses that, it will be fine. It doesn’t need to know the object is more complicated. booleanisPinOk (GenericRequestqr) { if (qr.getPin() == customerPin){ return true; } else { return false; } }

Inheritance The getPin code in GenericRequest could be: 1) full code that does the whole promised job; 2) empty, with classes just promising the method will be there; 3) something inbetween, with some methods full code, some just promises. Java builds these in through: extension : whole code available + what you write interfaces : just a set of promises + you write everything abstract classes : mix of code and promises

Extension Classes can be extended: public class GenericRequest{ protected int pin; public int getPin() { return pin; } }

Inheritance: extends Inheriting classes have all the public or protected variables and methods of the inherited class. class BlueBankRequestextendsGenericRequest{ void setPin(intpinIn) { pin = pinIn; } } Only need to define new variables and methods. The pin variable and getPin are inherited from GenericRequest. The parent class is called the Superclass, the inheritor is called the Subclass.

Inheritance: super Subclasses can’t access the private variables of Superclasses. Therefore, one way to set these is to use the Superclass’s constructor. class BlueBankRequestextends GenericRequest{ public BlueBankRequest() { super("Cheshire Cat Banking plc."); } } The call to super must be the first thing in the Subclasses constructor.

Inheritance: overriding What happens if you call a method in the Subclass the same thing as a method in the Superclass? If they have different arguments it doesn’t matter – the JVM will call the one that works with them. If the arguments are the same the Subclass will be used. The method is ‘overridden’. We can also use super. to refer to the Superclass methods and variables in the same way as we use this. to refer to the present class. If we declare the Superclass methods as final they can’t be overridden by the Subclass. final Classes can’t be inherited.

Abstract Classes Classes that can only be inherited – can’t make objects from them. Include some methods and variables. Any Class that extends it must provide all the missing methods, or be declared abstract itself.

abstract class GenericRequest{ int pin = 0; int account = 0; void setAccNumber(intaccountIn) { account = accountIn; } abstract intgetPin () ; } class BlueBankRequestextends GenericRequest{ intgetPin () { return pin; } } BlueBankRequestobjects have the setAccNumbermethod without defining it, but they must define getPinbecause all GenericRequestinheritors must have it.

Issues Note: • You don’t actually have to have any content in the methods to get the compiler to see you’ve met your promises with abstract classes. • You can only extend one class or abstract class at a time. You can’t, for example subclass both a menu item and a scrollbar – what would it look like?

Hierarchies Finally, with inheritance, we can build up flexible modelling and data-holding structures, where elements of behaviour can be replaced, and classes used to build up multiple subclasses. We see this, for example in ArcGIS Geodatabases: route66 instantiates Freeway which inherits Road which inherits Line. …each has additional variables suitable for holding, e.g. road speed limits. But also in models: dale instantiates Human which inherits Primate which inherits Mammal with inherits Animal which inherits Agent. …each has additional and overriding behaviours.

Review If you have a class you’d like to pick up the methods from, just extend it: class BlueBankRequest extends GenericRequest{ From then on, you get all the class’ code for free! If the class is abstract, the compiler will force you to put in the abstract methods.

Interfaces Interfaces are the ultimate abstract class. They are lists of methods that must be defined in classes that implement them. All variables in them are final. Why the devil would you want to do that…? You can make classes that rely on finding certain methods wherever they are used. By forcing people to implement these methods you can guarantee they exist.

BlueBankRequest b1 = new BlueBankRequest(); b1.setPin (getAtmPin()); boolean pinOk = redBankConnection.isPinOk(b1); booleanpinOk (GenericRequestqr) { if (qr.getPin() == customerPin) return true; else return false; }

interfaces public interfaceGenericRequest { public intgetPin (); } public class BlueBankRequestimplementsGenericRequest { private int pin = 0; public void setPin (int p) { pin = p; } publicintgetPin () { return pin; } }

BlueBankRequest b1 = new BlueBankRequest(); b1.setPin (getAtmPin()); boolean pinOk = redBankConnection.isPinOk(b1); booleanisPinOk (GenericRequestqr) { if (qr.getPin() == customerPin) return true; else return false; }

interface variables Interfaces classically also contain final static variables of use with the interface: public interfaceGenericRequest { publicfinal static String STANDARDS_AGENCY = “Bank Standards Inc.”; public intgetPin (); } BlueBankRequest b1 = new BlueBankRequest(); b1.setPin (1234); boolean ok = redBankConnection.isPinOk(b1); System.out.printToATM(“Your connection is brought to you by ” + GenericRequest.STANDARDS_AGENCY);

Importance Interfaces are the key link between any two pieces of code that need to talk to each other where there might need to be a wide variety of implementations of a standard. This includes: • Commercial systems. • Operating systems. • The interaction between the user interface and a program. • Interaction between components of a program you want to be swappable later.

Inheritance We can extend a Class to give us all its functionality. class A extends B { We can implement an Interface, which means we promise to supply its methods. class A implements C { We can only extend one Class, but we can implement many Interfaces using commas. class A extends B implements C, D, E {

UML The Unified Modelling Language. A way of drawing code overviews so that it’s understood by any programmer. Usually part of a software development ‘process’. UML is an overview. Once developers have seen your UML, they’ll look at your documentation (next lecture) for more information. Can be converted into raw code using some Computer Aided Software Engineering (CASE) tools.

Why have an overview standard? In industry code tends to be part of much larger projects with multiple programmers working on it. Therefore we need standard overviews so that… We can see whether an application can be made and how many people we’ll need to work before we start coding. We can see where our code fits in when we start. We can see how to use other people’s objects. If you spontaneously combust, others can pick up your work easily.

Parts of UML There are several types of model in the UML. Which one you use, and how you look at it, will depend on what you’re trying to do. The secret is to use what’s useful. Types of diagram… Use Cases (What are the uses someone [or thing] may want from our software). Class Diagrams (What are the different relationships between Classes). Sequence Diagrams (What order does stuff happen in). State/Activity Diagrams (What are Classes like over time).

The Class Diagram -/+/# = private/public/protected Solid arrow is inheritance from a class/abstract class. Interfaces have dashed arrows and are written: <<Point>> Abstract classes are either light font or, more usually, italics. Variables at top, methods at bottom.

Activity Diagram Replacement for older flowcharts. Beginning and end marked by circles (end by a double circle). Diamonds for decisions. Parallel code marked by bars.

Next lecture Using other’s code II: Problems and Packages More methods Check out practice pieces on inheritance Check out UML resources Practical

Programming for Geographical Information Analysis: Core Skills