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

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

Сейчас же я захотел переделать код, начав с соблюдения принципа «один класс - одна задача», то есть решил сделать отдельно классы для:
1) Этапов решения кубика
2) Проверок того, что определённый этап выполнился
3) Поворотов кубика
4) и т.д

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

Если сам класс кубика нельзя заставить видеть заголовочные файлы и использовать в них приватные поля кубика без наследования, имеет ли смысл наследовать классы поворотов граней, шагов решения и тд от кубика или наоборот кубик наследовать от этих классов?
  • Вопрос задан
  • 257 просмотров
Пригласить эксперта
Ответы на вопрос 2
Adamos
@Adamos
Хороший класс - это тот, у которого известно, что он делает, но неважно, как он это делает.
Именно для этого нужны интерфейс (чтобы к нему обратиться извне) и приватные поля (чтобы логика работы не торчала наружу).
Если вам нужно обращаться к приватным полям класса извне - это не класс, а скомканные процедуры.
Ответ написан
saboteur_kiev
@saboteur_kiev Куратор тега C++
software engineer
Сейчас же я захотел переделать код, начав с соблюдения принципа «один класс - одна задача»

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы