M2 — Abstraction, Types, and Encapsulation

SENG 365 — Software Engineering

Neil Ernst
nernst@uvic.ca

University of Victoria

2026-07-31

Learning Objectives

Learning Objectives

Reading: Robillard, 3rd ed. — Ch. 2, Encapsulation (pp. 13–41).

  • Software is about abstraction
  • Programming in OO Java and design in the small
  • Encapsulation buries the details and exposes only the interface — a key concept
  • How should we represent a hockey/soccer league? What are the key abstractions?

Foundations

OOP History

OOP history

Where does Python fit in this graph? Is it OO?

Software Process

  • Waterfall vs. Agile
  • Cynefin

Cynefin

Key: have a process, follow it, and reflect on the results.

Encapsulation

What are some reasons to practise information hiding?

  • A class is two things: implementation and interface.

Types and Abstractions

Types and Classes

Java has 8 primitive types: int, boolean, double, float, byte, char, long, short.

  • What distinguishes a type in Java? In OO? A type is a set of externally visible (public) characteristics.
  • Is Java strongly or weakly typed?
  • What is the benefit of strong typing? The disadvantage?

Abstractions

Goals for abstractions:

  • clearly map to concepts in the problem domain (to facilitate understanding)
  • be well-encapsulated

Why we care: control complexity, isolate distinct computations, divide and conquer.

  • What programming idiom violates abstraction? (Goto and globals)
  • Leaky abstractions: how we store a Stack ADT might matter under high demand.

Problem Abstraction

What are important attributes of a bookstore inventory system?

  • Hardcover / paperback / formats
  • Fiction / non-fiction
  • Customer sales and payment processing
  • Staff management

Approaches: nouns and verbs in object brainstorming; single responsibility (one reason to change).

Worked Example: Playing Cards

Representing a Card

How can we represent a playing card? What should the card do?

  • “the 10 of Hearts”
  • For each Java version, ask: what is the abstraction?

Card1 – Card3

  • Card1: neither encapsulated nor a good abstraction. Don’t shoehorn domain concepts into int/String (Primitive Obsession ☠)
  • Card2: slightly better (can’t directly mutate) but representation is tightly coupled to implementation; easy to corrupt
  • Card3: information hiding; uses suits and ranks to capture the problem space

Object Diagrams

object diagram

  • Snapshot of runtime execution
  • An abstraction of the real thing (“all models are wrong, but some are useful”)
  • Video 2-4: how to create an object diagram in JetUML.

Scope and References

Scope

scope

  • Global, object, local scope
  • References and mutability
  • Always define variables in the tightest scope possible.

Scope Problems (escaping references)

  1. There is no door: a global-scope variable escapes by default.
  2. The front door is open: an accessor returns a reference to an instance variable — copy before returning.
  3. The door was not closed: an instance variable is assigned from a parameter — the caller keeps a reference.
  4. The back door is open: a reference is stored in an externally reachable object — copy, or redesign to avoid it.

Immutability and Contracts

Immutability

  • Generally a good design approach — why?
  • “Leaking” references is not a problem when the reference is to an immutable object (e.g. String).
  • Video 2-3: immutability and internals — returning a copy; escaping references.

Design by Contract

  • addPlayer: pre- and post-conditions — why?
  • The public keyword is a promise to external callers — other objects, other packages, or unknown library clients.
  • Becomes more important as systems spread across companies and people.

Encapsulation Principles

  • Make all fields private.
  • Don’t reflexively add a getter/setter for every field.
  • Avoid methods that both mutate state and return a value.
  • Make instance variables final whenever possible.
  • Make classes immutable whenever possible.
  • Ensure accessors don’t return a reference to a mutable instance variable.

In-Class Activities

Day 1

  • Walk through Gradle.
  • What is a “good design”, and when does design matter?
  • Software Design Decoded principles: for each, give a thumbs-up if you have personally experienced it in action (need not be software-related).

Day 2

Day 3

  • Meet your team / 1-1 sessions.