Шаблон треугольника

[Racheengel]

Я имею в виду следующее: у автора есть методы типа

class Triangle{
public:
...
    QVector3D a() const;
...
};


Т.е класс Triangle "заточен" на работу с QVector3D. В общем случае это не годится, и вместо QVector3D придется использовать независимый от имплементации класс-враппер, типа CUniversalVector3D, который уже может быть специализирован для double & float отдельно. Это, в свою очередь, означает смену API:

class Triangle{
public:
...
    CUniversalVector3D a() const;
...
};

только тогда человек сможет "безболезненно" менять имплементации векторов.

[m_ax]

только тогда человек сможет "безболезненно" менять имплементации векторов.

Безболезненно? Вы шутите?) То что Вы сейчас предлагаете - это антипатерн..
Это как минимум не эффективно: приводить суперкласс к частным случаям (QVector3D, arma::vec3).. И как быть с тем, что завтра мне понадобится использовать в качестве вектора /точки другой класс? (например с размерностью больше 3?) Ммм? Будете опять лезть в супервектор и добавлять новый функционал? И так до бесконечности?

Нет уж, нафиг-нафиг)         

[__Heaven__]

Я имел в виду завести point_traits, где определить нужные функции и подсовывать уже его в реализацию одного шаблонного треугольника:

Элегантненько, спасибо

[__Heaven__]

Racheengel, если я правильно вас понял, то сделать больше двух (и даже одного, имхо) наследников будет болью. Так и зачем нам привязка именно к QVector3D не совсем понял.

[__Heaven__]

m_ax, а зачем в аргументы шаблона записывать class PointTraits = point_traits<T> ?

[__Heaven__]

А всё, сообразил, чтобы какой-нибудь Generic можно было вставить

[m_ax]

m_ax, а зачем в аргументы шаблона записывать class PointTraits = point_traits<T> ?

Если понадобится расширить класс харрактеристик (в котором еобходимо передавать более одного шаблона).. Но можно и не писать, если в этом нет необходимости..

[Racheengel]

Racheengel, если я правильно вас понял, то сделать больше двух (и даже одного, имхо) наследников будет болью. Так и зачем нам привязка именно к QVector3D не совсем понял.

Боль будет в любом случае, поскольку изначальный класс завязан на QVector3D , с которым double не получится...
А значит, и весь код, зависящий от этого класса, придется переделать на нечто генерическое с абстрактым вектором.
Но после этого хоть 2, хоть 22 наследника можно делать - все будет более-менее одинаково. Главное API не поломать.

[Racheengel]

Безболезненно? Вы шутите?) То что Вы сейчас предлагаете - это антипатерн..

С каких пор "фасад" стал антипаттерном? O_o

Это как минимум не эффективно: приводить суперкласс к частным случаям (QVector3D, arma::vec3).. И как быть с тем, что завтра мне понадобится использовать в качестве вектора /точки другой класс? (например с размерностью больше 3?) Ммм? Будете опять лезть в супервектор и добавлять новый функционал? И так до бесконечности?

Суперкласс сейчас завязан на QVector3D. Если его привести к CAbstractVector3D, то имплементаций можно ваять сколько угодно - но код, использующий CAbstractVector3D, переписывать не придется

[m_ax]

С каких пор "фасад" стал антипаттерном? O_o

А я сомневаюсь, что это в данном случае именно фасад)

Ну хорошо, как Вы видите себе API абстрактного CAbstractVector3D? Как Вы его будете приводить к QVector3D, arma::vec3, MyCustomPont5D?

[Racheengel]

// Это базовый шаблон-интерфейс, в который передаем T=float/double/whatever...
template<typename T>
class IAbstractVector3D
{
public:
   IAbstractVector3D(T x, T y, T z);

   IAbstractVector3D GetMul(T factor) const  = 0;
   IAbstractVector3D GetSomethingElse(...) const  = 0;
   
   T GetX() const = 0;
   T GetY() const = 0;   
   T GetZ() const = 0;
};

// float-имплементация на основе QVector3D
class CVector3D: public IAbstractVector3D<float>
{
public:
   CVector3D(float x, float y, float z): m_vector3d(x,y,z)
   {}

   IAbstractVector3D GetMul(T factor) const
   {
      QVector3D result = m_vector3d * factor;
      return CVector3D(result.x(), result.y(), result.z());
   }

...

  float GetX() const { return m_vector.x(); }
...

private:
   QVector3D m_vector3d;   
};


// double-имплементация на основе vec3
class CArmaVector3D: public IAbstractVector3D<double>
{
public:
   CArmaVector3D(double x, double y, double z): m_vector3d(x,y,z)
   {}

   IAbstractVector3D GetMul(double factor) const
   {
      CArmaVector3D result = m_vector3d * factor;
      return CArmaVector3D(result.x(), result.y(), result.z());
   }

...

  double GetX() const { return m_vector.x(); }
...

private:
   arma::vec3 m_vector3d;   
};

Примерно так у нас реализованы подобные классы в рабочей либе (сейчас писал по памяти, без компилятора, но в общем идея, думаю, понятна)

[__Heaven__]

Зачем мне реализовывать GetMul?, если везде определён operator*, а если в какой-то экзотической либе не определён, то я могу его определить сам

[Racheengel]

Зачем мне реализовывать GetMul?, если везде определён operator*, а если в какой-то экзотической либе не определён, то я могу его определить сам

Ну, это я для примера привел
В реальности все скорее всего решится через Find & Replace
Даже имплементация через общий интерфейс имеет недостаток того, что в вызывающем коде все равно придется менять флоты на даблы. Поэтому, любое другое решение, кроме замены, будет избыточным

[m_ax]

Примерно так у нас реализованы подобные классы в рабочей либе (сейчас писал по памяти, без компилятора, но в общем идея, думаю, понятна)

Теперь понятно, спасибо)

Думаю, класс точки/вектора - это  немного не тот случай, когда паттерн фассад  оправдан.. Во всяком случае я не вижу никаких преимуществ в данном подходе..
Как я понимаю, пользователь сам должен выбирать удобную для него реализацию класса точки/вектора (с любой из которых сможет однообразно работать класс Triangle) а не переписывать каждый раз весь её функционал, наследуясь от абстрактного предка.
   

[Racheengel]

Во всяком случае я не вижу никаких преимуществ в данном подходе..

Да собственно, их и нет. Единственное, для чего все это городится - чтобы "встык" заменить QVector3D на нечто другое. Но проблема тут в том, что и вызывающий код придется насиловать в любом случае. Либо заменять все вызовы Triangle на IAbstractTriangle, либо переписать на шаблонах... Опять же, возникает вопрос - усилия того стоят?