How to properly build the logic of the code in compliance with the principles of OOP?

Question

OOP

The problem is this: I wrote the code that solves the Rubik's Cube using classes, but in very bad shape, since I put both the solution algorithm and the state checks and everything that was possible in the cube class itself.

Now I wanted to redo the code, starting with the principle of “one class - one task”, that is, I decided to make separate classes for:
1) The stages of solving the cube
2) Checking that a certain stage was completed
3) Turning the cube
4), etc. d

But at this moment, I had a question: I can’t do anything because, when creating a class in a different header file, I can no longer use the private fields of the cube itself in the same solution algorithms where I have changes to these inside the functions the most private fields, because I just can't get the header file to see the cube class and work with it ( is it realistic in practice and I just can't do it, or should it be? )

If the cube class itself cannot be forced to see the header files and use in them private fields of the cube without inheritance, does it make sense to inherit classes of turns of faces , solution stepsand so on from the cube or vice versa to inherit the cube from these classes?

Answer 1

A good class is one that knows what it does, but it doesn't matter how it does it.
This is what the interface is for (to access it from the outside) and private fields (so that the logic of work does not stick out).
If you need to access private fields of a class from the outside, this is not a class, but crumpled procedures.

Answer 2

Now I wanted to redo the code, starting with the principle of "one class - one task"

Why? Where did this principle come from?
Follow the following principles:
1) data that is inside a class was handled by methods of that class
2) Avoid superclasses (classes that are too big to fit in one programmer's head and cause a lot of application maintenance conflicts)
3) Keep a balance between the first two points.
Given that you are the only developer, it makes no sense to divide the class into several, even if it is large.
If you have a visualization of the stages, you could only bring this visualization into a separate class. And so - most likely you are fine. Can be names of methods to reconsider and all.