11. Abstract Classes and Interfaces

Transcription

1 11. Abstract Classes and Interfaces THIS SECTION IS OPTIONAL FOR CMPT 101, and you will find it was written for a different course. It refers to previous exercises that are not part of Cmpt 101. Sometimes in software development, we see or create base classes that should never be instantiated. They are present only for the purpose of localizing into one easily-maintained section of code the common attributes and functions for an whole inheritance family. This prevents them needing to be duplicated in all the subclasses. However, as a result the base class may seem somewhat artificial. There is a way in many object-oriented languages to label these so they cannot be instantiated by mistake, and so every application programmer recognizes them for what they are. They are called abstract classes or abstract base classes. Java has another feature called interfaces that are similar to abstract classes that have no attributes and not even one function body. Both abstract classes, or Java s novel interface feature, often form a base for polymorphic sections of code in Java. This is why they are both treated in this one section. C++ has multiple inheritance of class implementations, and interesting and powerful feature. However, multiple inheritance can be troublesome to program, and difficult to compile. Java interfaces and its single root Object class, can in most cases eliminate the need for multiple inheritance. Copyright Russell Tront, Page 11-1 Section Table of Contents 11. ABSTRACT CLASSES AND INTERFACES ABSTRACT CLASSES An Abstract Class Programming Example EXERCISE A INTERFACES Declaring An Interface Using an Interface and Interface Polymorphism Implementing an Interface EXERCISE B MULTIPLE INTERFACES INTERFACE CONSTANTS AND OTHER WEIRD THINGS25 Copyright Russell Tront, Page 11-2

2 11.1 Abstract Classes Sometimes we program a bunch of classes that seem to have a lot in common. So we extract that commonality and put it in a base class, from which we then extend our other classes. This is called generalization. Often generalization takes place in a more planned manner. Good OO architects will recognize commonality, even before any classes are written. Using UML class inheritance diagrams they communicate this structure to their colleagues. Sometimes though, the base class is so artificial that it will never be actually instantiated. Here is an example with which you are probably familiar. Parent/Super/ Base Class Child/Sub/ /Derived Classes Conventional desiredtemp selfcleaningnow Ovens currenttemp start( ) is-a Microwave powerlevel Generalization Specialization Barbeque valveposition settemp( ) startselfclean() setpower( ) setvalve( ) We never want to instantiate Oven object software, because there is no way to set the temperature or power of an Oven. Another example might be a base class called Aircraft in the federal government transport licensing system. There is no such thing as a generic Aircraft, only concrete classes like Airplane, Helicopter, Balloon, Hovercraft, etc. Nonetheless, all Aircraft have a license number, an owner, an address, a phone number, a date of production, etc. And functions related to these attributes. Copyright Russell Tront, Page 11-3 Copyright Russell Tront, Page 11-4

