I think my viewpoint is similar, but not quite the same as yours. Or maybe we just have different understandings of what "object oriented" means.

I find myself naturally writing highly modular programs, where a group of functions and the data that they "own" all live together in a single source file, with a limited and well defined interface to other modules. But to me, code that's merely modular is not necessarily object oriented (although the converse is certainly true).

I think that code gets to be object oriented as soon as it starts to have functions (methods) that operate on multiple and distinct data structures (objects) without knowing or caring which of those structures they are working with at any given moment. I consider the example that I gave at the start of this thread to be object oriented code, but similar code that could only deal with a single UART wouldn't be.

It took me a long time to understand and appreciate the OO paradigm, and getting there was anything but a natural process. Part of the problem I think were the made-up examples that folks sometimes use when they're trying to explain it. How often have you seen some introductory tutorial use "shapes" and "ellipses" and "circles" as examples of objects. C'mon! Those are abstract concepts if there ever were any. Remember, Mr. Tutorial Writer, I'm just learning this stuff. It's hard enough without you telling me that a "shape" is an object. Please give me some examples I can relate to. Like rocks. Rocks are objects. Thank you.

A second problem was that some folks seem convinced that object oriented programming is an all or nothing deal. A big light bulb came on for me the day I finally realized that the C++ gods weren't going to rend me asunder if I didn't try to make every single "thing" in my program a member of some class, even if that meant contriving artificial and useless classes to make them members of. I've been in a twelve-step program ("Hello, my name is Russell and I create abstract classes for no reason"), and it's helped a lot. These days I'm quite content to call an integer an 'int' and not feel ashamed about being too lazy to write the CNumericVariableThatCanOnlyContainCountingValues class.

Once you get the hang of it, I think the key to using OO techniques effectively is to apply them in moderation. Use them where they make good sense and ignore them otherwise. As an example, I find that it almost never makes sense to create a class unless you're going to need multiple instances of it. If you just have one of something, just hide it in a module by itself and be done with it. On the other hand, if you do have seven things that are all alike (like my UARTs), then by all means take the trouble to "objectify" them. Your code can be a lot smaller and cleaner than if you try to deal with them individually.

-- Russ