Вопрос гуру архитектурного дизайна приложений

Плодятся кучу методов, которые транслируются тупо в другой класс

Ну и что?

Например Model наследует интерфейс Drawable, следовательно содержит параметр класс DrawRule, зависимости ростут, классы начинают уметь больно много вещей

ЯННП.

вобщем нарушаются все эти законы. Как не нарушать?

А ты выбирай, какие законы нарушать. Есть, например, закон «do the simplest thing that might possibly work».

P.S. и купи себе спеллчекер, епт.

кстати забыл... класс не должен делать много вещей. Так вот если следовать этому закону, то может получиться так:

void doSomething(){
    SomeClassA a;
    SomeClassB b;
    SomeResultA ra = a.doSomething(m_somethingPrivate);
    SomeResultB rb = b.doSomething(m_somethingPrivate, ra);
    // и т.д.
}

Что-то ты на пустом месте кучу писанины развёл по-моему. Movable, Drawable, SetUserable, UpdateUserPositionable на каждый чих будешь делать интерфейс?

Просто напиши сеттер и всё. void setPosition(const vec3 &position) { this.position = position; } без всяких интерфейсов, наследований, моделей и проксей.

Или подробней опиши, зачем ты это делаешь.

И что ужасного в этом псевдокоде?

Movable нужно, потому что он имеет parent-а, и мы не должны знать конкретную реализацию, ну ты понимаешь... т.е. setParentMovable(Movable* movable)

Куча зависимостей

Такое впечатление, что ты под веществами.

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

Такое впечатление, что ты под веществами.

почему?

Горячечная невразумительная речь.

Реально же невозможно не нарушать правила

Ты нарисовал какой-то псевдокод (который лично мне ничего не говорит) и в ужасе мечешься, вереща «ОН НАРУШАЕТ ПРАВИЛА!!!11». Какие хоть правила он нарушает? Я не вижу в нем нарушения закона Деметры.

Да, закона Деметры он не нарушает, но зависимость очень большая. Когда я начинаю использовать в одном методе кучу классов, которые реализуют какую-то логику. Вот посмотрите только на это:

Mat4 Pivot::modelGlobalMatrix() const // этот же класс с такой же реализацией и в Model
{
    MovableMatrixConstructor mmc;
    return mmc.constructGlobalMatrix(this);
}

Да на такой класс охренеешь юнит тест присать. Да и по сути класс-то ничего не умеет. Этот класс просто композиция разных классов, которые транслируют в них свои методы.

зависимость очень большая

Да где, блин?

MovableMatrixConstructor высчитывает глобальную матрицу. Почему это в отдельном классе?

Почему это в отдельном _классе_? Это подозрительно похоже на процедуру.

то бы небыло дублирования кода в Model

Какого кода? Сформулируй уже задачу (не классы, придуманные тобой, а задачу).

В какой метод я это вынесу? Что бы оба класса Model и Pivot могли заюзать его? ООП-же. Короче жопа какая-то с этими правилами.

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

В какой метод я это вынесу?

В процедуру. Или у тебя ООП головного мозга?

Короче жопа какая-то с этими правилами.

Это не с правилами...

Да скорей всего (((

Что бы не дублировать код и не плодить кучи атрибутов у класса я сделал класс Transform

Вот тут я потерял ход мысли. Что за код будет дублироваться? Реализация setPosition() в каждом конкретном классе, который реализует Movable? Ну сделай миксин типа

class Moveable
{
public:
    Moveable(const vec3 &position) : m_position(position) {}
    virtual ~Moveable() {}

    virtual void setPosition(const vec3 &value)
    {
        m_position = value;
    }

protected:
    vec3 m_position;
};

class Point : public Moveable
{
public:
    Point() : Moveable(vec3(0, 0, 0)) {}

    // ...
};

Ну наследование это хреново. Используйте композицию - говорят все умные книжки. Наследовать только интерфейсы а не реализацию.

Ну, чувак. Ты или крестик сними, или трусы надень. А то у тебя: «Я хочу отнаследовать реализацию, чтобы не писать одинаковую реализацию везде, но только так, чтобы не отнаследовать реализацию».

Или так (ну можно ещё шаблонами причесть), или композиция: Movable-с-дефолтной-реализацией в виде поля Point и метод-заглушка, который реализует Moveable для Point, пробрасывая Point::setPosition() до того поля.

Упоротое ООП и стремление всё прятать за интерфейсами краткости кода не способствует.

Есть еще правила SOLID. Так вот первое гласит: На каждый объект должна быть возложена одна единственная обязанность.

Допустим у меня есть Core, в котором есть DocumentBuilder, и DeviceManager. Впринципе Core сам не создает документы и не управляет устройствами, этим занимаются менеджеры. Core просто делегирует запросы. Можно ли так делать? Что имеется в виду этим правилом?