Contract design. Is it for reuse or software correctness?

Question

Software design

The Beginning
Now I am rediscovering OOP. If I used to look through the prism of a specific programming language, now I understand where OOP came from, the concepts of abstraction, encapsulation, inheritance; what is it for and is it possible to do without it.
I got to the concepts of abstract class and interface. If you type in the search engine “what abstract classes are for” or “what interfaces are for”, then it will return posts with approximately the following justification for their use: “sometimes you need it for work”, “it can come in handy if”. It is perceived as something optional.
Why they are needed in OOP in principle (in the broad sense), and not in a specific programming language, I did not understand.
So I turned to books.
middle
I read several books in parallel, but I will mention the following:
1. "Object-oriented thinking" by M. Weisfeld
2. "Object-oriented analysis and design with application examples" by G. Buch
3. "Pragmatic programmer. The path from apprentice to master" E. Hunt, D. Thomas Let's
take Weisfeld. We find a mention of what abstract classes and interfaces are for at the beginning of Chapter 8.

Interfaces, protocols, and abstract classes are powerful
code reuse mechanisms that provide the foundation for what I call
the concept of contracts .

That is, roughly speaking, interfaces and abstract classes provide software "reusabiity".
I remembered that the combination "contract model" I had already met with Booch:


When reading, it seems that the contract model has a more global meaning. Almost the basics.
Thoughts began to appear in my mind that perhaps abstract classes and interfaces describe what an object should do, that they are part of that same contract. This is the embodiment of the idea of ​​object responsibility/duty in programming languages.
To verify this, I turned to the original source - to the books of Bertrand Meyer, which describes the technology of "design by contract". At first glance, judging by the definition, everything converged:

Design by Contract - the establishment of a relationship between a class and its clients in the form of a formal agreement that unambiguously establishes the rights and obligations of the parties.

But the more I read, the more I became convinced that Weisfeld and Butch interpret the concept of a contract too loosely, or they mean some kind of "contract" of their own.
While Weisfeld's concept of contracts ensures software reuse,
Hunt and Thomas have it as an error-proofing tool:

Meyer has it as a tool for building reliable software:

In addition, the definition of invariant, postconditions, and preconditions in Meyer and other authors are strikingly different.
The End
Many questions arise.
Can Meyer be considered the forerunner of the idea that a class is a contract consisting of an interface and an implementation?
Is design by contract the foundation of the basics or is it just one of the approaches to software development?
Is there a free interpretation of the concepts of contract, precondition, postcondition, invariant?
Is it possible, for example, to consider that preconditions are the very interfaces that must be implemented in order for the program to run?

Answer 1

Read the book "Clean Architecture" (R. Martin), everything will fall into place.
Contract - cannot be an implementation, it is an abstraction. It is used when it is planned to change the implementation (specifics) of the contract as the system is operated, usually in long-term projects.
An abstract class is a parent class that gives its ancestors something in common + the need to implement their contract, but it refers to the specifics, not the contract.

Answer 2

When you make software, you make code that interacts with other code.
Any function, procedure, each line is a code that interacts with other code above or below in the text. The interaction of one code with another code is always carried out through a certain interface - a set of entry / exit rules and expectations in the behavior of the code. Even when you declare a variable in the local scope, this is also an interface to the code that uses that variable. Other code expects the variable to exist, have the correct value, and can be used in the correct way. Each time these code coexistence rules are different, they change from language to language and developer to developer.
The best language (my opinion) is the language that is suitable for describing interaction interfaces in the broadest sense of the word. I'm talking about an interface as some contract of one code to another, one line of code to the next, one statement to others.
Of course, there are different approaches to describe such interfaces. Now the principle of descriptive "do as I say" is widespread. In this approach, the program is divided into simple entities that somehow interact with each other.
In OOP, these are object classes; in functional, these are functions.
The essence changes really weakly, all this is necessary in order to:
1. formalize the description of interaction interfaces.
2. Come to some uniform way of such a description.
In OOP, they go further, abstracting from the specific implementation of the class, and introducing only the ways in which entities interact (the description of this interaction). That. abstract classes and interfaces appear.
In the functional way, the descriptions also went towards abstraction. For example, Haskell has types and type interfaces - this is about contracts, and there are functions of higher orders - this is about the implementation of interfaces.
In this way, software complexity is reduced and code fragmentation improves reliability.
But even a rigid linear code in BASIC is still the same way to describe the interface of interaction of one code with another.
In addition to OOP and functional programming, there are a bunch of other techniques:
A complete list can be found here:https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%82%D... - and that one is quite abstract and raw.
In short, OOP is not a panacea, but just another way to describe this wonderful and complex world and relationships in it.

Answer 3

A contract, as I understand the term, is that all other code (as well as those who use it later) must know about a particular code in order to interact with it. In OOP, this role is traditionally played by the public interface of the class.
Abstract classes and interfaces allow all other code to know nothing about the whole hierarchy of classes that inherit these abstractions. External code links are reduced to a minimum. And from the point of view of reducing complexity, testing (and generally understanding what is happening in the code), this, of course, is a very big plus.