Interface Specifications

Benefits of Modularity

• Simplify software development
  • supports decomposition into components (e.g: classes)
  • allows each component to be considered and developed independently
• Facilitates change
  • Consolidates info into modules
  • Enables code to change so long as
    1. component code only relies on the interface
    2. the interface is stable
• Supports Teamwork
  • defined boundaries between each module's implementation and the client's code
  • allows parallel development

An interface is the public "persona" of the modules i.e: a modules' public data and signatures

- A form of data encapsulation and information hiding
- defines behavior

Interface Specification

An interface specification is a contract between the modul's provider and the client programmer, that documents each other's expectations.

- used to document the design of a future modules
- used to document the correct usage of an existing modules

They need to cover corner cases!

Many times, the structure of an algorithm affects it's specification.

A complicated description may imply poor design or poor understanding of the problem...

Interface Specifications in CS 247

Preconditions: Constraints that hold before the method is called. If none are specified, anything goes.

Format: // requires: ... assumptions about program state

Postconditions: Constraints that hold after the method is called (assuming valid preconditions)

Formats: // modifies: ... objects / variables that may be changed by the method // throws: ... thrown exceptions, and conditions leading to such exceptions // ensures: ... (guarantees) side effects on modified objects // returns: ... describes return value

Specifying Derivations

Derived classes inherit not only interface signatures, but also specifications.

We can specify a derived class by either listing all of its specification fields (inherited and new), or by listing just the new fields.

When specifying an overridden method, it is best to provide the complete specification (rather than attempt to provide just extension).

Comparing Specifications

Specification A is stronger than specification B (A⇒B) iff

1. A's preconditions are equal to or weaker (less restrictive) than B's preconditions
   • requires B ⇒ requires A
2. A's postconditions are equal to or stronger (promise more) than B's postconditions
   • (requires B ⇒ (ensures A ∧ returns A) ⇒ (ensures B ∧ returns B)
3. A modifies the same or more objects
   • (requires B ⇒ (modifies B ⊆ modifies A)
4. A throws the same or fewer exceptions
   • (requires B ⇒ (throws A ⊆ throws B)

Checking Preconditions

If preconditionsaren't met, we could do anything, and we would still technically be in the right. Some examples of things we could do:

• return without executing
• throw an exception
• terminate the program
• process the call "the best you can"

That said though, it would be nice to report something in these cases. It makes the code nicer to use, and more robust.

Obligation: The client is responsible for ensuring that the preconditions are met before calling our code.

Best practices:

1. Check precondition if it is easy to do so; throw exception if not satisfied.
2. Try to detect problem and report error.