3 Such a base class is present only to provide a base of common attributes and code from which other properly useful classes will be derived. Such base classes are called abstract classes by Java programmers. The derived classes are called concrete classes (as long as they, in turn, do not also happen to be abstract). When thinking about abstract classes, note the distinctions between the abstract base class designer, concrete subclass programmers, and in addition, application programmers who may use the concrete subclasses! Each has a different role with different goals An Abstract Class Programming Example Let us consider generalizing our previous graphical object inheritance tree even higher, so that Point inherits from an abstract base class called Location. Suppose we make the abstract Location class have x and y coordinates, and no color attribute (because conceptionally, a location does not have a color). In addition, you cannot display a location. abstract class Location { protected float x_coord; protected float y_coord; public void move(float x, float y){ x_coord = x; y_coord = y; public abstract void display(); We can then derive Point from this Location class: class Point extends Location{ protected Color color; public void setcolor(color color){ this.color = color; public void display() { drawpoint(x_coord, y_coord, color); Copyright Russell Tront, Page 11-5 Copyright Russell Tront, Page 11-6

4 Notice that Point can add an attribute, add a member function, possibly override member functions, and especially notice that it adds a body to the previously abstract function display( ). Now we can also derive other things like rectangles, windows, buttons, and all sorts of other things from the abstract Location class, thus taking advantage of the already written Location code. Also, modifications to the move( ) function only need to be done in one class. These advantages are of course more useful if the code in Location contained hundreds of lines of functionality that is inherited by a number of concrete subclasses. The nature of a Location is such that you can t really display it. It is not a visible point; it is an abstract concept. (Not all abstract classes are abstract concepts; for example, the concept of an Aircraft is pretty concrete, though a bit too general for instantiation.) Usually there is something so general or abstract about an abstract class, that the author of the abstract base class cannot provide an implementation body for some function, even though she knows that every subclass will require such a function. She likely even knows what the name and parameter list should be for that function. This is often the case because that function will be used polymorphically. The code that uses the inheritance tree of classes may have already been written! So, the purpose of an abstract function is pretty well known ahead of time, but each subclass will likely have to implement it differently. Abstract functions allow the base class programmer to declare a base set of functions for a whole family of classes, without defining that family or the bodies of those functions. Every member of that family will inherit this function set. Moreover, to be instantiated, every subclass author MUST implement this function set appropriately for its type. Abstract functions thus allow the base class author to force subclass authors to program particular functions, even if the base class programmer does not know what the appropriate bodies for each subclass would be. Such functions are written in the abstract base class with no body (not even empty braces, nor C++ s =0 notation). As shown above, all that is needed is a semi-colon after the function signature. Java requires that you label member functions with no bodies abstract. Note that it is possible to have an abstract class with no abstract functions. This indicates to subclass programmers that they need to ADD some unnamed function (not just function body) to the abstract class when deriving from it. Abstract classes without an abstract function are rare. And they should be well commented as to what needs to be added. Also, note that if you have an abstract class with no function bodies (i.e. all functions are abstract), it might be more appropriate to use a Java interface instead of an abstract class. This is especially true if there are also no instance attributes in the class. We will discuss Java interfaces shortly. Copyright Russell Tront, Page 11-7 Copyright Russell Tront, Page 11-8

5 11.2 Exercise A Take the OvenC class developed as an exercise in a previous section of this course, and make the print( ) function abstract. Call the new class OvenCA. Don t forget to rename the constructors and all other references to the old OvenC. Note that in UML, abstract method names are italicized, as are names of the abstract classes that contain them. OvenCA temperature pressure percentoxygen setoven( ) print( ) static printoven( ) static main( ) function does not call the OvenCA print( ) function, because OvenCA s print( ) function is abstract and has no body! Have the OvenSA main function instantiate and print a couple of instances of OvenSA. Test run OvenSA.main( ). Next, try modifying the OvenSA main so that it uses the setoven( ) function from OvenCA. Run the program again to prove that you can inherit functional code from the nonabstract functions of an abstract parent class. Also note that you are inheriting useful attribute fields from the parent abstract class. Finally, in OvenSA s main function, try instantiating an instance of OvenCA. Will this compile? Will this run? OvenSA percenthumidity print( ) static main( ) Convert the OvenS subclass developed as an exercise in a previous section of this course, and make it derive from the OvenCA rather than OvenC class. As shown above, call this new Class OvenSA. Make sure that OvenSA s print( ) Copyright Russell Tront, Page 11-9 Copyright Russell Tront, Page 11-10

6 11.3 Interfaces Interfaces are a great new concept that is elegantly used in several parts of Java. An interface is a specification of the function signatures that one or several classes must implement. Writing an interface is like writing a standard for the function signatures that a class or group of classes, whether related by inheritance or not, must provide. As such, it allows a kind of polymorphism not possible in C++. Interfaces, in essence, specify the formats of the function call messages that you can send to an object that complies with that interface s standard. Recall that, in an earlier part of the course, it was suggested that the Smalltalk programming language uses the terminology of sending a message containing a function name and parameter values to an object instance. The method of that object that matches the message will as a result be executed. Well, a message to invoke a particular function must have a particular format containing a function name and a list of parameter types unique to that function. Interestingly, instances of several different classes, even if not related by inheritance, could potentially have a similarly named function invoked by such a message. This is because the message contains exactly the information needed (function name and compliant sequence of argument parameters) for invocation of the function. Specifying a function in an interface is essentially similar to specifying an abstract member function (i.e. no function body). But unlike an abstract class, no attributes are allows in an interface, and NONE of the functions can have a body. Copyright Russell Tront, Page So, an interface is just a list of function signatures. (Later we will see that an interface can also contain static final constants). Interfaces are used by the Java GUI libraries for specifying the standard that an object you write must comply with in order to be called back, say, regarding mouse Button clicks. This allows Sun to write Button class functions which accept registrations of objects for call backs, even though these library functions do not know the name of the class that you are writing to be the target of the call back. Sun documents the standard for objects that need to receive Button callbacks in an interface called ActionListener. Such interfaces are widely used in the Java Abstract Windowing Toolkit (AWT), Swing GUI components, and any other classes needing function call standards. In addition, when using so-called remote objects on another machine, you cannot directly access public attributes of that remote object. You can only call general functions, and get and set functions that affect the remote attributes, using Remote Method Invocation (RMI). As such, all a local client program needs to know about a remote client is the function names and parameters that it can accept. Of course, this is exactly what interfaces are good at specifying. Other important languages and technologies have the concept of interfaces. Microsoft s ActiveX and DCOM technology heavily uses the concept of interfaces written in a special language called MIDL (Microsoft Interface Definition Language). Most interface names from Microsoft begin with an upper case I, which is not a bad way to Copyright Russell Tront, Page 11-12

7 distinguish them from class names. In addition, the very important CORBA remote object technology heavily relies on interfaces written in plain IDL. One of the reasons for interfaces is to allow the compiler to check your calling code uses the correct function name and parameter list. As such, an interface provides an advertisement that allows the calling code to be checked against during compilation. Of course, classes that purport to comply with this standard must declare so, and when they are compiled, the compiler ensures that the programmer of the implementing class actually does provide complete functions complying with the advertisement. As such, then, interfaces form a agreement between implementing classes and using classes. This agreement is only loosely tied to each class. This provides another aspect of the safety, yet flexibility, of Java s strong type checking. Copyright Russell Tront, Page Declaring An Interface Here is an example of the declaration of an interface: public interface DownCounter { void setcount(int newvalue); int decrement(); This interface abstractly defines how you would call to preset a counter, and then decrement it (which returns the resultant decremented value). Or, it could be used to set and decrement the altitude of an airplane in a video game. Java programmers use interfaces as a very simple way of specifying the functions that a class must implement without defining the server class. As such, it forms a kind of function services contract, like a legal contract written between two generic kinds of people. An interface is thus somewhat like a very abstract class, except that a class that purports to implements an interface does not need to inherit from it. Here are a few other differences between an abstract class, and an interface:. An interface cannot have member attributes, except public static constants. An interface therefore generally only advertises function signatures for use by other programmers. These programmers might implement classes that comply with the interface, or they might Copyright Russell Tront, Page 11-14

8 write application programs that use references that point to objects of unspecified classes that implement that interface. The method bodies of EVERY method must be absent. There should not even be empty braces{ for the body. All members of an interface are by default public, so you do not have to label them public. All constants are by default public static final, and do not need to be so labeled. Only the interface itself needs to be labeled public, private, or not at all (package access). Sun Microsystems states that interfaces are useful for the following: Specifying member function similarities between unrelated classes without artificially forcing a inheritance relationship on or between them. Declaring methods that one or more classes are expected to implement. Revealing an object's programming interface without revealing its class name. Interfaces are used extensively in some parts of Java, in particular in Java RMI and in the Java GUI system (called Abstract Windowing Toolkit and Swing). Interfaces allow another type of polymorphism, a type that is not related in any way to inheritance. This is particularly useful when, say, a Button icon when clicked in a Java applet doesn t know whether it is to call an actionperformed( ) member function on a Frame class Copyright Russell Tront, Page instance, a Panel class instance, an Oven class instance, or whatever. It doesn t really care. It has simply been told to call the actionperformed( ) function on an instance reference that is known to refer to some instance that implements the ActionListener interface. Copyright Russell Tront, Page 11-16

9 Using an Interface and Interface Polymorphism Students are often not familiar with how to use an interface because textbooks usually just show how to write a class that implements an interface. So here is an example of how an application programmer might use an interface type: you know, say, that the potential referred instances are at least related by inheritance. Instead, they are related by the fact they promise to implement a particular interface. (Note: You can often use the instanceof operator and/or Java Reflection with an interface reference to find out what kind of instance d actually refers to.) DownCounter d = new Airplane( ); The variable d is a reference to some kind of object that implements the two functions in the DownCounter interface above. This variable could, as shown above, refer to an instance of an Airplane class that has an altitude that can be set and decremented. Or later in a program it could refer to a Submarine class instance whose depth can be changed. Or, equally validly refer to an instance of a concrete DownCounterImpl class that simply contains an integer that can be decremented. The d variable can be thought of polymorphically, even though interestingly the various kinds of things it might refer to at different moments during execution are NOT related by inheritance! The programmer is nonetheless assured by Java that, no matter where the reference was obtained (do you trust your sources?) and irrespective of the underlying instance type it refers to, he/she can still legally execute a statement like: d.decrement(); So an interface reference is like an object reference, but the exact class of the referred to instance is not clear. Nor do Copyright Russell Tront, Page Copyright Russell Tront, Page 11-18

10 Implementing an Interface The DownCounter interface name is not the name of a class, so you cannot instantiate a DownCounter itself. As you saw above, we only defined a reference to something that implemented the DownCounter interface. For an instance to be assignable to an interface variable, the instance s class must meet certain criteria. The instance s class must implement the functions of the interface. Here is how it is done. public class DownCounterImpl implements DownCounter{ define any necessary member attributes needed to implement the advertised functions. actually provide function bodies that implement the advertised functions. Note the implementing class can provide additional functions not advertised in the interface if the programmer wants them for other purposes. Also note that several different classes could be written to implement the DownCounter interfaces. For example, in addition to the DownCounterImpl class, an Airplane class, a Submarine class, and an OvenTemperature class. //here is the where the counter is stored. private int thecount; public void setcount(int newvalue){ thecount = newvalue; public int decrement(){ thecount--; return thecount; The main issues in writing a class whose instances can be assigned to an interface reference variable are, to: declare right after the class name implements DownCounter. Copyright Russell Tront, Page Copyright Russell Tront, Page 11-20

11 11.4 Exercise B Take the abstract class OvenCA from the previous exercise, and convert it to an interface called OvenI. Then copy the class OvenSA over to a new class OvenSI. Change OvenSI so that it can implement OvenI. Hints and Questions: Can the interface OvenI still have constructors? Can the class OvenSI still be a subclass? Can the class OvenSI chain back to the superclass s constructors, non-overridden functions, and overridden functions? Here is a UML diagram of the architecture for this exercise. Note that UML identifies an interface with <<interface>> before the class name. And indicates implementing an interface with a dotted, inheritance-looking line. Copyright Russell Tront, Page <<interface>> OvenCA setoven( ) print( ) OvenSI temperature pressure percentoxygen percenthumidity setoven( ) print( ) static main( ) Notice that with OvenI being an interface, OvenSI has to provide all attributes and all method bodies. For brevity, I have dropped the static PrintOven( ) method. The above exercise will have you practice the elements of defining and implementing interfaces, but not the polymorphism use of interfaces. To do that, you would have to define two different classes that both implemented the same interface, perhaps both OvenSI and Fridge. A Fridge object would also have temperature, pressure, percenthumidity, et cetera, that could be set and printed. You might want to call the interface something more general than OvenI; perhaps MonitorableContainerI or IControllableAirspace. Then a polymorphic program could Copyright Russell Tront, Page 11-22

12 define an interface reference variable and could assign different kinds of instances to it: IcontrollableAirspace myairspaceobject myairspaceobject = new OvenSI( ); myairspaceobject = new Fridge( ); 11.5 Multiple Interfaces Most people will tell you that Java does not have multiple inheritance. That is not true. It is true that you cannot write a class that inherits from two parent classes. However, you can write an interface that inherits from two parent interfaces. Nevertheless, remember that an interface has no function implementation bodies to inherit and re-use. Therefore, an interface that inherits from two other interfaces just ends up with the signatures from those two, plus any it adds on its own. It is written this way: public interface Composite extends I1, I2 { void f( ); So interface Composite has all the function signatures and constants of interface I1, and of interface I2, and also function signature void f( ); In addition, a Java class can declare that it implements more than one interface, also using the comma notation: class C implements I1, I2 {/*body here*/ Finally, what is commonly done to simulate the multiple class inheritance feature that is in C++, but missing from Java, is to declare a subclass that inherits from one class and implement an interface. In this case, you use both the extends and implements keywords. e.g. class Mult extends Base implements Inter{ Copyright Russell Tront, Page Copyright Russell Tront, Page 11-24

13 11.6 Interface Constants and Other Weird Things You can put a few more kinds of things in an interface. Public static final constants are the most common. e.g. public interface Counter { int UPMODE = 1; int DOWNMODE = -1; void setmode(int mode); int count(); You don t have to bother labeling them public static final. You can also put nested class and nested interface definitions within an interface. Nested classes will be discussed in a different section of this course. Copyright Russell Tront, Page 11-25