Unformatted text preview:

The Evolution of InterfacesKenneth M. AndersonUniversity of Colorado, BoulderCSCI 4448/5448 — Lecture 30 — 12/10/09© University of Colorado, 20091Credit where Credit is Due• Some of the material for this lecture is taken from “Programming in Scala” by Martin Odersky, Lex Spoon, and Bill Venners• as such some of this material is copyright © 2007, 2008 Odersky, Spoon and Venners• In addition, some material is taken from “Ruby For Rails” by David Black• as such some of this material is copyright © 2006 Manning Publications2Goals for this Lecture• Examine mechanisms in more recent OO languages for evolving the concept of “interface”, providing flexibility in specifying the types of an application• Go (briefly)• Clojure (briefly)• Scala• Ruby• Wrap up the semester3Review: (Lecture 3) Relationships: Interfaces• A class can indicate that it implements an interface•An interface is a type of class definition in which only method signatures are defined•A class implementing an interface provides method bodies for each defined method signature in that interface• This allows a class to play different roles, each role providing a different set of services• These roles are then independent of the class’s inheritance relationships• Other classes can then access a class via its interface• This is indicated via a “ball and socket” notation4Reminder (Lecture 4): Interface Example• Consider modifying the Animal hierarchy to provide operations related to pets (e.g. play() or takeForWalk())• We have several options, all with pros and cons• add Pet-related methods to Animal• add abstract Pet methods to Animal• add Pet methods only in the classes they belong (no explicit contract)• make a separate Pet superclass and have pets inherit from both Pet and Animal• make a Pet interface and have only pets implement it• This often makes the most sense although it hinders code reuse• Variation: create Pet interface, but then create Pet helper class that is then composed internally and Pet’s delegate if they want the default behavior5Reminder (Lecture 4): Animals (With Inheritance)CatmakeNoise()TigermakeNoise()RhinomakeNoise()Animalsleep()Felineroam()Canineroam()Pachydermroam()WolfmakeNoise()WolfDogmakeNoise()LionmakeNoise()ElephantmakeNoise()HippomakeNoise()6Essentially, how do we make Dog and Cat be Pets without impacting the rest of the classes?Considering the alternatives (I)• Consider modifying the Animal hierarchy to provide operations related to pets (e.g. play() or takeForWalk())• We have several options, all with pros and cons• add Pet-related methods to Animal• This approach is sub-optimal because non-Pet classes receive Pet behaviors via inheritance; you would be forced to override those behaviors to raise an exception for non-Pets.7Considering the alternatives (II)• Consider modifying the Animal hierarchy to provide operations related to pets (e.g. play() or takeForWalk())• We have several options, all with pros and cons• add abstract Pet methods to Animal• even worse than previous solution!• every subclass gets Pet methods AND has to implement them• with the former method, you at least could take advantage of code reuse8Considering the alternatives (III)• Consider modifying the Animal hierarchy to provide operations related to pets (e.g. play() or takeForWalk())• We have several options, all with pros and cons• add Pet methods only in the classes they belong (no explicit contract)• With this approach (at least in Java and languages similar to it), you lose the advantage of having a type called Pet• Instead, your code just has to know that Dog IS-A Pet and that it can invoke Pet operations on it. It also had to know that Dogs and Cats can be treated similarly via their shared Pet methods• But you would get no support for the type system!•You can’t do this: Pet p = new Dog();• You can’t do this: Pet[] p = [new Dog(), new Cat(), new Dog()];9Considering the alternatives (IV)• Consider modifying the Animal hierarchy to provide operations related to pets (e.g. play() or takeForWalk())• We have several options, all with pros and cons• make a separate Pet superclass and have pets inherit from both Pet and Animal• Multiple Inheritance: enough said10Considering the alternatives (V)• Consider modifying the Animal hierarchy to provide operations related to pets (e.g. play() or takeForWalk())• We have several options, all with pros and cons• make a Pet interface and have only pets implement it• This often makes the most sense although it hinders code reuse• Variation: create Pet interface, but then create Pet helper class that is then composed internally and Pet’s delegate if they want the default behavior11The landscape is evolving...• New language features are offering additional alternatives to the ones above• or, in one case, removing the cons associated with one of the alternatives• Consider the use of “interface” in the Go programming language...12The basics of Go (I)• No explicit support for objects, no type inheritance, no generics, etc.• To get object-like support, first define a structtype File struct { fd int; // file descriptor number name string; // file name at Open time}• and create a factory:func newFile(fd int, name string) *File { if fd < 0 { return nil } return &File{fd, name}}13The basics of Go (II)• To use the factoryvar Stdin = newFile(0, “/dev/stdin”);• The type of Stdin is *File. To define a method that operates on Files do:func (file *File) Close() os.Error {…}func (file *File) Read(b []byte) (ret int, err os.Error) {…}func (file *File) Write(b []byte) (ret int, err os.Error) {…}• The syntax therefore is: func <receiver>? <name>(<params>) (<return types>) <body>• On to interfaces...14Interfaces in Go• Interfaces are special types in Go that define method signatures type reader interface { Read(b []byte) (ret int, err os.Error); }• This defines a type name called “reader” and this type name can now be used anywhere a type name can appear in Go:• as a receiver, as a parameter, as a return type• What’s more, an “object” (struct + methods) does not have to declare that it implements an interface: Instead, if it has all the methods defined by the interface it automatically matches!•We can pass a *File to ANY method that accepts a reader as a


View Full Document

CU-Boulder CSCI 5448 - The Evolution of Interfaces

Documents in this Course
Django

Django

42 pages

ENRS

ENRS

30 pages

PhoneGap

PhoneGap

22 pages

Load more
Download The Evolution of Interfaces
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view The Evolution of Interfaces and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view The Evolution of Interfaces 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?