c++ - 通过策略(策略)模式启用多个后端

标签 c++ design-patterns architecture

研究员:

我正在研究一组算法，这些算法作用于“Body”、“Spacecraft”、“Planet”等类。每个实例的构建都可以通过不同的后端来完成。例如，我可以使用大量库(如 NASA 的 SPICE 系统)计算行星位置，我还可以使用大量数据源和库“计算”天体的半径。

我的算法集合应该忽略数据源:例如，如果我想计算 eclipse 的时间，我只关心物体的相对位置和它们的半径(不管我从哪里得到这些数字来自)。

在下面附带的代码中，我使用 Policy 类来参数化两个不同的后端(已简化，因为这是一个示例)。我有兴趣问以下问题:

  • 为此目的使用策略模式是否合理？
  • 如何删除类构造函数中包含的实现细节并将它们移至 Pimpl 构造函数(参数化 BodyImpl？)

代码有点冗长，但我想“说清楚”我的理由。

谢谢。

我使用 g++ 4.7.2 成功编译了下面的代码，如下所示:

g++ backends.cpp -std=c++11 -Wall -O2

(注意它使用了一些 c++11 结构，比如 auto)。

/**
   Is it reasonable to parameterize different data back-ends using the
   Policy Pattern? 

   The goal is to provide a unified interface to different classes
   (e.g., `Body`, `Star`, `Spacecraft`). However, the construction of
   specific instances requires data which can originate from different
   sources.

   For example, a "Body" has a radius and a gravitational parameter
   (called "gm"). But these values can come from different sources
   (different libraries which provide this kind of information).

   Say that library 1 (called "Spice") is capable of providing the
   radius given the body name:

   double the_radius = compute_radius_with_spice("Mercury");

   On the other hand, you could be using another library, which
   computes the radius with a completely different interface, and with
   completely different requirements:

   double radii[3];
   compute_the_radius_with_another_library("Mercury", radii)
   double the_radius = (radii[0] + radii[1] + radii[2]) / 3.0;

   Of course, the values computed with either library are similar, but
   different enough to make a difference. What matters is CONSISTENCY
   (stick to one back-end).
*/


#include<iostream>
#include<string>
#include<vector>
#include<memory>

/* Say that this is the uniform interface that I want to provide.*/
template<typename DataPolicy>
class Body:
  private DataPolicy{
public: 
  Body(const std::string& name);
  Body(const Body& body);
  ~Body();
  std::string name() const;
  double radius() const;
  double gm() const;
private:
  class BodyImpl * pimpl_;;
  //  std::unique_ptr<BodyImpl> pimpl_;
};

/* I use the pimpl_ idiom to hide the implementation */
struct BodyImpl{
  std::string m_name;
  double m_radius;
  double m_gm;  
  BodyImpl(const std::string& name):
    m_name(name){    
  }
};

/* The constructor has to build the pimpl step by step using the data
   policy as a data source. */
template<typename DataPolicy>
Body<DataPolicy>::Body(const std::string& name):
  pimpl_(new BodyImpl(name)){
  pimpl_->m_radius = DataPolicy::get_radius(name);
  pimpl_->m_gm = DataPolicy::get_gm(name);
}

template<typename DataPolicy>
Body<DataPolicy>::Body(const Body& body):
  pimpl_(new BodyImpl(body.name())){
  pimpl_->m_radius = body.radius();
  pimpl_->m_gm = body.gm();
}

template<typename DataPolicy>
Body<DataPolicy>::~Body(){
  delete pimpl_;
  pimpl_ = 0;
}

/* The methods are simple forwarding calls to the implementation (in
   reality it is not as simple as returning a primitive data type)*/
template<typename DataPolicy>
std::string Body<DataPolicy>::name() const{
  return pimpl_->m_name;
}

template<typename DataPolicy>
double Body<DataPolicy>::radius() const{
  return pimpl_->m_radius;
}

template<typename DataPolicy>
double Body<DataPolicy>::gm() const{
  return pimpl_->m_gm;
}


/* Now I create a concrete data policy - in reality this would be more
   extensive and complex, but the idea remains the same */
struct SPICEDataPolicy{
  static double get_radius(const std::string& name){
    std::cout<<"SPICEDataPolicy: calculating radius for "<<name<<std::endl;
    return 0;
  }
  static double get_gm(const std::string& name){
    std::cout<<"SPICEDataPolicy: calculating gm for "<<name<<std::endl;
    return 0;
  }
};

/* This is another data policy - it provides the same data but it may
   call a completely different underlying library, and calculate the
   values using completely different logic */
