Design By Contract Vs. Defensive Programming

The same kinds of protocol assertions are used by Programming by Contract and Defensive Programming to document software contracts.

The critical distinction is that neither side trusts the other in defensive programming. 

Still, in programming by contract, both the customer and the supplier believe that the other will keep their half of the bargain.

In this article, please find out more about Design by Contract and Defensive programming, their differences, examples, and much more!

What is Design By Contract in Programming?

Design by Contract is a process that depends on creating a straightforward interface for each component. It is mainly used for developing software.

The term “Design by Contract” is often used to describe a native or third-party method within some programming languages that necessitates the implicit coding of the contracts within a program, even though it can be perceived as an abstract development style incorporated through documentary evidence or modeling. 

The purpose of using Design by Contract is to create programs that are created and, eventually, programmed in a way that eliminates more minor mistakes. 

In contrast, the accompanying language’s enforcement of the contracts makes any remaining faults simple to find and capture.

Because the contracts for functions and classes are well defined, programs that use them may be more modularly designed with individual courses that are simple to reuse in other applications.

Bertrand Meyer created DBC as a component of the Eiffel programming language. As a result, DBC is a valuable design method for any programming language, including Java, regardless of where it originated.

The idea of an assertion, a Boolean expression regarding the state of a software system, is fundamental to DBC. 

We analyze the assertions at runtime at particular checkpoints throughout the system’s operation. Finally, all arguments are considered true in a working software system. 

In other words, we consider the software system flawed or broken if any assertion evaluates to false.

The main idea of DBC is related to the #assert macro used in C and C++ programming. DBC, however, goes a million levels beyond its claims.

We can distinguish three types of expressions in DBC: Preconditions, Postconditions, and Invariants.

What Is Defensive Programming Design?

Defensive programming is writing computer code that aims to stabilize and improve a product by preventing potential problems. 

The fundamental concept behind this strategy is to develop software that can continue to function normally even when unexpected processes or user-made entries are present. 

Defensive programming frequently relies on a seemingly contradictory mix of removing extraneous code while ensuring enough is written to handle all potential user activities. 

This procedure also requires extensive testing and easily auditable and checkable software development.

Defensive programming shares many similarities with defensive driving in that issues are anticipated before they emerge. 

Making code designed to handle any situation that could be presented to it is one popular way to do this. 

Programmers frequently experiment with software that may be outside of the anticipated parameters or try to predict how users will provide information. 

The foundation for the usage of defensive programming is the code itself, which is written to be able to accept unusual input without crashing or running into an error event.

What is Defensive Programming Example?

Code employed in space exploration missions is one example of defensive programming.

Once created, that code is launched into space. That’s lost labor costing billions of dollars if it fails.

You must take drastic actions for such a type of code. No matter what, the code must execute appropriately without crashing.

This software differs significantly from most others. 

Bugs don’t usually pose a significant issue with the common application. 

Even if your application has bugs, it could still be helpful. 

The worst-case scenario is that an issue can be manually repaired by contacting customer support. 

The software can be crashed and restarted if it becomes useless. 

If it’s back-end software, it’s presumably operating on several servers. 

If it’s a client, the user can manually restart the application. The server code can be updated in the worst-case scenario. Even physically visiting a server and continuing it manually is an option.

But you can’t do it with specific essential software. The program must function properly at all times.

People’s imperfections are the problem. Not to add that the software has no control over other potential issues (such as operating system errors). As a result, the software might not succeed.

However, with specific applications, that is not an option.

You must thus take all reasonable steps to avoid failure.

The Difference Between Design By Contract & Defensive Programming

Defensive programming and design by contract are in some ways in opposition to one another since, with DBC, you set the agreements between collaborators and build your programs on the premise that they will be upheld. 

When programming defensively, you assume that your colleagues will break their agreements.

A real square root procedure designed in the DBC style would explicitly indicate in its contract that negative numbers are not permitted to be passed in and then just presume that it would never come across a negative value. 

A defensively constructed square root method would presume a negative value has been provided to it and perform the necessary safety measures.

Why is Design By Contract Not Popular?

The fundamental issue with DBC is that it is frequently impossible to specify the contract formally (at least not efficiently) or to validate it using a static analysis tool. 

DBC won’t offer the level of confidence consumers require until we go past this stage for common languages (not Eiffel).

In test-driven development (TDD), humans generate tests based on the method’s present natural-text requirements, which are (ideally) well-documented. 

So, by creating the test, a human may understand accuracy and receive some confidence based on that interpretation.

It states that the documentation should spell out a contract adequate to provide a test plan for producing JavaDocs. 

But, all in all, design by contract and TDD need not necessarily be mutually incompatible.