Published Sep 3, 2019

Episode 51: Design By Contract

Explore the transformative programming paradigm of Design by Contract with Arno Schaefer and Michael Stal as they delve into its core concepts, emphasizing the power of preconditions and postconditions in ensuring method reliability, and discuss its practical applications, benefits, and limitations in maintaining robust software systems.
Episode Highlights
Software Engineering Radio - the podcast for professional software developers logo

Popular Clips

Episode Highlights

  • Tool Support

    The discussion on tool support for Design by Contract highlights its challenges and benefits. explains that without proper tools, maintaining contracts across inheritance hierarchies becomes cumbersome, as assertions need to be manually synchronized between supertypes and subtypes 1. He notes that while tools exist for languages like Java and C, they often require additional setup and can impact the development environment 2.

    Contracts and subtypes may provide better than that, but definitely not worse. This is actually quite important.

    ---

    Despite these challenges, explicit contract annotations can help developers detect interface changes even when method signatures remain the same 1.

       

    Pre/Postconditions

    Preconditions and postconditions play a crucial role in enhancing software reliability and documentation. emphasizes that exceptions must be part of the contract, treating them as special return values to ensure robust error handling 3. He argues that preconditions act as a hard barrier, ensuring that any unmet precondition is treated as a bug, while postconditions allow for valid exception handling 3.

    If you use design by contract and a caller does not meet a precondition, it's okay for the system to crash, basically.

    ---

    This approach ensures that contracts remain a valuable tool during both development and production, helping to identify bugs early and maintain system stability 4.

       

    Design Limits

    Design by Contract faces limitations, particularly in user interfaces and stateless objects. points out that specifying preconditions and postconditions for UI elements can be impractical, as there's often no way to verify if a UI action occurred 5. adds that while contracts can operate on parameters and visible state, they cannot reference internal state, limiting their applicability in certain contexts 6.

    It's hard to specify a precondition. Well, this button appeared, or this button now looks expressed, or things like that.

    ---

    Despite these challenges, Design by Contract provides a formal specification that keeps documentation up-to-date and reliable, offering significant benefits when used appropriately 6.

Related Episodes