A Problem – Object Model for a Simulation • Suppose we are designing the classes for a simulation game like the Sims, or Sim City • We might want to model CSE 143 Java • People (office workers, police/firemen, politicians, …) • Pets (cats, dogs, ferrets, lizards, …) • Vehicles (cars, trucks, buses, …) Interfaces • Physical objects (buildings, streets, traffic lights, …) • Object model – use inheritance Reading: Ch. 15.1.3 • Base classes for People, Pets, Vehicles, PhysicalThings, … • Extended classes for specific kinds of things (Cat extends Pet, Dog extends Pet, Truck extends Vehicle…) 10/9/2003 (c) 2001-3, University of Washington 03-1 10/9/2003 (c) 2001-3, University of Washington 03-2 Making it Tick Type Compatibility • A time-based simulation has some sort of clock that ticks • We want to be able to write something like regularly public void updateState(SimThing thing) { … } • On each tick, every object in the simulation needs to, for instance, where “SimThing” is a type that is compatible with Cats, update its state, maybe redraw itself, … Cars, People, Buildings. How? • We would like to write methods in the simulation engine that can • Could create an additional superclass SimThing and work with any object in the simulation have People, Pets, Vehicles, PhysicalThings, …, all /** update the state of simulation object thing for one clock tick */ extend it, but: public void updateState(??? thing) { thing.tick( ); • People, Pets, etc. don’t have a real “is-a” relationship thing.redraw( ); • What if we wanted to have other polymorphic methods that, for } example, only apply to breathing things? • Question: What is the type of parameter thing in this method? • Deep inheritance hierarchies are brittle, hard to modify 10/9/2003 (c) 2001-3, University of Washington 03-3 10/9/2003 (c) 2001-3, University of Washington 03-4 CSE143 Au03 03-1
Solution – Interfaces SimThing Interface • Interface declaration • We want a way to create a type SimThing independently /** Interface for all objects involved in the simulation */ of the simulation actor class hierarchies, then tag each public interface SimThing { of the simulation actor classes so they can be treated as public void tick( ); public void redraw( ); SimThings } • Solution: create a Java interface to define type SimThing • Class declaration using the interface /** Base class for all Pets in the simulation */ • Declare that the appropriate classes implement this public class Pet implements SimThing { interface /** tick method for Pets */ public void tick( ) { … } /** redraw method for Pets */ public void redraw( ) { … } … } 10/9/2003 (c) 2001-3, University of Washington 03-5 10/9/2003 (c) 2001-3, University of Washington 03-6 Interfaces and Implements • A Java interface declares a set of method signatures method signatures of • i.e., says what behavior exists I, without code; no interface I • Does not say how the behavior is implemented instance variables i.e., does not give code for the methods • Does not describe any state (but may include “final” constants) • A concrete class that implements an interface • Contains “implements InterfaceName ” in the class declaration methods of I, • Must provide implementations (either directly or inherited from including code concrete a superclass) of all methods declared in the interface class C other methods, • An abstract class can also implement an interface instance B's stuff • Can optionally have implementations of some or all interface variables of C methods 10/9/2003 (c) 2001-3, University of Washington 03-7 10/9/2003 (c) 2001-3, University of Washington 03-8 CSE143 Au03 03-2
Interfaces and Extends Classes, Interfaces, and Inheritance • Both describe an “is-a” relation • A class • If B implements interface A, then B inherits the • Extends exactly one other class (which defaults to Object if “extends …” does not appear in the class definition) (abstract) method signatures in A • Implements zero or more interfaces (no limit) • If B extends class A, then B inherits everything in A, • Interfaces can also extend other interfaces which can include method code and instance variables (superinterfaces) as well as abstract method signatures Interface ScaryThing extends SimThing { … } • Sometimes people distinguish “interface inheritance” • Mostly found in larger libraries and systems from “code” or “class inheritance” • A concrete class implementing an extended interface must • Informally, “inheritance” is sometimes used to talk implement all methods in that interface and all superinterfaces about the superclass/subclass “extends” relation only 10/9/2003 (c) 2001-3, University of Washington 03-9 10/9/2003 (c) 2001-3, University of Washington 03-10 What is the Type of an Object? Benefits of Interfaces • Every interface or class declaration defines a new type • May be hard to see in small systems, but in large ones… • An instance of a class named Example has all of these types: • Better model of application domain • The named class ( Example ) • Avoids inappropriate use of inheritance to get polymorphism • Every superclass that Example extends directly or indirectly (including • More flexibility in system design Object) • Every interface (including superinterfaces) that Example implements • Can isolate functionality in separate interfaces – better • The instance can be used anywhere one of its types is cohesion, less tendency to create monster “kitchen sink” appropriate interfaces or classes • As variables • Allows multiple abstractions to be mixed and matched as • As parameters and arguments needed • As return values 10/9/2003 (c) 2001-3, University of Washington 03-11 10/9/2003 (c) 2001-3, University of Washington 03-12 CSE143 Au03 03-3
Interfaces vs Abstract Classes Abstract Classes vs. Interfaces • Both of these specify a type Abstract Class Advantages Interface Advantages • A class can extend at most one • Can include instance variables • Interface superclass (abstract or not) • Can include a default (partial or • Pure specification • By contrast, a class (and an complete) implementation, as a interface) can implement any starter for concrete subclasses • No method implementationd (code), no instance variables, no number of super-interfaces • Wider range of modifiers and constructors • Helps keep state and behavior other details (static, etc.) • Abstract class separate • Can specify constructors, which • Provides fewer constraints on subclasses can invoke with super • Method specification plus, optionally: algorithms and data structures • Interfaces with many method Partial or full default method implementation specifications are tedious to Instance variables implement (implementations can’t Constructors (called from subclasses using super) be inherited) • Which to use? 10/9/2003 (c) 2001-3, University of Washington 03-13 10/9/2003 (c) 2001-3, University of Washington 03-14 A Design Strategy • These rules of thumb seem to provide a nice balance for designing software that can evolve over time (Might be overkill for some CSE 143 projects) • Any major type should be defined in an interface • If it makes sense, provide a default implementation of the interface – can be abstract or concrete • Client code can choose to either extend the default implementation, overriding methods that need to be changed, or implement the complete interface directly (needed if the class already has a specified superclass) • This pattern occurs frequently in the standard Java libraries 10/9/2003 (c) 2001-3, University of Washington 03-15 CSE143 Au03 03-4
Recommend
More recommend
