So this is probably too old for me to help the OP in any way, and I'm not an expert.
However, I'd like to support @Rijk & their accepted answer with a little bit more structure & a few reference books (as outdated as books are starting to be these are, in my opinion, good ones).
So modern OOP, is mostly centered around the SOLID acronym.
Single responsibility, Open-closed principle, Liskov substitution, Interface segregation & Dependency inversion (almost an exact quote from the link).
They are defined better in the linked article than I could do them justice but here are the overall concepts that most of this fits under (but in , as much as I could pull off, less technical sounding terms):
- Do one thing & do it well
- Attempt to keep programming objects smaller & simpler rather than larger & complex (you can still build complex systems with less complex parts and it makes it much easier to understand each part of the complex system... and avoid and fix bugs)
- Make your classes built so they follow the above AND so you can add functionality to them WITHOUT changing the code that makes up the class (when you change working code you are always risking the creation of bugs)
- Design to concepts and ideas before you design your code
- When a concept is implemented in code make an interface for it and anything that fits that concept should support the same interface & that interface to the concept should NOT change
- Based on the above, make more interfaces & more concepts behind them if the interfaces you have created are not sufficient (rather than make the interface you have defined more complex)
- Also avoid complex inheritance chains and instead utilize object composition
It's likely I missed a number of important points and/or failed to convey the proper ideas in what I said so, on to the reference books. These books were recommended to me by multiple programmers with more experience, expertise, & knowledge than I have. So with that recommendation:
The second is an excellent book on how to write good software & pull off software projects & plan & design & ... just lots of other valuable stuff.
The first is more accessible in general and is a really great resource for learning, well ... probably all of the principles covered in the SOLID acronym.
The overarching concept seems to be best described as:
writing relatively error free software through writing smaller pieces of code that are proven to work, that also don't need to be changed when you add more functionality.
Hope that's helpful to someone.