Modularity

Software Engineering / 11 Sep 2026 / 8 min read

Common Closure Principle: Group Code That Changes Together

Common Closure Principle: Group Code That Changes Together A codebase can have tidy classes and still make routine changes expensive. A new pricing rule might require edits in a controller module, a generic utilities package, a shared validation package, and a reporting package. Each edit is small, but one business decision now crosses several boundaries. The Common Closure Principle offers a practical way to judge those boundaries: code that tends to change for the same reason should tend to live in the same component. A component can be a package, module, library, or another unit that a team changes and releases together.

Software Engineering Software Design

Software Engineering / 10 Sep 2026 / 9 min read

Information Hiding: Designing Modules Around Change

Information Hiding: Designing Modules Around Change A module can have a small API and still be difficult to change. The problem appears when callers know details they shouldn’t need to know: which storage format is used, how identifiers are assembled, which retry sequence is required, or what intermediate states exist inside a workflow. Once that knowledge escapes, an internal change becomes a coordinated change across the codebase. Information hiding is a design principle for preventing that spread. A module hides a design decision by giving other code a stable way to use the capability without depending on the decision itself. This article develops a practical way to recognize leaked decisions, choose useful module boundaries, and avoid interfaces that merely disguise the implementation.

Software Engineering Software Design

Software Engineering / 10 Sep 2026 / 9 min read

Information Hiding: Design Modules Around Change

Information Hiding: Design Modules Around Change A module can have private fields and still expose nearly every design decision it makes. If callers know which storage keys exist, how records are ordered, which retry sequence is used, or how an identifier is encoded, changing those decisions means changing the callers too. Information hiding is the design practice of keeping such decisions behind a boundary. The goal isn’t secrecy. The goal is to make a decision replaceable without forcing unrelated code to understand or change with it.

Software Engineering Software Design

Software Engineering / 09 Sep 2026 / 8 min read

Information Hiding: Design Modules Around Decisions

A module can have a tidy directory, a small public API, and still be difficult to change. The problem often appears when callers know details that should have remained private: how an identifier is formatted, which algorithm selects a price, or which fields must be updated together. When those details change, callers change with them. Information hiding is a design principle for reducing that coupling. The idea is simple: identify a design decision that may change, place it behind a module boundary, and expose the capability callers need rather than the decision’s internal details.

Software Engineering Modularity

Software Engineering / 08 Sep 2026 / 9 min read

Information Hiding as a Design Tool

A module can have private fields and still expose too much. Callers may know which storage format it uses, which sequence of operations is required, or which implementation rule determines a result. When that hidden-looking detail changes, code outside the module must change with it. Information hiding is a design principle for preventing that spread. The idea is simple: identify a design decision that other code should not need to know, then place that decision behind a boundary whose public contract can remain stable when the decision changes.

Software Engineering Software Design

Software Engineering / 06 Sep 2026 / 9 min read

Designing Modules with Information Hiding

A module can have private fields and still expose too much of its design. Callers may know how its data is stored, which steps must happen in which order, or which third-party concepts sit underneath it. When one of those decisions changes, code outside the module must change too. Information hiding is the practice of placing a design decision behind a boundary so other code depends on what the module provides, not on how it provides it. The goal is not secrecy. The goal is to contain the cost of change.

Software Engineering Software Design

Software Engineering / 05 Sep 2026 / 10 min read

Ports and Adapters for Testable Application Boundaries

A business rule often begins as a few lines of code and gradually becomes entangled with everything around it. A pricing decision reads directly from a database. An order workflow calls a payment SDK from the middle of its logic. Tests need a web server, network access, and several configuration files just to exercise one decision. The problem is not that databases, frameworks, or SDKs are bad. The problem is that application decisions have become dependent on details that change for different reasons.

Software Engineering Architecture

Software Engineering / 05 Sep 2026 / 8 min read

Designing Modules Around Information Hiding

A module can have a small public API and still be difficult to change. The problem appears when callers must know details that supposedly belong inside the module: a storage layout, a retry rule, a naming convention, a calculation step, or the order in which internal operations happen. When those details change, callers change too. The boundary exists in the code, but it does not contain the knowledge that creates maintenance work.

Software Engineering Software Design

Software Engineering / 03 Sep 2026 / 9 min read

Hide Design Decisions Behind Stable Interfaces

A module can have a small public API and still be difficult to change. The problem appears when callers know details they do not actually need: a file layout, a cache key format, a third-party response shape, a particular algorithm, or the order of internal steps. Once those details escape, changing an implementation becomes a multi-module change. Code that should have been independent must now move together. Information hiding is a design principle for preventing that spread. The idea is simple: identify decisions that are likely to change, keep those decisions inside one boundary, and expose an interface based on what callers need rather than how the work is currently done.

Software Engineering Software Design

Software Engineering / 03 Sep 2026 / 9 min read

Designing Modules Around Cohesion and Coupling

A codebase can be split into many files and still be difficult to change. A small feature may require edits in several modules, tests may need large fixtures, and one internal change may unexpectedly break distant code. The problem is often not the number of modules. It is where their boundaries are drawn. Two ideas are especially useful when evaluating those boundaries: cohesion and coupling. Cohesion asks whether the responsibilities inside a module belong together. Coupling asks how much one module depends on the details of another. Used together, they provide a practical way to decide where code should live and which dependencies deserve attention.

Software Engineering Software Design

Software Engineering / 03 Sep 2026 / 12 min read

Designing for Localized Change

A small requirement can produce a surprisingly large code change. Suppose a product changes the rule for displaying customer names. The new rule sounds simple: show the preferred name when one exists, otherwise show the legal name. Yet implementing it requires edits in an API response mapper, an email formatter, an audit message, a report generator, and three tests that each reconstruct the same choice. The problem is not that five files changed. Some changes legitimately cross many files. The warning sign is that one decision had to be rediscovered and edited in several places.

Software Engineering Software Design