OBJECT-ORIENTED PROGRAMMING AND ARISTOTLE

public class Animal
{
}

public class Man : Animal
{
}

Man oguzhan = new Man();

You might be a little confused here. "oguzhan" is a reference-type variable. It points to a Man object. Shouldn't we create a class called "Oguzhan" and produce an instance from it? This is something we can debate among ourselves. Aristotle gives some hints about this topic as well. And of course, you can make this more meaningful by adding more fields.

Now let's continue reading and see what Aristotle has to say to us, and confuse our minds a little more.

It took me quite a long time to fully grasp these lines. In fact, they are quite simple, but the language used naturally makes them hard to understand. In short, Aristotle is saying the following:

"Oğuzhan" is a substance. He is a substance by virtue of the "man" and "animal" that are predicated of him, or that he inherits (we could even take this further, to matter and from there to energy). But "Oğuzhan" is a primary substance. Or, dear reader, you are a primary substance. We understood that we are substances. But why are we primary substances? Good question! Aristotle answers it: I am neither said of a subject nor present in a subject.

If you are wondering what this means, let me put it this way: the "man" object is said of the "oguzhan" object and is present in it. The "animal" object is in the "man" object, and "animal" is also said of "man". For this reason, "man" and "animal" are secondary substances. But you cannot say of any other object that it "is Oğuzhan". Suppose there were a substance that had all the properties of "Oğuzhan", that is, one that inherits from Oğuzhan and adds its own distinguishing characteristics on top. In that case, "Oğuzhan" would become a secondary substance. But if no substance inherits from Oğuzhan, then Oğuzhan is a primary substance.

I understood this topic more easily through code, so perhaps explaining it to you with code will make it easier. If we examine the case where Oğuzhan is not a primary substance:

public class Animal
{
}

public class Man : Animal
{
}

public class Oguzhan : Man
{
}

public class Substance : Oguzhan
{
}

Here, an object derived from the "Substance" class is called a primary substance. In that case, even an object derived from the "Oguzhan" class would be a secondary substance.

So far we have learned the following: since the "Oğuzhan" object is a substance, it must definitely be defined as a class. This is reasonable. While Oğuzhan is a programmer, another person may not be a programmer but an artist. While Oğuzhan cannot show an artist's traits, an artist cannot show a programmer's traits. From here we can arrive at the concept of encapsulation. But it is still too early. In fact, so as not to spoil the excitement of the book, I won't go into this topic and will leave it to you. In the following pages, you will understand it better.

Now, let's return to the main subject. Since "Oğuzhan" is a primary substance, the code block above is wrong. How do we fix this? Like this:

public class Canli
{
}

public class Insan : Canli
{
}

public sealed class Oguzhan : Insan
{
}

The sealed keyword says that a class cannot be inherited from. In that case, we can say that an object instantiated from the "Oguzhan" class is a primary substance. Of course, I know you have tons of questions in your mind. Let's take it step by step:

Here, Aristotle says that secondary substances do not signify a certain thing but a quality. In that case, as you would expect, we will clearly make use of the abstract keyword. Besides that, we said that primary substances, being substances, are classes. But we also learned from Aristotle that a primary substance signifies a single, indivisible thing, so evidently we should follow the singleton design pattern here. However, I think the following still holds: if we arrange the Man class appropriately, each instance created from Man will refer to its own unique object, so our earlier examples remain correct. In other words, we don't necessarily have to draw the conclusions above from this. But whatever we conclude, it clearly has a place in object-oriented programming. If we rearrange our code:

public abstract class Animal
{
}

public abstract class Man : Animal
{
}

public sealed class Oguzhan : Man
{
    private static Oguzhan oguzhan;

    private Oguzhan()
    {

    }

    public static Oguzhan GetObject
    {
        get
        {
            if (oguzhan is null)
            {
                oguzhan = new Oguzhan();
            }
            return oguzhan;
        }
    }
}

Now we have exactly one Oğuzhan. Objects cannot be instantiated from the Man and Animal classes, and Oğuzhan can point to only a single object. We have agreed with Aristotle quite well. As I said, if we arrange the Man class appropriately, every instance we create will logically fit this situation too. So however we choose to draw our conclusions, it has a place in OOP. But I followed this path in order to get into both design patterns and the concept of encapsulation, and to draw the most out of what Aristotle says. Otherwise, even in this case: 

    Insan oguzhan = new Insan();

Since the oguzhan variable refers to only a single object, and there is no question of it being inherited from, there is no need for the singleton design pattern or for encapsulation. But as I said, wherever you take this from here, it has a place in OOP.

So as not to make this article any longer, and so as not to spoil the excitement of the book, I'm ending it here. Honestly, I took great pleasure in discovering this book. (Yes! While reading it, you feel like you are discovering OOP.) I hope you read it with the same excitement and pleasure.

Happy reading.

Finally, object-oriented programming was born out of a need. This need arose from programmers writing code in the C programming language using structs to follow a path much like the one in OOP. As a result, OOP was developed. However, the logic of OOP differs from one programming language to another. It is clear that the basic philosophy was laid out by Aristotle. Furthermore, Microsoft has applied this philosophy quite well with C# and .NET. If you like, you can research the C programming language and structs and learn more about OOP.