One big thing I've learnt is to design classes from the outside in. Design the interface before you even start thinking about the implementation. This will make the class much, much more intuitive for your users (those using the class) than writing the underlying algorithms and building up the class, and writing new public member functions as they are needed.
I think the most common misconception about OOP is that it's supposed to make writing software much easier. That's where some of the criticism comes from, because when writing software, OOP often means more and sometimes even less natural code. That's what makes it hard to see the benefits of OOP, as everyone who starts programming just writes new programs and never has to maintain existing ones.
However, the real benefit of OOP only shows when you have to maintain software over the years, while constantly changing parts of the program in ways nobody expected when they were first written.
You should see OOP as a way to make sure that local changes to the software stay local and don't affect the rest of the program. In this sense classes are sort of explicit placeholders for future changes. In a procedural program it is often hard to see where you have to change the code to add a completely new feature, without affecting anything else.
Surely you can write procedural programs that are also extensible, but you have to think about it and design it properly. OOP provides you with a general idea of how programs can be structured to keep them maintainable, which means that don't have to think about design that hard! The same goes for other programming paradigms, OOP isn't necessarily the just the most common right now.
So in conclusion I think the only way to really understand OOP is to change and add features to existing software. This is the most common task for programmers anyways, and it's supposed to be easy! Not having a good design makes it harder than it has to be.
That sort of makes it hard to answer your question, as any project can benefit from OOP if it's complex enough and needs to be maintained and expanded. I think projects that can have any number of unforeseen features, such games or bots would be good examples. You can also work on a open source program, that is in general the best way to practice advanced programming.
Best Answer
Short answer: no.
Long answer: There's no "simple way" because OOP is far from 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 a 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 keeping a good segregation of duties.
We came to a "solution" that was to 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) andgraphic_manageretc. 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 feel 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're 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 terms 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 ones who come from 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.