3

我正在尝试编写一个抽象层来让我的代码在不同的平台上运行。让我举一个我最终想在高级代码中使用的两个类的例子：

class Thread
{
public:
    Thread();
    virtual ~Thread();

    void start();
    void stop();

    virtual void callback() = 0;
};

class Display 
{
public:
    static void drawText(const char* text);
};

我的问题是：我可以使用什么设计模式让低级代码填充实现？以下是我的想法以及为什么我认为它们不是一个好的解决方案：

  1. 理论上，上面的定义highLevel/thread.h和平台特定的实现都没有问题lowLevel/platformA/thread.cpp。这是在链接时解决的低开销解决方案。唯一的问题是低级实现不能向其添加任何成员变量或成员函数。这使得某些事情无法实施。

  2. 一种出路是将其添加到定义中（基本上是 Pimpl-Idiom）：

    class Thread 
{ 
    // ...
private:
    void* impl_data;
}

    现在低级代码可以有它自己的结构或对象存储在 void 指针中。这里的问题是它很难阅读并且编程很痛苦。

  3. 我可以class Thread通过继承来制作纯虚拟并实现低级功能。高级代码可以通过调用工厂函数来访问低级实现，如下所示：

    // thread.h, below the pure virtual class definition 
extern "C" void* makeNewThread();

// in lowlevel/platformA/thread.h 
class ThreadImpl: public Thread
{ ... };

// in lowLevel/platformA/thread.cpp
extern "C" void* makeNewThread() { return new ThreadImpl(); }

    这已经足够整洁了，但是对于静态类却失败了。我的抽象层将用于硬件和 IO 事物，我真的希望能够拥有Display::drawText(...)而不是携带指向单个Display类的指针。

  4. 另一种选择是只使用可以像这样在链接时解析的 C 样式函数extern "C" handle_t createThread()。这对于访问仅存在一次的低级硬件（如显示器）非常简单且非常有用。但是对于任何可能多次出现的东西（锁、线程、内存管理），我必须在我的高级代码中携带句柄，这很难看，或者有一个隐藏句柄的高级包装类。无论哪种方式，我都必须将句柄与高级和低级端的相应功能相关联。

  5. 我最后的想法是混合结构。extern "C"用于仅存在一次的低级内容的纯 C 风格函数。可以多次出现的东西的工厂函数（参见 3.）。但我担心混合的东西会导致不一致、不可读的代码。

对于适合我要求的设计模式的提示，我将不胜感激。

4

3 回答 3

1

您不需要具有与平台无关的基类，因为您的代码一次仅针对单个具体平台编译。

例如，只需将包含路径设置为，并在每个受支持平台的包含目录-Iinclude/generic -Iinclude/platform中都有一个单独的 Thread 类。

您可以（并且应该）编写与平台无关的测试，默认编译和执行，以确认您的不同平台特定实现遵循相同的接口和语义。

PS。正如 StoryTeller 所说，Thread 是一个不好的例子，因为已经有一个可移植的std::thread. 我假设您确实需要抽象一些其他特定于平台的细节。

聚苯乙烯。您仍然需要弄清楚通用（与平台无关的）代码和特定于平台的代码之间的正确划分：决定什么去哪里没有灵丹妙药，只有重用/复制、简单代码与高度参数化代码之间的一系列权衡，等等

于 2016-08-01T12:41:28.350 回答
0

您似乎想要您的Thread类的值语义，并且想知道在哪里添加间接以使其可移植。所以你使用 pimpl 成语，和一些条件编译。
根据您希望构建工具的复杂性所在的位置，以及如果您想让所有低级代码尽可能自包含，您可以执行以下操作：

在您的高级标题Thread.hpp中，您定义：

class Thread
{
  class Impl:
  Impl *pimpl; // or better yet, some smart pointer
public:
  Thread ();
  ~Thread();
  // Other stuff;
};

然后，在您的线程源目录中，您按照这种方式定义文件：

Thread_PlatformA.cpp

#ifdef PLATFORM_A

#include <Thread.hpp>

Thread::Thread()
{
  // Platform A specific code goes here, initialize the pimpl;
}

Thread::~Thread()
{
  // Platform A specific code goes here, release the pimpl;
}

#endif

构建Thread.o变得简单，只需获取Thread_*.cppThread 目录中的所有文件，并让构建系统-D为编译器提供正确的选项。

于 2016-08-01T13:04:00.607 回答
0

我很好奇，像下面这样设计这种情况会是什么感觉（只是坚持线程）：

// Your generic include level:
// thread.h
class Thread : public 
#ifdef PLATFORM_A
    PlatformAThread
#elif PLATFORM_B
    PlatformBThread
// any more stuff you need in here
#endif
{  
    Thread();
    virtual ~Thread();

    void start();
    void stop();

    virtual void callback() = 0;
} ;

其中不包含任何有关实现的内容，仅包含接口

然后你有：

// platformA directory 
class PlatformAThread { ... };

这将自动导致当您创建“通用”Thread对象时，您会自动获得一个依赖于平台的类，该类会自动设置其内部结构，并且可能具有特定于平台的操作，当然您的PlatformAThread类可能派生自Base具有共同事物的通用类你可能需要。

您还需要设置构建系统以自动识别平台特定目录。

另外，请注意，我倾向于创建类继承的层次结构，有些人建议不要这样做：https ://en.wikipedia.org/wiki/Composition_over_inheritance

于 2016-08-01T13:06:56.760 回答