Master the Maximum‑Minimum Principle to Simplify Software Design and Naturally Satisfy SOLID

There are no shortcuts; every concept and technology must be deeply understood through extensive practice, and others' opinions are not always correct.

Many people constantly cite the six design‑pattern principles, but the author finds them superficial and sometimes contradictory.

The author proposes a single guiding rule called the Maximum‑Minimum Principle :

Any interface or program segment has inputs and outputs. Inputs come with constraints (e.g., type, range), and outputs carry guarantees (e.g., length, format). When chaining modules, the output guarantee of the upstream component must fully satisfy the input constraints of the downstream component.

To achieve stable design under fixed resources, modules and interfaces should be defined so that each interface’s output guarantee is maximized while its input constraints are minimized.

The three requirements—resource limitation, maximal output guarantee, minimal input constraint—are mutually conflicting, so they are prioritized as follows: resources first, then output guarantee, then input constraint.

Typical improvement steps:

Identify and shift constraints/guarantees between adjacent modules to simplify implementation; remove interfaces that merely transform data without adding value.

Merge duplicate functionality into a single interface to reduce complexity.

Split interfaces that produce inconsistent output types into multiple interfaces with uniform guarantees.

Eliminate unnecessary input constraints that do not significantly increase implementation difficulty.

When these steps are correctly applied, the following outcomes are achieved:

Every functionality is implemented exactly once and is necessary.

Each interface produces a single, strongly guaranteed result, fulfilling the Single‑Responsibility Principle.

Interfaces impose minimal input constraints, allowing subclasses to replace superclasses (Liskov Substitution Principle).

Minimal constraints mean interfaces depend only on essential information, naturally satisfying Dependency Inversion.

Interface Segregation and the Law of Demeter emerge as side effects.

When an interface provides maximal guarantee with minimal constraint, its implementation becomes closed to modification, while other business logic can extend by inserting new modules before it, illustrating the Open‑Closed Principle.

Thus, adhering to the Maximum‑Minimum Principle makes the other SOLID principles automatically satisfied.

A common mistake is designing downstream input constraints to mirror upstream output guarantees, propagating constraints through the system and preventing future extensions.

Under this principle, requirement changes fall into three categories: (1) modify the program handling a completely changed input type; (2) add a parallel path for special cases of an existing input type; (3) introduce a new path for entirely new inputs, reusing existing interfaces when possible.

True refactoring only makes sense when adopting new technologies (e.g., a new language or framework).

The author also reflects on type systems, viewing types as a subset of constraints that can be overly restrictive; duck‑typed languages reduce unnecessary constraints, offering a purer programming experience.