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

Question

[lipa44]

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

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

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

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

Comments

[Евгений Шатунов]

lipa44 ,

я уже не могу использовать приватные поля самого кубика в тех же алгоритмах решения

Такие алгоритмы решения уже неправильные.

реально ли это на практике и у меня просто не получается это сделать или так и должно быть?

Да, это реально. Но сперва нужно понять твои собственные проблемы и заблуждения. Кажется, в отношении ООП у тебя их много.

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

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

[lipa44]

Евгений Шатунов, я неправильно выразился по поводу того, что класс должен видеть заголовочные файлы. Я имел ввиду, что я не могу сделать экспорт модуля, как, например, в js, и спокойно использовать элемент класса кубик в другом заголовочном файле.
Я подключил к заголовочному файлу другой заголовочные файл, который называется «решение кубика», но после попытки объявить элемент класса кубик в этом заголовочном файле или принять в качестве параметра функции, мне среда разработки говорит (can’t resolve type “rubikCube”), хотя я просто создаю/принимаю переменную того типа, которая у меня прописана в заголовочном файле, который я подключил.

Почему класс кубика должен иметь родителя? Этого я не говорил, это как раз и была часть моего вопроса, имеет ли это смысл, потому что я не совсем понимаю, правильно ли делать классы поворотов, алгоритмов и всего остального наследованными от кубика.

Что касается поворота, у меня это и есть функция, которую я хотел вынести в отдельный класс, но, опять же, для того, чтобы это работало, единственное, что я могу написать - это то, чтобы функция поворота принимала n-ное количество «обезличенных и отделенных» от кубика параметров, а именно, векторов по ссылкам, и менять в них значения, вместо того, чтобы не принимать никаких параметров, как это было тогда, когда повороты были внутри класса кубика, и могли взаимодействовать с его приватными полями.

Вопрос как раз и состоит в том, какую структуру, порядок наследования и тому подобное выбрать для данной проблемы, сам я на этот вопрос ответить не могу, поэтому и спрашиваю тут :)

[Евгений Шатунов]

lipa44,

Я подключил к заголовочному файлу другой заголовочные файл, который называется «решение кубика», но после попытки объявить элемент класса кубик в этом заголовочном файле или принять в качестве параметра функции, мне среда разработки говорит (can’t resolve type “rubikCube”), хотя я просто создаю/принимаю переменную того типа, которая у меня прописана в заголовочном файле, который я подключил.

Давай вот этот момент посмотрим в твоем коде. Выпиши в сокращенном виде свои заголовки, оставив в них только описываемые тобой строки кода.

У тебя должно получиться что-то вроде этого

// cube.h
...
#include ???
...
class Cube
{
...
};

// solutions.h
...
class Solution
{
...
};

Со всем остальным будем разбираться по ходу дела.

[lipa44]

// cube.h

...
#pragma once

#include <iostream>
#include <vector>
#include <unistd.h> // для sleep и flush
#include "checkCubeFunctions.h"

#define Plane vector<vector<MiniCube*>>
#define RightCenter RightPlane[1][1]->RightColor()
#define LeftCenter LeftPlane[1][1]->LeftColor()
#define UpCenter UpPlane[1][1]->UpColor()
#define DownCenter DownPlane[1][1]->DownColor()
#define FrontCenter FrontPlane[1][1]->FrontColor()
#define BackCenter BackPlane[1][1]->BackColor()

#include "miniCube.h" // то, из чего состоит кбуик
#include "cubeSolving.h" // алгоритмы решения
#include "rotates.h" // повороты
#include "additional.h" // прочие вспомогательные функции
...

class rubikCube {
private:

//    unsigned int FirstStepCounter = 0, SecondStepCounter = 0, ThirdStepCounter = 0,
//            FourthStepCounter = 0, FifthStepCounter = 0, SixthStepCounter = 0, SeventhStepCounter = 0;

    // В arr мы храним "слои" нашего кубика, в каждом из которых есть 3 вектора по 3 мини-кубика
    vector<vector<vector<MiniCube>>> arr;

    // Грани кубика
    Plane UpPlane;
    Plane DownPlane;
    Plane LeftPlane;
    Plane RightPlane;
    Plane FrontPlane;
    Plane BackPlane;
...

// solution.h

#pragma once

#include "rubikCube.h"
#include "rotates.h" // повороты
#include "checkCubeFunctions.h"

using namespace std;

// class rubikCube; пишет  Can't resolve type 'rubikCube'

class cubeSolving {
private:
    int FirstStepCounter = 0, SecondStepCounter = 0, ThirdStepCounter = 0, FourthStepCounter = 0,
            FifthStepCounter = 0, SixthStepCounter = 0, SeventhStepCounter = 0;

    // хотелось бы тут хранить rubikCube cube;
    // но он выдаёт Can't resolve type 'rubikCube'

public:
//    cubeSolving(rubikCube cube_) : cube(cube_){}
    cubeSolving() = default;

