Engineering with Interfaces - cs.brown.educs.brown.edu/courses/cs0320/lectures/interfaces.pdf · John Jannotti (cs32) Engineering with Interfaces Feb 1, 2018 12 / 1. Now, realize

Course Announcements

Lecture capture has begun, available from Lectures page.

First two and a half weeks are packed.

Testing lab done, HTML started, and Stars due next Friday.

Department has a lot of student research opportunitiesI MURA Office hours – Thurs at 12-1pm in CIT 546I Contact [email protected] for more info.

John Jannotti (cs32) Engineering with Interfaces Feb 1, 2018 1 / 1

Engineering with Interfaces

John Jannotti

/course/cs0320/www/lectures/

Feb 1, 2018


Review(?): Java Interfaces

An interface is a collection of related method signatures.

Interface methods contain no code.I This has changed slightly in Java 8. See default methods.

A class implements an interface byI Saying so: implements RunnableI And: Implementing every method from the interface. (Use @Override)

An interface is used as a type, just like a class.I An object of any class that implements the type can be assigned.I Animal cardinal = new Bird(Color.RED, location);I You can only call the Animal methods on cardinal, not Bird’s.I bird.move() perhaps, but not bird.fly().I List<Cat> cats = new ArrayList<>();I cats.ensureCapacity(1000); is a compile error.


Interfaces specify, they do not implement

Export functionality without revealing/promising details.I List<String> names = Collections.emptyList();I What is the class of names?

Constrain objects taken as arguments.I Arguments to methods: Collections.shuffle(List)I Arguments to generic types, like. . .

I public class KdTree<T extends Cartesian>

Or both in one example.

I List safe = Collections.unmodifiableList(lst)I Your first Pattern: Decorator (But a particularly vacuous example)




Constrain objects taken as arguments.I Arguments to methods: Collections.shuffle(List)I Arguments to generic types, like. . .I public class KdTree<T extends Cartesian>

Or both in one example.

I List safe = Collections.unmodifiableList(lst)I Your first Pattern: Decorator (But a particularly vacuous example)





Or both in one example.I List safe = Collections.unmodifiableList(lst)

I Your first Pattern: Decorator (But a particularly vacuous example)





Or both in one example.I List safe = Collections.unmodifiableList(lst)I Your first Pattern: Decorator (But a particularly vacuous example)


Example: Comparable

Java supplies a Collections.sort() method.

What can you pass it?I How would you sort Strings? LatLng? Chairs?

I If you look it up, you find: void sort(List<T> list)I Where did T come from? What should T mean?

sort() shouldn’t need to know how every T is ordered.

So it requires that its argument implement Comparable.

Technically: <T extends Comparable<? super T>>

To be Comparable, objects implement one method, compareTo().

Collections.sort calls compareTo() as needed.

Back to LatLng. . . What might LatLng.compareTo() do?

If there’s no LatLng.compareTo(), can I sort them?

The two argument version of sort() takes another interface,Comparator, to add more flexibility.


Example: Comparable


What can you pass it?I How would you sort Strings? LatLng? Chairs?I If you look it up, you find: void sort(List<T> list)I Where did T come from? What should T mean?










Example: Comparable












Example: Comparable












Example: Comparable












Comparable.java (Download the JDK source!)

1 p u b l i c i n t e r f a c e Comparable<T> {2 /∗∗3 ∗ . . .4 ∗ @param o t he o b j e c t to be compared .5 ∗ @ r e t u r n a n e g a t i v e i n t e g e r , ze ro , o r a6 ∗ p o s i t i v e i n t e g e r as t h i s o b j e c t7 ∗ i s l e s s than , e q u a l to , o r g r e a t e r8 ∗ than t he s p e c i f i e d o b j e c t .9 ∗

10 ∗ @throws N u l l P o i n t e r E x c e p t i o n i f ’ o ’ i s n u l l11 ∗ @throws C l a s s C a s t E x c e p t i o n i f t he t y p e o f ’ o ’12 ∗ cannot b e i n g compared to t h i s .13 ∗/14 p u b l i c i n t compareTo (T o ) ;15 }


Comparator separates a class and a sort order

