Чи повинен наслідувати Vector3 від Vector2?

Я створюю пару класів Vector2(X & Y) і Vector3(X, Y & Z), але я не знаю, чи слід Vector3успадковувати Vector2, чи потрібно повторно реалізувати змінні члена m_xі m_yзнову? Які плюси і мінуси кожної сторони (успадкування проти перегляду).

Редагувати: я використовую C ++ (VS2010).

Ні, це не повинно. Єдине, що ви використовували б у спадщині - це компоненти xта yкомпоненти. Методи, які використовуються в Vector2класі, не будуть корисними для Vector3класу, вони, ймовірно, прийматимуть різні аргументи та виконуватимуть операції над різною кількістю змінних членів.

З C ++ ви можете зробити щось цікаве (ви не вказали мову, і ця відповідь здебільшого тому, що я думаю, що приємно бачити альтернативи, хоча я не вважаю, що це корисно в більшості випадків.)

За допомогою шаблонів ви можете зробити щось подібне:

template <class T, class S, int U>
class VectorN
{
    protected:
        int _vec[U];
    public:
        S& operator+=(const S c)
        {
            for(int i = 0; i < U; i++)
            {
                _vec[i] += c.at(i);
            }
            return (S&)*this;
        }
        int at(int n) const
        {
            return _vec[n];
        }
};

template <class T>
class Vec2 : public VectorN<T,Vec2<T>,2>
{
    public:
        T& x;
        T& y;
        Vec2(T a, T b) : x(this->_vec[0]), y(this->_vec[1])
        {
            this->_vec[0] = a;
            this->_vec[1] = b;
        }
};

template <class T>
class Vec3 : public VectorN<T,Vec3<T>,3>
{
    public:
        T& x;
        T& y;
        T& z;
        Vec3(T a, T b, T c) : x(this->_vec[0]), y(this->_vec[1]), z(this->_vec[2])
        {
            this->_vec[0] = a;
            this->_vec[1] = b;
            this->_vec[2] = c;
        }
};

і це можна використовувати так:

int main(int argc, char* argv[])
{

    Vec2<int> v1(5,0);
    Vec2<int> v2(10,1);

    std::cout<<((v1+=v2)+=v2).x;
    return 0;
}

Як я вже говорив, я не вважаю, що це корисно, і це, ймовірно, ускладнить ваше життя, коли ви спробуєте реалізувати точки / нормалізувати / інші речі та спробувати бути загальними з будь-якою кількістю векторів.

Незалежно від швидкості, перше питання, яке ви повинні задати собі при здійсненні будь-якої спадщини, - це якщо ви збираєтеся їх використовувати поліморфно. Більш конкретно, чи існує якась ситуація, коли ви можете побачити себе, використовуючи a, Vector3як ніби це Vector2(що, успадковуючи його, ви прямо говорите, що Vector3 "є -" Vector2).

Якщо ні, то не слід використовувати спадщину. Ви не повинні використовувати спадщину для спільного використання коду. Саме для цього потрібні компоненти та зовнішні функції, а не те, що ви б ділилися між собою будь-яким кодом.

Зважаючи на це, ви можете захотіти прості способи перетворення Vector3 s в Vector2s, і в цьому випадку ви можете написати перевантаження оператора, яка буде неявно усічена в Vector3a Vector2. Але не слід успадковувати.

Ні, оскільки кожен метод потрібно буде відмінити, і ви не матимете користі від наслідування від нього.

Якщо щось, вони могли б реалізувати векторний інтерфейс. Однак, оскільки ви, мабуть, не хочете додавати / sub / dot / dst між Vector2 та Vector3, це матиме небажані побічні ефекти. І мати різні параметри тощо було б клопоту.
Тому я справді не бачу жодних плюсів успадкування / інтерфейсу в цьому випадку.

Прикладом може слугувати рамка Libgdx, де Vector2 і Vector3 не мають нічого спільного між собою, крім того, що мають однотипні методи.

Якщо ви плануєте використовувати SIMD- масиви , ймовірно, найкращі. Якщо ви все ще хочете використовувати перевантаження оператора, ви можете скористатися інтерфейсом / mixin для доступу до базового масиву - наприклад, ось початкова точка, яка має лише (неперевірений) Add.

Зверніть увагу, як я не вказав X/ Y/ Z, кожен VectorXклас успадкував би безпосередньо цей клас - з тих же причин, які вказали інші люди. Проте я багато разів бачив масиви, які використовуються як вектори в дикій природі.

#include <xmmintrin.h>

class Vector
{
public:
    Vector(void)
    {
        Values = AllocArray();
    }

    virtual ~Vector(void) 
    { 
        _aligned_free(Values);
    }

    // Gets a pointer to the array that contains the vector.
    float* GetVector()
    {
        return Values;
    }

    // Gets the number of dimensions contained by the vector.
    virtual char GetDimensions() = 0;

    // An example of how the Vector2 Add would look.
    Vector2 operator+ (const Vector2& other)
    {
        return Vector2(Add(other.Values));
    }

protected:
    Vector(float* values)
    {
        // Assume it was created correctly.
        Values = values;
    }

    // The array of values in the vector.
    float* Values;

    // Adds another vector to this one (this + other)
    float* Add(float* other)
    {
        float* r = AllocArray();

#if SSE
        __m128 pv1 = _mm_load_ps(Values);
        __m128 pv2 = _mm_load_ps(other);
        __m128 pvr = _mm_load_ps(r);

        pvr = _mm_add_ps(pv1, pv2);
        _mm_store_ps(r, pvr);

#else
        char dims = GetDimensions();
        for(char i = 0; i < dims; i++)
            r[i] = Values[i] + other[i];
#endif

        return r;
    }

private:

    float* AllocArray()
    {
        // SSE float arrays need to be 16-byte aligned.
        return (float*) _aligned_malloc(GetDimensions() * sizeof(float), 16);
    }
};

Відмова: Мій C ++ може смоктати, минув час, коли я ним користувався.

Ще одна серйозна проблема, коли Vec3 успадковує від Vec2 або, можливо, спадковує з одного класу Vector: ваш код буде робити багатооперацій над векторами, часто у критичних для часу ситуаціях, і вам дуже важливо переконатися, що всі ці операції проходять настільки швидко, наскільки це можливо - набагато більше, ніж це стосується багатьох інших об'єктів, які не є цілком універсальний або низькорівневий. Хоча хороший компілятор зробить усе можливе, щоб вирівняти будь-які надбавки за спадщиною, ви все ще більше покладаєтесь на компілятор, ніж хочете; натомість я б створив їх як структури з якомога меншими накладними витратами і, можливо, навіть спробував би зробити більшість функцій, які ними користуються (за винятком таких речей, як оператор +, яким реально не допомогти), - глобальні, а не методи на структура. Рання оптимізація, як правило, рекомендується проти, і з відмінних причин,