liveBook · Manning

Implementation detail

As explained in 100 C++ Mistakes and How to Avoid Them

An implementation detail is an internal representation or mechanism of a component that is not part of its intended external contract.

Treat internal state and representation as implementation details, not as a client-facing contract. Nonessential accessors can expose private variables, increase cognitive load, and let client code depend on choices that may later change. section 8.2

Mistake: storing and exposing a derived value

A Circle stores both radius and area, initializes area in its constructors, and exposes getArea(). Clients can now depend on the stored representation. A safer design stores only radius and computes the area in getArea(), preserving the class invariant while allowing the representation to change. section 8.2

How 100 C++ Mistakes and How to Avoid Them covers it

How deep it goes
Explains accessor-driven exposure, derived state, class invariants, and a computing replacement, but does not develop broader redesign techniques.
Examples
Uses a Circle whose stored area is replaced by an accessor that computes area from radius.
What it assumes
Assumes familiarity with classes, private variables, constructors, accessors, mutators, and client code.
What you can do after
Evaluate whether an accessor exposes representation unnecessarily and replace derived stored state with a meaningful computation.
How it connects
Connects implementation details with encapsulation, class invariants, accessors, mutators, client code, and derived state.

Also explained in

Compare how 3 books explain implementation detail →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of 100 C++ Mistakes and How to Avoid Them. The section links point to the parts of the book it draws on.