Controlled Boundary Breaking

Starter: think before typing

Before running this pragmatic design choices example, find the line where the main idea becomes active. Write a prediction: what must already be true for that line to work, and what should be different after it runs? The checked run ends with `AUDIT: Created portfolio artefact`; predict how the focus line helps produce that evidence.

Learning Objectives

• Explain why object boundaries exist.
• Recognise when direct access would make code fragile.
• Use package-private access or helper methods deliberately.
• Justify a boundary exception in writing.

Learning Outcomes

• By the end of the lesson, you can explain why object boundaries exist.
• By the end of the lesson, you can recognise when direct access would make code fragile.
• By the end of the lesson, you can use package-private access or helper methods deliberately.
• By the end of the lesson, you can justify a boundary exception in writing.

Why this idea exists

Boundaries exist to protect meaning: private state, module edges and object responsibilities stop unrelated code from reaching in and changing details it should not own.

Controlled boundary breaking exists because real software sometimes needs carefully limited exceptions for testing, performance, migration, package-level collaboration or framework integration.

This topic fits the arc by adding professional judgement to earlier rules. A boundary exception is not a shortcut; it is a documented trade-off that should make the maintenance cost visible.

Deep dive

Lesson visual

Type this and run it

Create ControlledBoundaryBreakingDemo.java, type the program, and run it before changing anything. This section is about reproducing the checked baseline.

public class ControlledBoundaryBreakingDemo {
  public static void main(String[] args) {
    AuditLog.record("Created portfolio artefact");
  }
}

class AuditLog {
  static void record(String message) {
    System.out.println("AUDIT: " + message);
  }
}

Build and run it with:

javac ControlledBoundaryBreakingDemo.java && java ControlledBoundaryBreakingDemo

Expected baseline: AUDIT: Created portfolio artefact

Line-by-line explanation

Read the code as a sequence of responsibilities. The focus line for this lesson is AuditLog.record("Created portfolio artefact");; the surrounding lines prepare it, use its result or make the behaviour observable.

Worked example

Trace the program

Common misconception

A common mistake in controlled boundary breaking is treating the example as a finished answer. For pragmatic design choices, the important question is narrower: which operation carries the idea, what does it make possible, and what would break if you changed it carelessly?

Quick checks

How to study this lesson

For Controlled Boundary Breaking, predict how pragmatic design choices changes the run before you press Run.

Use the first portfolio task as your main edit: Find one place where exposing state would be tempting.

Use the second task as your variation: Design a method that preserves the boundary.

Finish with evidence, not a diary entry: Write when you would accept a controlled exception.

Portfolio Practice

1. Find one place where exposing state would be tempting.
2. Design a method that preserves the boundary.
3. Write when you would accept a controlled exception.

Final self-check

Study route

Practise pragmatic design choices by predicting the Java example, typing it, running it in the browser, tracing the result and saving portfolio evidence.

Next, move into Polymorphism: Cost and Benefit and carry forward one improvement from this lesson into the next program.