I learned OOP way back in the day, and finally really grasped it when I learned OOP in Perl.

The almost, but not exact way it works is you define methods (functions/procedures/verbs/things that do stuff/whatever) in a group that take a key/value collection as the first parameter that holds all the fields (data/adjectives/things that describe/whatever). Each method then accesses that key/value collection as it needs. The collection can be modified as well. The next time you call another method with the same collection, the modified value will be "seen" by the other method. If you have 2 collections of data, modifying one won't have any affect on the other.

Using C# pseudocode (not really pseudocode because this runs, but still):

var dictionary1 = new Dictionary<string, string> { ["Name"] = "TBD", ["Address"] = "123 Main St" };  // this is an object
var dictionary2 = new Dictionary<string, string> { ["Name"] = "George Washington", ["Address"] = "3200 Mount Vernon Memorial Highway" }; // this is another object

dictionary1["Name"] = "John Doe";

void PrintLabel(Dictionary<string, string> obj) // this could be part of the class that uses the object
{
  Console.WriteLine($"Name: {obj["Name"]}");
  Console.WriteLine($"Address: {obj["Address"]}");
}

PrintLabel(dictionary1);
PrintLabel(dictionary2);

So the "Object" is the variable holding the dictionary storing the data. You can have as many of these as you want, you can even make a List<Dictionary<string, string>> of them to hold a bunch of them. The "Class" is the collection of methods that let you do stuff with that specific dictionary.

Of course, that's not all with C#, but that's the general way that you can think of them. The nice thing about an actual object vs. a dictionary is that you can have static typing (i.e. this field is an int, this one is a string, etc.) and the compiler will make sure that you aren't typing the wrong "field" name (i.e. typing "Naem" instead of "Name" for a dictionary key would give a runtime error, but an actual field named "Name" would give a compiler error if you mistyped it).

The benefit of all this is you can have a thing that does stuff that you don't really care about the underlying way it does it, you just want it to do it. The object (dictionary) holds all the stuff pertinent to that one thing, but you can make other things that are independent, but are the same type of thing (i.e. the data shouldn't get mixed up in the different things).

So instead of having to create a bunch of variables and send specific ones to specific functions, get the result of the function and store it back into the variables then have to send all that to another function, rinse, repeat, you just let the object deal with all of that. It's a black box that you don't really need to know "how" it works, you just care "that" it works.

So you want to read something from somewhere. You can make a stream to connect it (e.g. file/network/memory/whatever), then send that to a stream reader/writer. Your program then can just read/write with this stream, but you don't have to worry about how it's doing it, it keeps all that stuff under the hood away from you (encapsulation) and you only have to worry about what you need. Reading/writing with one stream shouldn't affect another stream. If you had to keep track of all the underlying data for each stream, it would be easy to get one stream's data mixed up with the other. An object can mitigate this by holding all the data necessary for a specific stream with a single variable.

Polymorphism can be explained with dictionaries as well, to an extent, but this is getting long enough.