Some things about contractual programming

Contractual programming is a programming method. So what is contractual programming? I think this concept has evolved from contract. In human social activities, a contract is generally used by two parties, one party (supplier) for the other party (customer) to complete some tasks. Each party expects to gain benefits from the contract and accept some obligations. Generally, one party is deemed as a right to the other. The contractual documents should clearly state the rights and obligations of both parties.

Contractual programming is a programming method. So what is contractual programming? I think this concept has evolved from contract.

In human social activities, a contract is generally used by two parties, one party (supplier) for the other party (customer) to complete some tasks. Each party expects to gain benefits from the contract and accept some obligations. Generally, one party is deemed as a right to the other. The contractual documents should clearly state the rights and obligations of both parties.

The contract can protect the interests of both parties. for the customer, the contract specifies the work to be done by the supplier. for the supplier, the contract indicates that if the agreed conditions are not met, the supplier is not obligated to complete the required tasks.

The same principle applies to software. Imagine a software unit E. To fulfill its purpose (to fulfill the contract), E may use a series of sub-tasks, t1,... tn. If the subtask ti is not that simple, it needs to call another function routine (routine) R. In other words, E transfers sub-tasks to R. In this case, a well-defined "Registration Form" (roster) should be used to manage the obligations and rights of both parties-contracts.

If ti is a task, you need to insert a given element into a dictionary of limited capacity. The dictionary is a (name-value) table. each element (value) is accessed by a string (name) as a keyword. (Note: "elements" can be understood as any data item ).

In short, the function caller should ensure that the input function parameters meet the function requirements. if the input function does not meet the function requirements, the function will refuse to continue execution. If code is written according to the contractual programming idea, we need to check the function parameters when writing the function. Sometimes it is easy to judge whether a parameter cannot be null, or the value cannot be less than 0. If contractual programming is fully applied in the project, there should be a "contract framework" to help us do these things.

A contract is similar to a commercial contract. it has the following features:

1. Both parties in the contract relationship are equal and jointly liable for the smooth conduct of the entire bussiness. no party can only have rights and no obligations.
2. Contractual relationships are often mutual, and rights and obligations are often bound together;
3. The obligation to execute the contract lies with me, and the power to verify the contract lies with the person;
4. My obligations protect your interests, and your obligations protect my interests;

The introduction of contractual relationships to the software development field, especially after the object-oriented field, has brought us several major conceptual impacts:

In general, in software systems, libraries and component libraries are analogous to servers, while programs using libraries and component libraries are considered as clients. Based on this C/S relationship, we often impose strict requirements on the quality of library programs and components, forcing them to assume the responsibilities they should not bear, and over-indulge the client, it even requires the library program to handle the dilemmas caused by client errors. Objectively, the design and compilation of libraries and component libraries are difficult, and there are more hidden quality risks. at the same time, the client-side code is mostly loose and the quality is inferior. In this situation, it is like in an enterprise with unclear rights and responsibilities, it is bound to have a group of zombie meals mixed up, a group of hard-working, regardless of the gains and losses of the old scalpers. After the concept of contract is introduced, the C/S relationship is broken and everyone is equal. if you need to provide services correctly, you must meet the conditions I have proposed, otherwise, I do not have the obligation to "eliminate all difficulties" to complete the task.

It is generally considered that checking and reporting errors in the module is the obligation of the module itself. In the contract system, the inspection of the contract is not an obligation, but is actually fulfilling the right. One obligation and one right have a great difference. For example, the above code:

if (dest == NULL) { ... }

This is an obligation. The key point is that once the conditions are not met, we (the obligated party) must handle this embarrassing situation in an appropriate way, return an error value, or throw an exception. And:

assert(dest != NULL);

This is to check the contract and fulfill the right. If the conditions are not met, I will immediately "tear up the contract" if the error occurs to the other party rather than me. This will undoubtedly greatly simplify the development of libraries and component libraries.

The contract verifies the condition that must be met to ensure correctness. Therefore, when the contract is damaged, only one thing is shown: there are bugs in the software system. It means that some conditions must be "true" when they arrive at me ". Who will make sure? It should be ensured by other modules in the system in advance. If I find that the contract has not been observed, it indicates that other modules in the system have not correctly fulfilled their obligations. Take the example of "open FILE" mentioned above as an example. if a module requires a FILE *, and the contract Check finds that the pointer is NULL, this means that a module does not fulfill its obligations, that is, "check whether the file exists, ensure that the file is opened in the correct mode, and ensure the correctness of the pointer ". Therefore, when the contract check fails, we first need to know that this means that the programmer is wrong, and what we need to do is not to correct the contract reviewer, but to correct the contract provider. In other words, when you find that:

assert(dest != NULL);

When an error is reported, you do not modify your string_copy function, but make sure that the dest pointer is not empty when any code calls string_copy.

Our previous understanding of "process" or "function" is that the process of completing a computing task only emphasizes its goal and does not emphasize its conditions. With this understanding, our understanding of exception is very vague and broad: as long as the computation process cannot be completed, it can be considered as an exception, whether it is my own reason, it is also the reason for others (the typical rights and responsibilities are unclear ). It is precisely because of this fuzzy and broad nature that "When should an exception be thrown?" is a question that no one can answer. After the contract is introduced, the "process" and "function" are defined as the process of completing the contract. Contract-based interoperability. if the contract fails because other modules fail to perform the contract, this process only needs to be reported and no response is needed. The real exception is that "the other party fully satisfies the contract, and I still cannot complete the task as planned. In this way, we have made a clear and feasible definition for "exceptions.

In general, in object-oriented technology, we think "interfaces" are the only important thing. interfaces define components and interfaces determine the system, interfaces are the only thing we need to care about in object-oriented systems. interfaces are not only necessary, but also adequate. However, the concept of contract reminds us that there are not enough interfaces, but the interface alone is not enough to convey enough information. to use interfaces correctly, we must consider the contract. Only by considering the contract can we achieve the goal of object-oriented: reliability, scalability and reusability. In turn, "reusing without a contract is nothing more than making a fuss. (Bertrand Meyer )".

From the above point of view, we can see that although the Design By Contract proposed By Eifel is just a systematic assertion mechanism, it is indeed a complete ideological innovation behind it. "I think the direction of Bertrand Meyer-Design by Contract-is the right direction, and we will all move forward along his path," Ivar Jacob told programmers during his visit to China. I believe that large manufacturers (Microsoft, IBM, and of course Rational) will not ignore the achievements of Bertrand Meyer. All these vendors will take actions in this direction ."

This article is available at http://www.nowamagic.net/librarys/veda/detail/395.