Difference between revisions of "Design by contract"
Karl Jones (Talk | contribs) (First) |
Karl Jones (Talk | contribs) (etc) |
||
| Line 1: | Line 1: | ||
| − | '''Design by contract''' ('''DbC'''), also known as '''contract programming''', ''programming by contract'' and ''design-by-contract programming'', is an approach for designing software. | + | '''Design by contract''' ('''DbC'''), also known as '''contract programming''', ''programming by contract'' and ''design-by-contract programming'', is an approach for designing [[software]]. |
| − | It prescribes that software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, postconditions and invariants. | + | It prescribes that software designers should define formal, precise and verifiable interface specifications for [[Component-based_software_engineering|software components]], which extend the ordinary definition of [[Abstract data type|abstract data types]] with preconditions, postconditions and invariants. |
These specifications are referred to as "contracts", in accordance with a conceptual metaphor with the conditions and obligations of business contracts. | These specifications are referred to as "contracts", in accordance with a conceptual metaphor with the conditions and obligations of business contracts. | ||
Revision as of 10:15, 1 June 2015
Design by contract (DbC), also known as contract programming, programming by contract and design-by-contract programming, is an approach for designing software.
It prescribes that software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, postconditions and invariants.
These specifications are referred to as "contracts", in accordance with a conceptual metaphor with the conditions and obligations of business contracts.
The DbC approach assumes all client components that invoke an operation on a server component will meet the preconditions specified as required for that operation.
Where this assumption is considered too risky (as in multi-channel client-server or distributed computing) the opposite "defensive design" approach is taken, meaning that a server component tests (before or while processing a client's request) that all relevant preconditions hold true, and replies with a suitable error message if not.
External links
- Design by contract @ Wikipedia
