Short answer: no.
Long answer: There no "simple way" because OOP is far than simple. Procedural programming is all about "variables" and "if then goto". Everything else is syntactic sugar, but those four things are all of what procedural programming is about. Once you get them nothing can stop you.
OOP is a way to organize variables and pieces of code. How many patterns are there to define OOP? 25? 30? Even teachers who learned OOP from different languages and backgrounds don't agree on its own definition, so ... how can it be simple?
I don't know how you came to that, but since your mother has similar experience to mine, I can tell you how I came to that.
I was programming in C in a very large project. It was 1988. Many programmers organizing modules and libraries, with the difficulty of avoiding interference in other jobs and keep a good segregation of duties.
We came to a "solution" that was put all interrelated global data into structs, placing in those struct some function pointers where callbacks were required. We generalized in that way what we called
io_mask (sort of textual mode dialog boxes) and
graphic_manager etc. etc.
In 1996 It was very easy to discover that those structs were named "classes" and those function pointers replaced by member function and virtual functions, or with links to other objects (called behaviors) by other programmers who renewed that old project.
I started to understand OOP when I started to feel the need for it: segregation, polymorphism, and runtime defined behaviors.
Today I work with OOP, but I don't think of it as a doctrine to serve: just a "common idiom" (set of ...) that let us speak together without the need to provide long explanations and descriptions all the time. In fact, more a "convention" than anything else. After all, all OOP does is -again- "if then goto": it just does it "multilayered". Hence abstraction and idioms over idioms.
Ignore them. Until she doesn't fell the need for them don't even try to explain: she will feel them just as a complicated way to do simple things. And she is right... until what she does is -in fact- simple.
No one will think to "organize a desk" if there just four things on top. It make sense when the things on top start to interfere each other. That's the time for OOP to come in.
You don't need OOP to work with C++. The entire C++ standard library is not designed in term of OOP (although it can cooperate with it), and C++ is not Java.
In all my experience the worst C++ teachers and C++ programmers are the one who come form Java, teaching all their prejudice about everything is not OOP, denaturating a language like C++ that is not (just) for OOP.
Let me suggest a good book for those who want to approach C++: Accelerated C++: it will bring you into C++ idioms without pretending to follow a predefined doctrine.