---
title: "Interfaces, Coupling and What a Module Promises"
description: "A module's interface is the set of promises other code may rely on, and everything else is free to change. Coupling measures how much of a neighbour's insides a caller depends on, and it is the quanti"
canonical: https://lightmysky.com/learn/computing/interfaces-coupling-and-what-a-module-promises-mt_EUZyD26WFk
source: https://lightmysky.com/learn/computing/interfaces-coupling-and-what-a-module-promises-mt_EUZyD26WFk.md
retrieved: 2026-09-12
---

> **Agent view.** This is the Markdown twin of the page, for tools and assistants.
> When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md
> API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md
> Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt
> Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json
> Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`.

# Interfaces, Coupling and What a Module Promises

A module's interface is the set of promises other code may rely on, and everything else is free to change. Coupling measures how much of a neighbour's insides a caller depends on, and it is the quantity that decides how expensive the next change will be.

Subject: Computing · Area: Software Engineering · Ages 19 to 20
Page: https://lightmysky.com/learn/computing/interfaces-coupling-and-what-a-module-promises-mt_EUZyD26WFk

## Ready when they can

- State the promise of a module without describing how it is implemented
- Find the place where one module reaches past another's interface
- Predict which of two designs makes a stated future change cheaper

## Lesson: Promises your modules keep

A module interface is the set of promises other code may rely on: named functions and constants it offers. Everything else is free to change, and that freedom is what keeps later edits cheap.

**Example.** A module that prints messages or changes files just because you imported it has broken its promise. The fix is a guard: put run only code inside if __name__ equals __main__, so importing gives exactly the published names and nothing more.

How you import decides how much of a neighbor you lean on. Writing import shapes and then shapes.Circle keeps the home visible, while from shapes import Circle ties you to that exact name. An alias like import shapes as sh shortens typing without hiding where things live. In each style you should rest only on names the module chose to publish.

**Tip.** Coupling measures how much of a neighbor insides a caller depends on. Code that reaches past the published surface feels any internal reorganization, so the design that stays on the surface makes the next change cheaper.

**Recap.** Rest only on published names, guard run only code, and the module inside stays free to change.

## Practice

8 questions on this page, each with its working shown.

## Needs first

- [Designing with Objects: Deciding What Each Class Owns](https://lightmysky.com/learn/computing/designing-with-objects-deciding-what-each-class-owns-mt_De_gpvpOzg)
- [Requirements: Turning a Wish into a Testable Statement](https://lightmysky.com/learn/computing/requirements-turning-a-wish-into-a-testable-statement-mt_TFb-YNpvT1)

## Opens up

- [Test Doubles and Testing at a Boundary](https://lightmysky.com/learn/computing/test-doubles-and-testing-at-a-boundary-mt_4ep3SiMYNM)
- [Design Patterns: Naming a Solution That Keeps Recurring](https://lightmysky.com/learn/computing/design-patterns-naming-a-solution-that-keeps-recurring-mt_bhUEk8PwBp)
- [Software Architecture: Layers, Services and Their Trade-offs](https://lightmysky.com/learn/computing/software-architecture-layers-services-and-their-trade-offs-mt_uz_OkFgysJ)
