OOJP problem: there is no clear and mandatory core of object-oriented modeling

Hello colleagues!

I would like to share my thoughts about the NWOF and the PLO as a whole, as well as what can be (and, it seems to me, necessary) to be done on this basis.

Key ideas: In modern OOJPs, there is no clearly defined and mandatory modeling core for creating abstractions based only on "pure" OOP concepts. The concept of OOP "everything is an object" is not practical. The concept of messaging is tightly connected with its implementation.

Object-oriented programming languages ​​(OOJP) are understood as Java and C #, although this topic can also be related to other OOJP.

I am not trying to start another discussion about the problems of OOP or OOP vs FP. The purpose of the article is to look at OOJP and programming languages ​​in general, and show that languages ​​have properties that can be useful for OOJP. Modern OOJP have proved their viability to one degree or another, and the result of solving this issue would be a new language .

Almost everything that will be discussed is somehow already used in practice, but I would like it to be part of the language, at least as an alternative. But at present, there seems to be no such alternative.

In my opinion, there is no obligatory part in the NLFS - the modeling core , on which you can declaratively and very abstractly describe the subject area, based only on pure modeling concepts, in this case, on the elements of OOP decomposition (collaborators, messages, data).

As an example of a language in which there is such a modeling kernel, Haskell can be cited: dirty I / O functions require special syntax and interact with pure functions through a clear protocol. Pure functions allow you to quite abstractly model the subject area, based on a functional approach. (Although even in functional languages ​​it is sometimes necessary to consider the implementation, as an example - the use of tail recursion and its optimization by the translator).

The reason why a purely functional language has such a core, I think, is obvious: the functional approach, by definition, is based on abstract mathematical theory (lambda calculus). The reasons for the emergence of OOP, in my opinion, are purely practical and applied, so the imperative foundation is so clearly seen in the NWEP.

The core of the OOJP modeling should be based only on the elements of OOP decomposition. The syntax of the modeling core should be very simple, declarative, and abstract. Nothing but the definition of the "topology" of objects / collaborators (who interacts with whom), semantics / message names and their parameters / return values ​​should not be in the modeling kernel. The use of such a language is possible only starting from the modeling kernel, then converting the models into output code.

Due to the fact that constructions are mixed in OOJP both for describing objects (classes, interfaces, methods, etc.) and for the implementation of an imperative approach, in OOJP there is essentially a fundamental contradiction: at the same time, abstract models and their specific imperative implementation. This contradiction is, in my opinion, the reason for the key points of criticism of the PLO.

In addition to providing an imperative approach, the use of resources in the NWEP is also not separated from abstract models. Resources are memory and algorithms (in the sense of a sequence of instructions). In my opinion, memory and algorithms as resources need to be tied to abstract models. In models, imperative should be represented by major key steps, based on the template method pattern. Next, the steps from the models are converted to the actual output code.

In general, it seems to me that the operator newis a sign of a clear imperative approach. An operator newshould not be in the core of modeling to define objects at all - objects are defined declaratively. The existence of the object is declared, and the actual method of creation will be clarified later. Moreover, it is not the object itself that can be instantiated, but a proxy to the remote object.

Another example of a problem is the implementation of the concept of messaging. Messaging, as an abstract concept, in OOJP is hard-coded by language and is represented as method calls. Messaging should remain abstract in the core of modeling and later projected into a specific messaging engine, for example, method calls or projected into some sort of distributed actor topology.

Another problem that is associated with the lack of a modeling kernel is the null value. Here, in my opinion, the most terrible mixture. The null value in OOJP means different things, hence all the problems. Suppose that pure OOP is a modeling method , the imperative implementation and resources are separate , and there is still a data model . Then the essence of the problem is that any object requires a "memory" resource (which is a sign of imperative implementation) and the null value from the imperative implementation is present in all contexts . The data model itself is nullable, but there are fewer problems with these null values, because they are expected and data related. In the modeling core, null values ​​for objects must be missing by definition, although null values ​​from the data model are valid.

A few words about the OOP concepts themselves. In my opinion, the concept of “everything is an object” is not practical , although it looks, of course, very logical. I think practice nevertheless requires that the data does not come down to objects, and I would define the basic concepts of OOP as messages / collaborators / data . The data model (e.g., relational) must be explicit. Modeling a domain consists in representing it as a group of objects (collaborators) that exchange messages. The message arguments are data. This is the core of the modeling core. “Everything is an object” is an over-generalization when the important specificity of basic concepts is lost and they begin to look the same, although fundamentally they need to be distinguished.

Conclusion

OOP is a modeling method (decomposition and definition of abstractions), it must be separated from imperative implementation, resource management and data model. Modern OOJP mix all these concepts, and the problem is solved beyond the framework of languages, through the application of design principles, patterns, idioms, conventions, etc.

I see an alternative solution in a new language, built by analogy with functional languages. “By analogy” means that the new language will have the same property as the functional ones: a clean and binding core of modeling.

As an example of a similar idea, I will give the project of object-oriented eolang language of Yegor Bugaenko. ( This is not an advertisement for Yegor and his project, at the time of writing this article I am not personally acquainted with Yegor, had no chats or correspondence with him, I am not a contributor of his projects ). I generally support what is happening within the eolang project, although there are a lot of questions and disagreements in the details. Nevertheless, in eolang, what is discussed above is happening in my opinion: a whole set of imperative and procedural constructions and mechanisms has been removed from Java. Just the removal of imperative and procedural elements is an attempt to isolate the pure core of OOP modeling.