OONP problem: there is no clear and obligatory core object-oriented modeling

Hello colleagues!

I would like to share my thoughts about the UNPN and the PLO as a whole, and also what can (and I think we should) do on this basis.

Basic ideas: In modern NLSNs, there is no clearly defined and mandatory modeling core for creating abstractions based only on "pure" concepts of OOP. The concept of the PLO "everything is an object" is not practical. The concept of messaging is strictly related to its implementation.

Object Oriented Programming Languages ​​(SSNP) are understood to be Java and C #, although this topic may also be related to other SSNTs.

I'm not trying to start another discussion about the problems of OOP or OOP vs OP. The purpose of the article is to look at the SNPP and programming languages ​​in general, and show that languages ​​have properties that can be useful for SSNP as well. Modern SADNC to some extent proved its viability, and the result of solving this issue would be a new language .

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

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

An example of a language that has such a modeling core is Haskell: dirty I / O functions require special syntax and interact with pure functions through a clear protocol. Pure functions allow a rather abstract modeling of the subject area, based on the functional approach. (Although even in functional languages, sometimes you have to consider 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 an abstract mathematical theory (lambda calculus). The reasons for the emergence of the PLO, in my opinion, are purely practical and applied, therefore, the imperative foundation is so prominently visible in the UNPN.

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

Due to the fact that constructions both for describing objects (classes, interfaces, methods, etc.) and for implementing the imperative approach are mixed in an SNNP, a fundamental contradiction is inherent in an SNFN: at the same time, abstract models must be written, and their specific imperative implementation. This contradiction is, in my opinion, the cause of the key points of criticism of the PLO.

In addition to providing an imperative approach, the use of resources in the SOBNP 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 must be represented by major key steps, based on the pattern of "template method". Next, the steps from the models are converted to the actual output code.

In general, it seems to me, the new operator is a sign of an explicit imperative approach. The new operator should not be at all in the modeling kernel for defining objects — objects are defined declaratively. The existence of the object is declared, and the actual way of creation will be clarified later. Moreover, not the object itself can be instantiated, but a proxy to a remote object.

Another example of a problem is the implementation of the messaging concept itself. Messaging, as an abstract concept, is strictly defined in the DLNP by the language and presented in the form of method calls. The message exchange must remain abstract in the modeling core and later projected into a specific messaging mechanism, for example, method calls or projected into some topology of distributed actors.

Another problem that is related to the lack of a simulation core is the null value. Here, in my opinion, the most terrible mixture. The null value in DLNP means different things, hence all the problems. Suppose that pure OOP is a way of modeling , imperative implementation and resources stand apart, and there is still a data model . Then the essence of the problem is that any object requires the resource "memory" (which is a sign of an imperative implementation) and the null value from the imperative implementation is present in all contexts . The data model itself allows a null value, but with these null values ​​there are fewer problems, because they are expected and data related. In the modeling kernel, null values ​​for objects should be absent 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 the practice still requires that the data are not reduced to objects, and I would define the basic concepts of OOP as messages / collaborators / data . The data model (for example, relational) must be explicit. Modeling the subject area is to represent it as a group of objects (collaborators) that exchange messages. Message arguments are data. This is the basis of the modeling core. “Everything is an object” is a super-generalization, when important specificity of basic concepts is lost, and they begin to look the same, although they need to be fundamentally distinguished.

Conclusion

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

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

As an example of a similar idea, I will give the project in object-oriented eolang language of Egor Bugaenko. ( This is not an advertisement for Egor and his project. At the time of writing this article I am not familiar with Yegor personally, I did not have any chats or correspondence with him, I am not a contributor to his projects ). I generally support what is happening in the framework of the eolang project, although there are a lot of questions and disagreements in details. However, in eolang, in my opinion, what was discussed above: a whole set of imperative and procedural constructions and mechanisms were removed from Java. Just the removal of imperative and procedural elements is an attempt to isolate the pure core of the PLO simulation.