Java Interfaces 6 May 2019 OSU CSE 1 Conceptual Framework A - - PowerPoint PPT Presentation

java interfaces
SMART_READER_LITE
LIVE PREVIEW

Java Interfaces 6 May 2019 OSU CSE 1 Conceptual Framework A - - PowerPoint PPT Presentation

Java Interfaces 6 May 2019 OSU CSE 1 Conceptual Framework A firm conceptual foundation for understanding and designing modern software recognizes: Modern software consists of potentially large numbers of components that are composed


slide-1
SLIDE 1

Java Interfaces

6 May 2019 OSU CSE 1

slide-2
SLIDE 2

Conceptual Framework

  • A firm conceptual foundation for

understanding and designing modern software recognizes:

– Modern software consists of potentially large numbers of components that are composed into “larger” components/systems – In Java, one ordinarily thinks of a class as a component, with its client-visible specification in the interface(s) it implements

6 May 2019 OSU CSE 2

slide-3
SLIDE 3

Conceptual Framework

  • A firm conceptual foundation for

understanding and designing modern software recognizes:

– Modern software consists of potentially large numbers of components that are composed into “larger” components/systems – In Java, one ordinarily thinks of a class as a component, with its client-visible specification in the interface(s) it implements

6 May 2019 OSU CSE 3

An interface contains a description of what software does.

slide-4
SLIDE 4

Conceptual Framework

  • A firm conceptual foundation for

understanding and designing modern software recognizes:

– Modern software consists of potentially large numbers of components that are composed into “larger” components/systems – In Java, one ordinarily thinks of a class as a component, with its client-visible specification in the interface(s) it implements

6 May 2019 OSU CSE 4

A class contains a description of how the software does it. An interface contains a description of what software does.

slide-5
SLIDE 5

Anatomy of an Interface

