M3 — Interfaces, Polymorphism, and Design Patterns

SENG 365 — Software Engineering

Neil Ernst
nernst@uvic.ca

University of Victoria

2026-07-24

Learning Objectives

Learning Objectives

Reading: Robillard, 3rd ed. — Ch. 3, Types and Interfaces (pp. 43–66).

  • When and how to use interfaces
  • The uses of polymorphism
  • The notion of design patterns
  • Overview of JUnit testing

Interfaces and Implementation

Interfaces and Implementation

Design for other classes to use (clients) vs. internal implementation.

  • What should a Deck offer? A Card? A Game?
  • An interface is a formal guarantee (contract) and enables subtype relationships.
  • Interface decouples definitions from implementation.

BookIS Example

  • We maintain an inventory of books, but sell many things.
  • Bad design tightly couples “managing books” and makes adding other items hard.
  • Class vs. object; interface vs. class (Python and Java, multiple inheritance).

Duck Typing and Inspection

  • Duck typing: “I don’t care what the object is, I need to do X with it.”
  • invoke vs. inspect: inspect is frowned upon in Java (but possible via reflection); more central in dynamically typed languages.
  • Python is strongly typed and dynamically typed.
x = [3, 4, 5]
type(x)
x.__getitem__(1)   # == x[1]
isinstance(x, list)
dir(x)

Polymorphism

Polymorphism

  • “Many shapes.” Why?
  • Notion of a base class (Icon example).
  • Gives us loose coupling and extensibility.
  • You can assign a value to a variable if the value is of the same type or a subtype of the variable’s type.

Polymorphism

Explain polymorphism to your neighbour. Create one concrete example, and list an advantage.

  • shuffle vs. sort — sort needs help
  • collections type hierarchy
  • type parameters

Function Objects and Comparators

Class Diagrams

  • A static view.
  • All models are abstractions — not everything needs to be in the model.
  • Video 3-1: creating class diagrams in JetUML and PlantUML.

Comparator

Different ways to compare things. Comparable says a type can be compared; Comparator says how.

  • Comparator as top-level class — no private access
  • Comparator as nested class — more verbose
  • Comparator as anonymous class — fine if stateless and used once
  • Comparator as lambda — function object, no state
  • Factory method — verbose but keeps logic inside Card

Comparator

fleet.sort(new ByAccelComparator());
fleet.sort((c1, c2) -> c1.getBrakingDistance() - c2.getBrakingDistance());

Write the car comparators. Add a byBrakingDistance comparator as a lambda.

Design Patterns

Anatomy of a Pattern

  1. Name
  2. Problem / Context
  3. Solution (often a UML class diagram)
  4. Consequences

Iterator

An interface expecting hasNext() and next().

  • Implementing Iterable indicates a set of things can be iterated over.
  • How you find the next thing or determine emptiness is implementation-dependent.

Strategy

  • Strategy is just like the Comparator we discussed.
  • Switch algorithms for a problem — otherwise just polymorphism.
  • Design questions: stateful? return types and side effects?

“Define a family of algorithms, encapsulate each one, and make them interchangeable.”

Interface Segregation Principle (ISP)

  • Don’t depend on or couple too tightly.
  • Related to Single Responsibility.
  • “Do I need to depend on everything in this interface?”

In-Class Activities

Day 1

  • Team meeting / overview of peer eval
  • Go over EX2 feedback; EX3 overview; survey

Day 2

Day 3

  • Group meetings / office hours