The difference between an object and an instance, is it at all?
I think it’s no secret to anyone that in OOP (object-oriented programming), the main emphasis is on objects and their interaction. There are even 6 basic laws, 6 OOP paradigms, which, if we want to write the right OOP code, we must adhere to. But, as a rule, newcomers who come to OOP often see the concept of an object along with the concept of an object. It is, of course, not surprising that these two inextricable words are used in the same context even in high-quality literature. But the biggest problem comes from this: confusion in the concepts of instance and object.
What is a heap?
For a detailed analysis, we first recall that all reference types (classes, interfaces, delegates, collections, arrays, etc.) are stored in a memory area called a heap, and all significant types (int, float, double, enumerations, structures, etc.) .p.) and memory address references of reference types on the heap are stored on the stack. The heap is a dynamic, disordered memory area, it is much larger than the stack and from this it is already possible to draw a logical conclusion why all reference "bulk" types are stored there.
Create Object and Instance
For complete clarity of the picture and as proof, let's create an instance of some previously described class:
public class MyExample //- { public void Hi() { myHi(); } private void myHi() { Console.WriteLine("Hi, man!!!"); } } class Program { static void Main(string[] args) { MyExample myExample = new MyExample(); // MyExample // c MyExample myExample.Hi(); // MyExample } }
A simple example, to which you still have to finish a lot. Firstly, the concept of an instance itself implies a set of values of non-static fields for a given object (anyone who is familiar with statics will understand sooner), and the object itself stores all methods and static fields. On the heap, it looks like this:
As you can see, there will be as many instances as the number of times you assign a reference to the variable through the constructor for this instance. And in the end, we came to the conclusion that “instance 1” and the object implemented the first OOP paradigm - encapsulation, and “Object 1” was created.
Secondly, to put this puzzle together, let's recall why the class needs a constructor: it is needed in order to initialize all non-static fields of the class. It turns out thanks to the designer that we create a new instance each time.
Encapsulation
Above, I mentioned the first (it is important that it is the first) OOP paradigm - encapsulation. Many "new" programmers confuse encapsulation with a similar phenomenon - hiding the implementation. These wrong thoughts come from the statement that encapsulation is hiding the implementation from the user due to access modifiers, which is true and fundamentally wrong at the same time. If you look at the photo example again and carefully re-read the information, we can conclude that encapsulation is "a kind of combination of an instance and an object into one entity." And in principle - it is so from the part. After all, the correct meaning of the word encapsulation in programming will sound like this: “Encapsulation is the first OOP paradigm, which implies that the data and methods for working with this data will be combined into one object [Object 1 (see photo)], and the implementation will be hidden from user ".
I hope in the future you will no longer confuse the meaning of the words instance and object, and encapsulation has finally found a new and correct meaning in your head.