struct OtherDataPolicy{
  static double get_radius(const std::string& name){
    std::cout<<"OtherDataPolicy: calculating radius for "<<name<<std::endl;
    return 0;
  }
  static double get_gm(const std::string& name){
    std::cout<<"OtherDataPolicy: calculating gm for "<<name<<std::endl;
    return 0;
  }
};


/* My algorithms can now use the objects via the unified interface */
template<typename T>
void individual_complex_calculation(const Body<T>& body){
  // Regardless of the body's data policy, I know I can call a uniform interface.
  std::cout<<"I am making a complex calculation involving "<<body.name()<<"."<<std::endl
       <<"[This is my radius: "<<body.radius()<<", "
       <<"and this is my gm: "<<body.gm()<<"]"<<std::endl;
}
template<typename T>
void complex_calculation(const std::vector<Body<T> > bodies){
  for(auto it=bodies.begin(), finished=bodies.end(); it!=finished; it++)
    individual_complex_calculation(*it);
}

int main(){  
  /* Now I can create a vector of bodies which are consistent with one
     another */
  std::cout<<"========== Using 'SPICEDataPolicy =========='"<<std::endl;
  std::vector<Body<SPICEDataPolicy> > bodies;
  bodies.push_back(Body<SPICEDataPolicy>("Mercury"));
  bodies.push_back(Body<SPICEDataPolicy>("Venus"));
  bodies.push_back(Body<SPICEDataPolicy>("Earth"));
  bodies.push_back(Body<SPICEDataPolicy>("Mars"));

  complex_calculation(bodies);

  /* And even create other set of bodies consistent with one another,
     but inconsistent with the previous ones.*/
  std::cout<<"========== Using 'OtherDataPolicy' =========="<<std::endl;  
  std::vector<Body<OtherDataPolicy> > other_bodies;
  other_bodies.push_back(Body<OtherDataPolicy>("Mercury"));
  other_bodies.push_back(Body<OtherDataPolicy>("Venus"));
  other_bodies.push_back(Body<OtherDataPolicy>("Earth"));
  other_bodies.push_back(Body<OtherDataPolicy>("Mars"));

  complex_calculation(other_bodies);
  return 0;
}

./a.out 的输出:

========== Using 'SPICEDataPolicy =========='
SPICEDataPolicy: calculating radius for Mercury
SPICEDataPolicy: calculating gm for Mercury
SPICEDataPolicy: calculating radius for Venus
SPICEDataPolicy: calculating gm for Venus
SPICEDataPolicy: calculating radius for Earth
SPICEDataPolicy: calculating gm for Earth
SPICEDataPolicy: calculating radius for Mars
SPICEDataPolicy: calculating gm for Mars
I am making a complex calculation involving Mercury.
[This is my radius: 0, and this is my gm: 0]
I am making a complex calculation involving Venus.
[This is my radius: 0, and this is my gm: 0]
I am making a complex calculation involving Earth.
[This is my radius: 0, and this is my gm: 0]
I am making a complex calculation involving Mars.
[This is my radius: 0, and this is my gm: 0]
========== Using 'OtherDataPolicy' ==========
OtherDataPolicy: calculating radius for Mercury
OtherDataPolicy: calculating gm for Mercury
OtherDataPolicy: calculating radius for Venus
OtherDataPolicy: calculating gm for Venus
OtherDataPolicy: calculating radius for Earth
OtherDataPolicy: calculating gm for Earth
OtherDataPolicy: calculating radius for Mars
OtherDataPolicy: calculating gm for Mars
I am making a complex calculation involving Mercury.
[This is my radius: 0, and this is my gm: 0]
I am making a complex calculation involving Venus.
[This is my radius: 0, and this is my gm: 0]
I am making a complex calculation involving Earth.
[This is my radius: 0, and this is my gm: 0]
I am making a complex calculation involving Mars.
[This is my radius: 0, and this is my gm: 0]

编辑:

我试验了另一种基于“特征”和“策略”的实现。感觉干净多了，但我仍然很好奇你对它的看法。

以下代码使用与上面相同的命令行参数进行编译。

/**
   Multiple back-ends implemented as a mix of trait classes and policies.

   This seems to be a better implementation because there is a clear
   path to extend the different back-ends, and the class front-end is
   completely independent from its back-end.

*/

#include<iostream>
#include<string>
#include<vector>
#include<memory>

// forward declaration of the trait "data_traits"
template<typename T>
struct data_traits{
};

// each class would be defined as follows (with forward declaration of
// its implementation class)
template<typename T>
struct BodyImpl;

template<typename T>
class Body{
public:
  Body(const std::string& name);
  std::string name() const;
  double radius() const;
  double gm() const;
private:
  std::unique_ptr<BodyImpl<T> > pimpl_;
};

