OOP is a different way of looking at things. Let's see if I can give you a perspective. And since my first programming was done in FORTRAN II-D on an old IBM 1620 mod II in the 1960s, I can talk about OOP from that time.
Programming started out by making humongous arrays. The typical approach was a set of parallel arrays. By that I mean that each thing we would call a property was the name of an array. So the first object's name was in the OName(1) slot. Its color was in the OColor(1) slot. This meant you had as many arrays as the properties you were tracking. Not really that difficult to wrap your head around.
But there was this new thing called "structures" where instead of parallel arrays of properties, you created a single array of a complex structure. So that meant that Object(1) had elements of name, color, weight, etc. To the computer it made no difference because the compilers could keep track of that stuff for you either way you looked at it.
As procedural languages evolved, though, people started thinking about how long it took to write the code to set up these arrays of objects or these parallel arrays, either way you cut it. As it became clearer conceptually that computers were the ultimate model-makers, the idea of making an object out of a structure started to develop. And the issue is that if you had an object, you could do things with it. Including build code called "constructors" and "destructors" to create or destroy objects, to initialize and close them down, whatever they were doing. And that started the idea of having CODE be built into the object.
Think for a moment about Windows. You can still do this today. Pick an icon on the screen. That icon is there because the object underneath it identifies that icon. (You can click "Properties" and get to something that would let you change the icon.) If you right-click on the object, you get a list of things you can do with that object. You can open it (assuming it is openable). You can rename it, delete it, copy it, cut it, paste it, change its properties such as security, ownership, etc.
If you consider the old way of doing things, what we do now is define CLASSES of objects for which certain actions are possible for ALL MEMBERS of that class. We don't have to individually program the list of actions for each object. It is enough that it is a member of a class such as files in order to know a lot of things that can happen.
But the next step is sub-classes. In Windows, this is what is called an association. All files have basic file manipulation. But some files have more things that they can do based on the programs that work with those particular files. So files of type .DOC, .DOCX, and a few others can be opened by WORD. Files of type .XLS, .XLSX, .CSV, and a few others can be opened by EXCEL. And so on. And you don't have to do anything but get the file type correct in order for the correct sub-class options to be added to that list of things you can do with a file.
That is because a file, being a member of a particular class of objects, has a predetermined set of things you can do with it (in Access, called "methods.") This is what OOP gets you.
At the device-driver level, though, OOP is still playing around, even though sometimes you are below the level of files. For instance, a serial port can do input and output. You can open a serial port as though it were a file. Same for parallel ports. Same for networking ports. The drivers for the devices will take any request but sometimes the result is a no-op (null operation). For instance, you can open a serial port but a directory operation will only return the device name. You can close a serial port but no file actually gets stored because of that. The point, though, is that except for certain specialized scientific devices, ALL device drivers treat ALL devices like objects that can do I/O.
This is getting far afield, but I have one more point to make: The mindset of OOP is that you are modeling something. What you put inside the model might make it a black box to the world that uses it, but the object's programmer-creator is simply defining what you can do with it (and equally, what you can't.)
We could get really deep into the weeds by discussing inheritance, because sub-classes inherit properties and methods from their base class, but perhaps you might need to do some reading or thinking first before deciding that OOP is not needed.