1 p u b l i c i n t e r f a c e Comparator<T> {2 i n t compare (T o1 , T o2 ) ;3 }4 p u b l i c N o r t h F i r s t implements Comparator<LatLong> {5 i n t compare ( LatLng a , LatLng b ) {6 r e t u r n Double . compare ( a . g e t L a t i t u d e ( ) ,7 b . g e t L a t i t u d e ( ) ) ;8 }9 }

10 C o l l e c t i o n s . s o r t ( somePoints , new N o r t h F i r s t ( ) ) ;11 // somePoints i s now s o r t e d . How?12 // What happens i f some p o i n t s have t he same l a t i t u d e ?


A Comparator can profitably use state

1 p u b l i c N e a r e s t implements Comparator<LatLong> {2 p r i v a t e f i n a l LatLng pt ;3 p u b l i c N e a r e s t ( LatLng pt ) {4 t h i s . pt = pt ;5 }6 i n t compare ( LatLng a , LatLng b ) {7 r e t u r n Double . compare ( pt . d i s t a n c e ( a ) ,8 pt . d i s t a n c e ( b ) ) ;9 }

10 }11 LatLng pvd = new LatLng ( 4 2 . 3 6 , −71.09) ;12 C o l l e c t i o n s . s o r t ( somePoints , new N e a r e s t ( pvd ) ) ;13 // somePoints a r e now i n o r d e r from P r o v i d e n c e .14 // With lambda e x p r e s s i o n s , t h i s becomes one l i n e .


Using interfaces

1 i n t e r f a c e V e h i c l e { v o i d move ( ) ; }2 c l a s s Car implements V e h i c l e {3 p u b l i c v o i d move ( ) { d r i v e ( ) ; }4 v o i d d r i v e ( ) { /∗ ∗/ } }5 c l a s s Boat implements V e h i c l e {6 p u b l i c v o i d move ( ) { f l o a t ( ) ; }7 v o i d f l o a t ( ) { /∗ ∗/ } }8 V e h i c l e v = new V e h i c l e ( ) ;9 V e h i c l e c a r = new Car ( ) ;

10 V e h i c l e boat = new Boat ( ) ;11 c a r . d r i v e ( ) ;12 boat . move ( ) ;

Which lines contain compile-time errors?


Case study: Battleship Tournament

Consider a library for running games, or entire tournaments.I User implements some strategies, library tries them out.

How can the library avoid impacting player design?I Good libraries do not impose their world-view on callers.

The library provides a Game and Tournament abstraction.I How would you implement Game? How does a caller construct one?I How about Tournament? How can the library make games on demand?


What are the Classes?

What information do we need?I To describe the competitors?I To enforce rules?I To determine a winner (of a game? of a tournament?)

How can callers supply that information?I Without undue inconvenience.I Or constraint on their design.


First, imagine you are the caller.

In a library, your first concern should be how your code will be used.

How would you like the code to look?

What would you pass to a “Game” object?

A “Tournament” object?

1 p u b l i c c l a s s Main {2 p u b l i c s t a t i c main ( S t r i n g [ ] a r g s ) {3 Game g = new Game ( . . . ) ;4 . . .5 Tournament t = new Tournament ( . . . ) ;6 }7 }

What “makes sense” in the ellipses?


Now, realize you are not the caller.

You should not force callers to use your classes.

You should not expose your internal classes.

Interfaces are much more flexible.

Consider exactly what Game needs from Player.I Start the game, convey rules.I Get Player’s ship positions.I Ask the Player to take a turn.I Report to the Player what happened.

Define an interface with exactly those requirements.

A caller may implement the interface using their own existingabstractions.


Player.java

1 package edu . brown . c s . s t a f f . b a t t l e s h i p ;2

3 i m p o r t j a v a . u t i l . Map ;4

5 p u b l i c i n t e r f a c e P l a y e r {6 Map<Ship , Placement> s e t u p ( P o s i t i o n max ) ;7 P o s i t i o n f i r e ( ) ;8 v o i d r a d a r ( P o s i t i o n pos , Impact impact ) ;9 }


How much design is dictated?

Note that there’s no concept of Board, or “Game State”I Yes, Game will surely have one internally.I But clients do not use Game’s representation.I Game need not even be a public class.I General principle: sharing state is error-prone.

Clients are not required to inherit from a class.I A Java class extends only one superclass.I But it implements as many interfaces as desired.I What if a caller also wants to use a UI or persistence library?