// each class would be implemented in a cpp file with the following
// structure (notice full independence from any back-end)
template<typename T>
struct BodyImpl{
  std::string m_name;
  double m_radius;
  double m_gm;
  BodyImpl(const std::string& name):
    m_name(name){
    m_radius = data_traits<T>::get_radius(name);
    m_gm = data_traits<T>::get_gm(name);
  }    
};

/* public interface simply forwards to pimpl */
template<typename T>
Body<T>::Body(const std::string& name):
  pimpl_(new BodyImpl<T>(name)){
}

template<typename T>
std::string Body<T>::name() const{
  return pimpl_->m_name;
}

template<typename T>
double Body<T>::radius() const{
  return pimpl_->m_radius;
}

template<typename T>
double Body<T>::gm() const{
  return pimpl_->m_gm;
}


/* the user or library writer can then write specific back-ends
   according to the following interfaces */
struct SPICEBackEnd;
template<> struct data_traits<SPICEBackEnd>{
  static double get_radius(const std::string& name){
    std::cout<<"[SPICE] get radius for "<<name<<std::endl;
    return 0;
  }
  static double get_gm(const std::string& name){
    std::cout<<"[SPICE] get gm for "<<name<<std::endl;
    return 0;
  }
};

/*another back-end*/
struct OtherBackEnd;
template<> struct data_traits<OtherBackEnd>{
  static double get_radius(const std::string& name){
    std::cout<<"[OTHER] get radius for "<<name<<std::endl;
    return 0;
  }
  static double get_gm(const std::string& name){
    std::cout<<"[OTHER] get gm for "<<name<<std::endl;
    return 0;
  }
};

/* The algorithms can be obvlivious to the back-end used */
template<typename T>
void complex_calculation(const std::vector<Body<T> >& bodies){
  for(auto it=bodies.begin(), finished=bodies.end(); it!=finished; it++){
    std::cout<<"Body "<<it->name()<<" (r="<<it->radius()<<", mu="<<it->gm()<<")"<<std::endl;
  }
}


int main(){
  std::vector<Body<SPICEBackEnd> > spice_bodies;
  spice_bodies.push_back(Body<SPICEBackEnd>("Mercury"));
  spice_bodies.push_back(Body<SPICEBackEnd>("Venus"));
  spice_bodies.push_back(Body<SPICEBackEnd>("Earth"));
  spice_bodies.push_back(Body<SPICEBackEnd>("Mars"));

  complex_calculation(spice_bodies);

  std::vector<Body<OtherBackEnd> > other_bodies;
  other_bodies.push_back(Body<OtherBackEnd>("Mercury"));
  other_bodies.push_back(Body<OtherBackEnd>("Venus"));
  other_bodies.push_back(Body<OtherBackEnd>("Earth"));
  other_bodies.push_back(Body<OtherBackEnd>("Mars"));

  complex_calculation(other_bodies);
}

最佳答案

有趣的问题。

有许多不同的方法值得考虑，也许跳出最多的是 Abstract Factory .为什么？因为您可以构建符合一组基本接口(interface)的对象族，然后使用它们而无需经常检查您应该做什么。另外，因为您强调了一致性。

我在 Strategy 中看到的问题是，它通常是一种封装做同一件事的不同方法的方法。例如，如果我们在做工资单，每个人都有一个系统同意应税工资是扣除总额，但这个值的推导方式可能不同(坦率地说，在工资单中，抽象工厂可能也有意义，因为你不会怀疑需要不止一个变体，一旦你起草了一个变体，所有其他变体都来自同一个家族是很重要的)。

这里另一个有趣的设计元素是您需要计算一些非常不同的实体的一些通用指标。这是 Java 中的接口(interface)和/或 Objective-C 或 Scala 等语言中的特征的巨大优势之一(来自可笑的辉煌 self )。我已经有一段时间没有写过很多 C++ 了，但我知道有一些方法可以做一些像 traits 这样的事情，例如Mixins (a la James Coplien)。

关于c++ - 通过策略(策略)模式启用多个后端，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14489919/

上一篇：c++ - 使用 lib.a 文件调试链接错误

下一篇：java - 在 OpenCv4Android 中存储测试数据

相关文章：

c++ - 更改dll对windows的依赖

php - 框架比较和开销

c# - const int 列表而不是枚举

ios - 在 iOS 游戏中发送信号

c# - 如何获取所有实现相同接口(interface)的类？

architecture - 组件、模块和子系统

java - 写完用户需求文档之后做什么？

c# - 如何将字符串从 native 代码返回到 Windows Azure 中的托管代码？

c++ - 复制 std::map 的子集

c++ - 在opencv中以flo​​at格式获取stddev的值

©2024 IT工具网  联系我们