/** * An informal Javadoc comment. * [additional Javadoc comments as needed; in our * case: the mathematical model, contract(s) for * constructor(s), optional contract for iterator] */ public interface I { // contract(s) for method(s) }

6 May 2019 OSU CSE 5

slide-6
SLIDE 6

Anatomy of an Interface

/** * An informal Javadoc comment. * [additional Javadoc comments as needed; in our * case: the mathematical model, contract(s) for * constructor(s), optional contract for iterator] */ public interface I extends I1, I2 { // contract(s) for method(s) }

6 May 2019 OSU CSE 6

An interface may extend one or more

  • ther interfaces.
slide-7
SLIDE 7

Anatomy of an Interface

/** * An informal Javadoc comment. * [additional Javadoc comments as needed; in our * case: the mathematical model, contract(s) for * constructor(s), optional contract for iterator] */ public interface I<T> extends I1<T>, I2 { // contract(s) for method(s) }

6 May 2019 OSU CSE 7

An interface may be generic, as seen here; formal parameter T may have any name, but T is typical (for “type”).

slide-8
SLIDE 8

Technicalities

  • Interfaces may be used to define:

– instance methods – static final variables (“constants”) – Not constructors – Not static methods – Not instance variables

6 May 2019 OSU CSE 8

slide-9
SLIDE 9

Technicalities

  • Interfaces may be used to define:

– instance methods – static final variables (“constants”) – Not constructors – Not static methods – Not instance variables

6 May 2019 OSU CSE 9

Instance methods in an interface are by default public abstract. (private instance methods and public/private static methods are allowed—but they cannot be abstract.)

slide-10
SLIDE 10

Technicalities

  • Interfaces may be used to define:

– instance methods – static final variables (“constants”) – Not constructors – Not static methods – Not instance variables

6 May 2019 OSU CSE 10

Variables are automatically public static final; it is unusual for an interface to define variables.

slide-11
SLIDE 11

Technicalities

  • Interfaces may be used to define:

– instance methods – static final variables (“constants”) – Not constructors – Not static methods – Not instance variables

6 May 2019 OSU CSE 11

A constructor always has the name of a class, and is not an instance method.

slide-12
SLIDE 12

Technicalities

  • Interfaces may be used to define:

– instance methods – static final variables (“constants”) – Not constructors – Not static methods – Not instance variables

6 May 2019 OSU CSE 12

Interfaces allow static methods with their

  • implementations. But

providing code in interfaces goes against our use of interfaces for client views (this biases designs to instance methods).

slide-13
SLIDE 13

Technicalities

  • Interfaces may be used to define:

– instance methods – static final variables (“constants”) – Not constructors – Not static methods – Not instance variables

6 May 2019 OSU CSE 13

This is a good thing: instance variables are not client-view information!

slide-14
SLIDE 14

Example: Queue Component Family

6 May 2019 OSU CSE 14

Queue QueueKernel extends Standard extends Iterable extends

slide-15
SLIDE 15

Example: Queue Component Family

6 May 2019 OSU CSE 15

Queue QueueKernel extends Standard extends Iterable extends Which methods are in Standard, and why?

slide-16
SLIDE 16

Example: Queue Component Family

6 May 2019 OSU CSE 16

Queue QueueKernel extends Standard extends Iterable extends We call the “core interface” in this design style the kernel interface.

slide-17
SLIDE 17

Example: Queue Component Family

6 May 2019 OSU CSE 17

Queue QueueKernel extends Standard extends Iterable extends We call the “most powerful interface” in this design style the enhanced interface.

slide-18
SLIDE 18

Let’s Examine...

  • Standard
  • QueueKernel
  • Queue

6 May 2019 OSU CSE 18

Ask about details, e.g.:

  • Design choices (math

model, constructor, kernel methods, other methods)

  • Javadoc (compare code in

the Java interface with the generated documentation)

slide-19
SLIDE 19

Interface Design

  • The kernel interface defines:

– The mathematical model for the type – Contract(s) for the constructor(s) – Contract(s) for kernel methods – Contract(s) for methods inherited from Java library interfaces that do not have their own contract specifications (if applicable; e.g., an iterator or a comparator)

  • The enhanced interface defines contracts

for all other methods for the type

6 May 2019 OSU CSE 19

slide-20
SLIDE 20

Kernel Design Guidelines

  • Kernel methods generally should be:

– A minimal set of methods that is functionally complete, i.e., powerful enough to:

  • Give a variable of the type any allowable value
  • Determine the value of a variable of the type

– Powerful enough to allow a client to:

  • Implement equals and toString
  • Check every kernel method’s precondition

6 May 2019 OSU CSE 20

slide-21
SLIDE 21

Kernel Design Guidelines

  • Kernel methods generally should be:

– A minimal set of methods that is functionally complete, i.e., powerful enough to:

  • Give a variable of the type any allowable value
  • Determine the value of a variable of the type

– Powerful enough to allow a client to:

  • Implement equals and toString
  • Check every kernel method’s precondition

6 May 2019 OSU CSE 21

“Minimal” means if any proposed kernel method were left out, you could not satisfy one of the completeness tests—though sometimes an “extra” kernel method is so parsimonious it is included in the kernel anyway!

slide-22
SLIDE 22

Notice: Circularity

public interface QueueKernel<T> extends Standard<Queue<T>>, Iterable<T> { ... } public interface Queue<T> extends QueueKernel<T> { ... }

6 May 2019 OSU CSE 22

slide-23
SLIDE 23

Notice: Circularity

public interface QueueKernel<T> extends Standard<Queue<T>>, Iterable<T> { ... } public interface Queue<T> extends QueueKernel<T> { ... }

6 May 2019 OSU CSE 23

Using Queue<T> is necessary because it is the return type of newInstance and the interface type we always use to declare Queue variables.

slide-24
SLIDE 24

What “Mentions” What?

6 May 2019 OSU CSE 24

Queue QueueKernel “mentions” Standard “mentions” Iterable “mentions” “mentions”

slide-25
SLIDE 25

Interface = Type

  • Java permits the circularity here because:

– A Java interface defines a type, i.e., the type name (which we consider to denote a set of mathematical model values that certain variables might have) along with the set of its instance methods – An interface type may be used in Java even if there is no implementation of it in scope

6 May 2019 OSU CSE 25

slide-26
SLIDE 26

Interfaces: Only At Compile-Time

  • Interfaces are a compile-time construct

– Used by the Java compiler for type-checking with declared types: to make sure variables are used only where they make sense

  • Recall the rules for declared types and object

(dynamic) types

– Once a Java program compiles, only object types are kept at run-time

  • Declared types literally “disappear” in the JVM

6 May 2019 OSU CSE 26

slide-27
SLIDE 27

Interfaces: Only At Compile-Time

  • Interfaces are a compile-time construct

– Used by the Java compiler for type-checking with declared types: to make sure variables are used only where they make sense

  • Recall the rules for declared types and object

(dynamic) types

– Once a Java program compiles, only object types are kept at run-time

  • Declared types literally “disappear” in the JVM

6 May 2019 OSU CSE 27

  • The declared type of a variable may be an interface type
  • The object type can never be an interface type, because

you may not instantiate a variable using new followed by an interface type

  • If the declared type is an interface type, then the object

type (a class) must implement the declared type (an interface)

slide-28
SLIDE 28

Javadoc Tags

  • Recall that the short one-sentence

informal overview, and the following standard Javadoc tags, are “expected”:

– @param – @return

6 May 2019 OSU CSE 28

slide-29
SLIDE 29

Javadoc Tags

  • Recall that the short one-sentence

informal overview, and the following standard Javadoc tags, are “expected”:

– @param – @return

6 May 2019 OSU CSE 29

Checkstyle warns you if they are missing when they should be there.

slide-30
SLIDE 30

Custom Javadoc Tags

  • Javadoc supports custom tags that can

be introduced to document various aspects not considered when Javadoc was introduced

– Example: contracts

6 May 2019 OSU CSE 30

slide-31
SLIDE 31

OSU CSE Custom Contract Tags

6 May 2019 OSU CSE 31

Custom Tags for Interfaces Custom Tags for Classes @mathsubtypes @convention @mathdefinitions @correspondence @mathmodel @initially @iterator

slide-32
SLIDE 32

6 May 2019 OSU CSE 32

Custom Tags for Constructors and Methods Custom Tags for Loops @aliases @maintains @updates @decreases @replaces @clears @requires @ensures @decreases

OSU CSE Custom Contract Tags

slide-33
SLIDE 33

Packages

  • Each OSU CSE component family is

bundled into its own package, i.e., a grouping of interfaces and classes that the designer thinks “belong together” for logical reasons

– Example: the Queue-family components are all in the package components.queue

6 May 2019 OSU CSE 33

slide-34
SLIDE 34

Packages Are Useful

  • A package provides:

– Logical structuring: packages are hierarchical, i.e., you may have packages within packages – A namespace: units in different packages may have the same name without conflict

  • See also import statements

– Another level of access control between public and private

6 May 2019 OSU CSE 34

slide-35
SLIDE 35

Packages Are Useful

  • A package provides:

– Logical structuring: packages are hierarchical, i.e., you may have packages within packages – A namespace: units in different packages may have the same name without conflict

  • See also import statements

– Another level of access control between public and private

6 May 2019 OSU CSE 35

But any apparent “control” is easily circumvented and illusory, so we do not recommend using it.

slide-36
SLIDE 36

Package Declaration

package components.queue; import components.standard.Standard; public interface Queue<T> ...

  • A Java file must be in a file system

directory matching the package name

– Eclipse handles this correspondence for you

  • At most one package declaration per file

– If there is no package declaration, interface/class is in unnamed default package

6 May 2019 OSU CSE 36

slide-37
SLIDE 37

Package Declaration

package components.queue; import components.standard.Standard; public interface Queue<T> ...

  • A Java file must be in a file system

directory matching the package name

– Eclipse handles this correspondence for you

  • At most one package declaration in a file

– If there is no package declaration, interface/class is in unnamed default package

6 May 2019 OSU CSE 37

This line declares that the interface (or class) in the current file belongs to the package components.queue.

slide-38
SLIDE 38

Package Declaration

package components.queue; import components.standard.Standard; public interface Queue<T> ...

  • A Java file must be in a file system

directory matching the package name

– Eclipse handles this correspondence for you

  • At most one package declaration in a file

– If there is no package declaration, interface/class is in unnamed default package

6 May 2019 OSU CSE 38

This line brings the interface Standard into scope, from the package components.standard.

slide-39
SLIDE 39

Resources

  • Java for Everyone, Section 9.6: Interface Types

– http://osu.worldcat.org/title/java-for-everyone-late-objects/oclc/808511232

  • javadoc — The Java API Documentation

Generator

– http://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html

6 May 2019 OSU CSE 39