Features of domain modeling using OOP



    Introduction


    I want to note that it will be very difficult for those who use OOP terms to understand me. The fact is that OOP has replaced concepts. In OOP, a class is not understood to be a multitude, as is customary in mathematics or linguistics. In OOP, the class is called the type of objects , as in Aristotle. In OOP, it would be correct to use the term object type instead of the term object class . Once, having moved out with the correct terminology, it is very difficult to return to the fold of the right terms. In this article I will try to help those who want to deal with the terminological porridge brewed by OOP. In my discussion I will use the terms in their original sense, and not in the sense of OOP. Term classwill be taken from the logical paradigm of domain modeling, which, in turn, borrowed this term from set theory. The terms type and instance will be taken from type theory built on Aristotle's paradigm of the existence of types.

    It is very difficult for an OOP adherent to understand that the term class instance in Russian indicates a class of objects, and not an element of the class that is consonant with this term — an object of the class. For many who have studied OOP, the terms instance and element are indistinguishable. Let's deal with these terms carefully.

    Definitions of Terms


    Term instance


    An instance is an object from a series of its own kind. That is, a machine instance is an object from a number of similar machines. Aristotle believed that the subject has the idea of ​​the existence of machines. This idea is expressed in the form of an abstract type of objects (machines) existing in the consciousness of subjects. When a subject looks at an object, he compares what he sees with the image that he has in his imagination (with the type of machines), and if he finds similar features, he calls the object a machine, or an instance of a machine. A list of similar features Aristotle called type. And an object possessing these features is an instance of this type.



    Following the logic, an instance of a class is an object from a number of similar classes. Thus, in Russian, the term instance of a class points to a class.



    A machine refers to a class of machines as follows: a machine is an object of a class of machines.



    Therefore, if we say, as is customary in OOP, that a machine is an instance of a class of machines, then it turns out that a machine is a class of machines. Clash!

    In OOP, the term class refers to the term type. Therefore, the term class instance in OOP should be read like this: an instance of an object type. Then our picture will look like this:



    Therefore, if you meet the term instance of a class, then know that most likely this term is generated by OOP and therefore it is an object type. Outside of OOP, a class means many objects.

    Term element


    An element is part of something. The element of the board is the resistor, the element of the leg is the knee, the element of the multitude is the object. Thus, the term element can refer to a relationship between two entities. This relationship can be a composition link (a machine element is a wheel),



    or a classification link (an element of a wheel class is a wheel).



    Other pairs of incorrect terms:


    In addition, other incorrect pairs of terms are common in business analysis: an event and an instance of this event, a process and an instance of this process, an agreement, and an instance of this agreement. In Russian there is no such thing as an object and an instance of this object. There are terms the type of object and an instance of this type of object.

    Perhaps the erroneous use of the terms arose due to the incorrect translation of the term instance from English. Instance translates as an example, or as a case, but it does not translate as an instance.

    Be that as it may, let's see the correct use of the term instance:

    • An electron instance is an electron, an instance of a particle of the electron type, or an instance of this type of electron (but not an instance of this electron).
    • A process instance is a process, an instance of an object of type process, or an instance of this type of process (but not an instance of this process).
    • An instance of an event is an event, an instance of an object of type event, or an instance of this type of event (but not an instance of this event).
    • An instance of a class is a class, an instance of an object of type class, or an instance of this type of classes (But not an instance of this class)

    These statements are made in the Aristotle paradigm, where there are types of objects and instances of these types, but not objects and instances of these objects. I wrote about the Aristotle paradigm in an article: Acquaintance with the paradigms of constructing domain models .

    Analogy with science


    One very interesting fact should be noted. The analogy between religion and science suggests itself. A scientific approach has emerged to counterbalance the religious description of the world. If you describe the world in terms of religion, then you need to understand that the presence of God cannot be verified. The foundation of faith is faith. The scientific approach, in contrast to faith, puts the primacy of the experiment. That is, if the experiment confirms the existence of Paradise, then Paradise exists. If it does not confirm, then it is not known whether it exists or not. The terms used in one concept do not mix with the terms used in another. For example, one can sometimes hear the thesis that someone has proved the existence of God. But as soon as someone proves this, God will cease to be God and will become another concept. Therefore, it is impossible to prove the existence of God, and therefore it is impossible to introduce the term proof in religion.
    Similarly, in ontology, there are two approaches: one was invented by Aristotle. This is type theory. The second was coined as opposed to the Aristotelian types. This approach is called the logical paradigm and uses the term class. These two paradigms are immiscible, like science and religion. Therefore, the term class cannot be used in type theory, and the term type cannot be used in class theory. However, the PLO has violated this prohibition. For this he needs to say fu.

    In my expositions, I rely on a logical paradigm in which there is an object and there are many objects, called a class of objects, but there are no terms such as instance, type and term class in the sense of OOP. For an introduction to the logical paradigm, I can recommend reading Chris Partridge Business Objects: Re-Engineering for Re-Use , Matthew WestDeveloping High Quality Data Models .

    The basis of the logical paradigm: communication classification and specialization


    Suppose there is a class of objects called wheels. This class contains all the wheels in the world that were, are and will be. By definition, the fact that an object of this class (wheel) belongs to the class of wheels is denoted by a classification relationship.



    There is no such relationship in OOP, and you cannot specify it in the UML diagram.

    Let there be a subclass (subset) of this class — the class of wheels under study (for example, the class of wheels belonging to one machine). By definition, the fact that this class is a subset of the class of all wheels is denoted by specialization.



    In OOP, this relationship between classes is called inheritance. Class 2 is said to inherit from Class 1.



    But in nature, Class 2 is a subset of Class 1. Apparently, it means that traits, or parameters, are inherited. But the parameters are only in the type description! And again, we run into a mixture of terms. Classes cannot inherit anything. But types can.

    On connections, specialization and classification can be found here: Information objects or the cause of one error (In the paragraph “Solution in a logical paradigm”, I showed how you can model a subject area using these terms).

    Dividing into classes and class objects allows me to consider any objects of the studied class, for example, the elephant class (to study the lifespan of any of the elephants, the length of its tusks at various stages of its life), as well as the elephant class (to study the average lifespan of elephants, average height and average weight). It is clear that any elephant of the class cannot "know" information about the average life expectancy of all elephants. Only the class of elephants “knows” this information. Try in Aristotle’s paradigm to come up with an object that “knows” about the average height of elephants, without using the term set! It is unlikely that you will succeed. Therefore, if you are an analyst, then you will have to work with objects and classes of objects (but classes do not mean OOP).

    Let me remind you: a class in a logical paradigm and a class in OOP are two different things. A description of a class in a logical paradigm is an enumeration of the objects of this class, and not the properties of these objects. In OOP, a class description refers to a description of the properties of objects, which, in fact, means a description of the type of objects. Those who teach OOP do not hide the fact that a class in OOP is a type of object. But this is why the type was called a class, not disclosed.

    Example
    To understand why class definition in OOP does not work in the real world, try the simplest operation on a class: create a class of all subclasses of this class. And try to apply a class definition that applies to OOP to each subclass you create.

    Example: let us have three apple trees {1; 2; 3}. This is a class. OOP requires the presence of objects of this class of common features. Let it be a sign of the presence of apples. Create a class consisting of all subclasses of the class of these apple trees. This class consists of classes: {{empty}; {1}; {2}; {3}; {1; 2}; {1; 3}; {2; 3}; {1; 2; 3}}.



    That is, in this class class there are 8 elements. Try, if you follow the definition of an OOP class, to give a differentiated description of these classes (another is meaningless). And these are flowers - there are only three elements in the class. And if there are 1000, and if there is a countable set, and if there is a continuum? Therefore, in OOP there are not even the simplest operations on classes (addition and subtraction of sets).

    Also popular now: