Как правильно выстроить логику кода с соблюдением принципов ООП?
==================================================================

 Проблема заключается в следующем: я написал код, который решает кубик Рубика, с использованием классов, но в очень плохой форме, так как я засунул и алгоритм решения, и проверки состояний, и все, что только можно было в сам класс кубика.   

  

Сейчас же я захотел переделать код, начав с соблюдения принципа «один класс - одна задача», то есть решил сделать отдельно классы для:  

1) Этапов решения кубика  

2) Проверок того, что определённый этап выполнился  

3) Поворотов кубика  

4) и т.д  

  

Но в этот момент у меня возник вопрос: у меня ничего не получается сделать ввиду того, что при банальном создании класса в другом заголовочном файле я уже не могу использовать приватные поля самого кубика в тех же алгоритмах решения, где у меня внутри функций прописаны изменения этих самых приватных полей, потому что я просто не могу заставить заголовочный файл видеть класс кубика и с ним работать (**реально ли это на практике и у меня просто не получается это сделать или так и должно быть?**)  

  

Если сам класс кубика нельзя заставить видеть заголовочные файлы и использовать в них приватные поля кубика без наследования, **имеет ли смысл наследовать классы *поворотов граней*, *шагов решения* и тд от кубика или наоборот кубик наследовать от этих классов?** 

 Хороший класс - это тот, у которого известно, что он делает, но неважно, как он это делает.  

Именно для этого нужны интерфейс (чтобы к нему обратиться извне) и приватные поля (чтобы логика работы не торчала наружу).  

Если вам нужно обращаться к приватным полям класса извне - это не класс, а скомканные процедуры. 

> Сейчас же я захотел переделать код, начав с соблюдения принципа «один класс - одна задача»

  

Почему? Откуда взялся этот принцип?  

  

Следуйте следующим принципам:  

1) данные, которые находятся внутри класса обрабатывались методами этого класса  

2) Избегайте суперклассов (слишком больших классов, которые не помещаются в голову одного программиста, и вызывают много конфликтов при поддержке приложения)  

3) Соблюдайте баланс между первыми двумя пунктами.  

  

Учитывая, что вы единственный разработчик, то нет смысла делить класс на несколько, даже если он великоват.  

Если у вас есть визуализация этапов, можно было бы разве что в отдельный класс вывести эту визуализацию. А так - скорее всего у вас все хорошо. Может быть названия методов пересмотреть и все.