Idempotent Design

Problem: You have an operation that needs to be carried out (e.g., on a database, a configuration file, etc.)

Context: The operation is one of a series that will be carried out. Or: The operation may be carried out incorrectly the first time, and may need to be fixed and re-done (e.g., installation in TestEnvironments that may uncover defects).

Solution: Design the operation to be idempotent; that is, if it's carried out more than once, it's as if it was carried out just once.

(You may remember from math courses that an idempotent function f is one where, for all values of x, f(f(x))=f(x). (For example, the function that returns the absolute value of a number is idempotent.)

Resulting context of AntiPattern: "Sorry, once that's been done, we have to do all this stuff before we can do it again." (*sigh*)

Related patterns: Most (all?) FunctionalProgramming is idempotent, but not all idempotent design is functional.

-- PaulChisholm

I think that's a bit ambiguous. Are you talking about f(x) followed by f(x), in which the second function call must evaluate to the same as the first in a functional language, or are you talking about f(f(x))? There's no reason why the latter should be true for arbitrary f, even in functional languages. --JasonGrossman


Definitions:


I have a question: DoesBeingStatelessImplyBeingIdempotent?

Please add your comments to IdempotentDesign.


EditText of this page (last edited July 21, 2005) or FindPage with title or text search