Interface concepts should be atomic

In both design and programming, interfaces and interactions are presented by way of simple communication. In design, this communication is often visuo-spatial. In programming, this is often textual, perhaps combinations of keywords. The communication necessary to presenting interfaces seeks to encapsulate “concepts” which, when understood by a user, can be used to establish an implicit contract which binds the interface (and its underlying system) to expectations of usage, behavior, and function.

These “concepts” must be effective at creating agreement between the expectations of a user/viewer and the realities of the system. Often, these concepts are taken directly from the world of the user, as in the case of programming concepts like the “Builder pattern”, which uses methods to “build” an object step-by-step. The concept in play is “builder”, which evokes images of a building being constructed. The building is constructed from bottom to top, step-by-step, so the user of a program employing the “Builder pattern” will expect the program to allow for building an object in place by progressively applying methods.

A given concept must be understandable and, therefore, relatively terse. Metaphors often lose their “punch” as they gain complexity.

Sometimes, there’s a temptation to add many responsibilities to a concept. This can often happen in programming when some module of business logic attempts to do too many things. The illusion of simplicity is keeping one module to do all of these things, and the excuse is that we’ll find a way to “do them flexibly”.

True simplicity is splitting all of those things into separate modules. Single responsibility principle: separate concerns into separate modules.

So, don’t overload concepts. Favor many atomic concepts over one overloaded concept.^[1] This helps to ensure that interfaces establish strong and clear contracts.