    // Стадии сборки кубика
    void FirstStep(int count = 0, bool isWriteToConsole = true) {
        if (FirstStepCounter++ > 128) {
            // solvingErrors.emplace_back("\nОшибка при сборке кубика номер " + to_string(CubeCounter) + " (1й шаг)\n");
            throw exception();
        }

        /*** тут он должен принимать приватные поля кубика, либо обращаться к ним напрямую ***/
        /*** LeftCenter, FrontCenter и т.д - цвета соответствующих центров, а DownPlane, LeftPlane
             и т.д - плоскости, которые хнанят по 9 мини-кубиков, каждый из которых имеет цвет на каждой из сторон ***/

        if (!checkCubeFunctions::isFirstStepCompleted(LeftCenter, FrontCenter, 
RightCenter, BackCenter, DownCenter, DownPlane, LeftPlane, RightPlane, FrontPlane, BackPlane)) {
...

Соответственно, вот, что я имею
1) То, что я подключаю к cube.h
2) Структура кубика
3) То, что у меня в "solution"

В последнем я подписал, что хотелось бы хранить в приватном поле solution сам элемент класса кубик, чтобы я мог обращаться так к его полям, но при любом упоминании класса rubikCube у меня вылезают ошибки с надписью "Can't resolve type 'rubikCube'"

P.S проверку инвариантов шагов решения я уже засунул в "solution"
P.S.S Plane объявлена внутри cube.h, но после объявления заголовочных файлов, поэтому внутри solution.h я его переопределяю (это нехорошо, но сейчас проблема не в этом)

[Евгений Шатунов]

lipa44, так не пойдет. П3.8 регламента работы сервиса.
Тебе стоит удалить изображения и вставить код текстом. Мне мои глаза дороже, я не буду читать мыльный текст с изображений.

[lipa44]

Евгений Шатунов, прошу прощения, исправил

[Евгений Шатунов]

lipa44, хорошо, спасибо.

// Грани кубика
Plane UpPlane;
Plane DownPlane;
Plane LeftPlane;
Plane RightPlane;
Plane FrontPlane;
Plane BackPlane;

С этим тебе будет тяжело работать. Тебе ведь надо вращать строки на гранях. При этом, крайние строки на гранях приведут к вращению смежной грани. Вот с таким дизайном тебе будет неудобно. Придется писать много лишнего кода.
Легче обозначить просто 6 граней в массиве, попутно определяя закон их смежности на ребрах.
Кубик состоит из 6 граней, в каждой из которых N*N ячеек с цветом. Нас интересует только цвет ячейки. Всего цветов тоже 6. Цвета можно обозначить целыми числами от 0 и до 5.

vector<vector<vector<MiniCube>>> arr;
Это память решения? Этому тут не место. Представь что в другой ситуации ты просто дал кубик игроку покрутить. Зачем игроку это поле для игры? В кубике должны быть только свойства кубика. Еще в кубике должна быть функциональность от кубика. Снова представь игрока с кубиком, нужно ли ему что-то дополнительное чтобы крутить его? Не нужно ведь. Следовательно, у кубика должен быть интерфейс крашения его строк.

#include "cubeSolving.h" // алгоритмы решения
Если мы дадим кубик игроку, то зачем ему еще и информация о его решении? Этому заголовку тут не место.

#include "rubikCube.h"
Вот это уже на месте. Когда ты обращаешься к решениям кубика, тебе уже нужна информация о самом кубике и, собственно, сам кубик.

cubeSolving() = default;
А для кого решать будем? Сюда стоит передать ссылку на кубик, который и будем решать.
В итоге у тебя игрок может взять кубик в произвольном состоянии, положить его в cubeSolving и ткнуть решалке решить.
Решалка должна оперировать на переданном через конструктор кубике. Вращения она должна выполнять используя только публичный интерфейс кубика.

Для того чтобы логика вращений не загружала класс кубика, ее можно вынести в тулкит - в отдельный тип, который через свой конструктор примет обозначенный выше массив из 6 граней по ссылке и предоставит интерфейс для вращения строк. При этом, публичный интерфейс кубика будет просто обращаться к этому тулкиту. Экземпляр тулкита даже в состояние кубика складывать не за чем, т.к. он все равно оперирует данными по ссылке.

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

Answer 1

[Adamos]

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

Comments

[lipa44]

Это намёк на то, чтобы я прописал геттеры и сеттеры или как мне реализовать данное обращение?

Потому что есть мнение, что геттеры и сеттеры также противоречат одному из принципов ООП, а именно, инкапсуляции.

Был бы очень признателен, если бы вы дали идею того, как это реализовать.

[Adamos]

lipa44, вам не нужны геттеры и сеттеры.
Например, для поворота грани вам не нужны цвета всех сторон кубика. Нужна только таблица цветов 5x5 с пустыми углами. В результате получится другая таблица, которую можно вернуть классу состояния кубика. А еще получится, что логика настолько элементарна, что создавать под нее целый класс плюс геттер с сеттером бессмысленно, достаточно создать метод поворота грани. А классу решения уже не потребуются сеттеры для того, чтобы повернуть грань, не так ли?

[lipa44]

Adamos, да, мне не нужны цвета всех сторон кубика, мне нужны только те цвета, которые я переворачиваю, и я использую для этого плоскости, являющиеся векторами, в которых хранятся «мини-кубики», у меня другая архитектура кода, не таблица 5х5, и код (относительно большой) уже написан с использованием ООП, мой вопрос не о том, как оптимальнее решать кубик и как хранить его состояния, а о том, как правильнее использовать ООП, так как в этом и есть суть задания, именно применение ООП для решения задачи, и я хочу понять, как мне правильнее это реализовать

[Adamos]

lipa44, по описанию - вы мечетесь с несколькими довольно разными вопросами.
Насчет архитектуры - правильное использование ООП именно в том, чтобы давать классам ровно столько данных, сколько им реально нужно для работы, и не давать им никакой информации о том, как реализованы внутри другие классы.
У вас, как я понимаю, главная проблема в том, что все эти решатели и поворачиватели все равно работают со всеми данными состояния, влезая в них по локоть. Не получается инкапсуляция, не работает логика ООП. Так может, вам и не нужно делить эту общую работу с едиными данными на разные классы?

[Ben L]

Adamos,

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

Как этого можно добится на практике? В любом случае если есть больше одного объекта, им придется взаимодействовать и одному из них придется получить свойства от друнгого.

[Евгений Шатунов]

Ben L,

и одному из них придется получить свойства от друнгого.

минуя публичный интерфейс и, собственно, инвариант типа?

[Adamos]

Ben L, например, может быть известная обоим классам структура, которую класс, имеющий приватные поля, умеет заполнять, а тот, которому понадобились данные - разбирать. Так она не завязана напрямую на приватные данные класса и может быть более абстрактной. Впрочем, для функций, которым все равно нужен весь кубик, этот вариант не особенно подходит.

[Ben L]

Евгений Шатунов,

минуя публичный интерфейс

Можно добавить getter-ы в interface.

[Ben L]

Adamos, согласен с предложенным вами методом. Только если это не "Hello world" то придется делать много таких методов (а иногда даже добавить новые классы) и в какой то момент сдаешься и просто делаешь getter-ы (Может это только у меня так :( ).

[Adamos]

Ben L, если это не Hello world, грамотное применение ООП как раз позволяет написать основную логику почти человеческим языком, а вот уже в названных по-человечески методах нужных классов опускаться до реального перемешивания байтиков. Здесь у ТС половина проблемы в том, что задача зациклена на одних и тех же данных, и разделять их интерфейсами тупо незачем.

[Евгений Шатунов]

Ben L, видимо с термином инварианта ты не знаком.

Можно добавить getter-ы в interface.

Еще раз. Минуя публичный интерфейс типа?
Ты точно понимаешь мои слова? Что такое публичный интерфейс типа?

[Ben L]

Евгений Шатунов,

Ты точно понимаешь мои слова?

Судя по вашим вопросов, похоже что нет.

За ссылку спасибо, интересно было прочитать. Попробую применить на практике (хотя не уверен что получится).

[Евгений Шатунов]

Ben L, Давай коротко опишу суть без ссылок.
Во время определения типа задается несколько интерфейсов, среди которых есть родительский интерфейс типа, публичный интерфейс, интерфейс наследников типа и приватный интерфейс типа. Интерфейс - это форма обращения, это набор функций, которые могут быть использованы для изменения состояния экземпляра типа.
Состояний у типа тоже может быть несколько: все те же родительское состояние, публичное состояние, приватное состояние, состояние наследников.
Терминами C++ это все выражается через определение области доступа. Функции в области protected: формируют интерфейс наследников. Поля в области private: формируют приватное состояние. Соответственно, публичный интерфейс типа определяется через функции в области public:. При этом, даже если в публичном интерфейсе есть константная функция-геттер, которая просто возвращает константную ссылку на приватное поле, то это не доступ к приватному полю. Это именно публичный интерфейс, который строго ограничивает возможности работы с состоянием экземпляра и именно так обеспечивает инвариантность этого состояния.

Adamos в своем ответе писал о том, что необходимость обращения к приватному состоянию экземпляра из стороннего кода является ярким признаком плохого дизайна. Часто плохой дизайн реализуется через дружественность, поэтому дружественность так часто и обличается признаком плохого дизайна.
В ответ на твой вопрос "Как этого можно добиться на практике?" можно сказать что плохой дизайн следует просто исправлять.

Answer 2

[Saboteur]

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

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

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

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