Why expose Placement, Position, and Impact?I These are “small” concepts.I And are mostly information for the caller.I All are immutable.I You could make them interfaces too, but little gain.


A Player is largely unconstrained

Let’s look at. . .

DumbPlayer

RandomPlayer

DecentPlayer

MemoPlayer extents WrapPlayer

Note that none contain a Board. They have their own notions ofimportant state.


What about Tournaments?

Can you run a Tournament with the Player interface?

Maybe. Tournament could call setup() for each new game.

But there are drawbacksI Explaining the Player “lifecycle” becomes more complex. Not ETU.I Reinitializing objects “smells bad.” Not SFB.I Doomed to run the tournament on only one core. Not RFC.

Let’s have the Tournament start each Game with fresh Players.

How can callers provide all those Players?


A bad idea...

1 p u b l i c c l a s s Main {2 p u b l i c s t a t i c main ( S t r i n g [ ] a r g s ) {3 Tournament t = new Tournament ( ) ;4 L i s t <P l a y e r> randoms = new A r r a y L i s t <>();5 L i s t <P l a y e r> d e c e n t s = new A r r a y L i s t <>();6 f o r ( i n t i = 0 ; i < 1 0 0 ; i ++) {7 randoms . add ( new RandomPlayer ( ) ) ;8 d e c e n t s . add ( new D e c e n t P l a y e r ( ) ) ;9 }

10 t . a d d P l a y e r ( ”Randy” , randoms ) ;11 t . a d d P l a y e r ( ” Joe ” , d e c e n t s ) ;12 t . run ( ) ;13 }14 }

Could we let the Tournament instantiate the Players as needed, instead?John Jannotti (cs32) Engineering with Interfaces Feb 1, 2018 18 / 1

Factories abstract creation

Code in one module needs to create objects best made by another.

Tournament needs to create Players to run more Games.

The second module can supply a Factory instead of the objectsthemselves. (Your second Pattern)

1 package edu . brown . cs32 . s t a f f . b a t t l e s h i p ;2

3 p u b l i c i n t e r f a c e P l a y e r F a c t o r y {4 p u b l i c P l a y e r c r e a t e ( ) ;5 }


A better idea.

1 p u b l i c s t a t i c main ( S t r i n g [ ] a r g s ) {2 Tournament t = new Tournament ( ) ;3 t . a d d P l a y e r ( ”Randy” , new RandomFactory ( ) ) ;4 t . a d d P l a y e r ( ”Dumbo” , new DumbFactory ( ) ) ;5 t . run ( ) ;6 }

As needed, the Tournament invokes create() on the supplied Factory.


Review

Design in terms of interfaces

Keep the interfaces short and abstract, only what is required.

Only expose classes if you must, or they are very simple.

Think about different approachesI Although there are no completely “right” or “wrong” answers,I Some are better than others

F Simpler, easier to use. (ETU, SFB)F More flexible in handling evolution. (RFC)

I If a design is “bad” in one way, it had better have something else torecommend it.

I You might sacrifice ETU for a large performance gain, but you hadbetter be sure you need to. Hint: profile.


Before Java 8, interfaces can be wordy

Recall Tournament.addPlayer(PlayerFactory pf).

Defined a new interface, PlayerFactory, to let callers do creation asneeded.

Callers created a PlayerFactory implementation, then constructed it.

t.addPlayer(”Randy”, new RandomFactory())

Wordy, and “hides” the implementation (from the callsite)


Lambda expressions to the rescue

Prefer Tournament.addPlayer(Supplier<Player> sp)1

I Call with t.addPlayer("Randy", () => new RandomPlayer())

Compiler sees that Tournament.addPlayer expects a “Functional” or“Single Abstract Method” interface.

So it creates one.

Handy interfaces like Supplier avoid declaring a lot of new interfaces.

Lambdas avoid the creation of tiny interface implementations.

You can also use a “method reference” to implement a SAM.I Then call with t.addPlayer("Randy", RandomPlayer::new)

1java.util.function.Supplier, which contains only get().John Jannotti (cs32) Engineering with Interfaces Feb 1, 2018 23 / 1

Engineering with Interfaces - cs.brown.educs.brown.edu/courses/cs0320/lectures/interfaces.pdf · John Jannotti (cs32) Engineering with Interfaces Feb 1, 2018 12 / 1. Now, realize

Documents