当班级想要耦合时

Question

我对两个曾经很好地分开的班级有一个问题，但现在他们想结合起来。

无需过多了解问题的具体细节，情况如下：

我曾经有一个包含 3 个空间位置顶点的 Triangle 类。

class Triangle
{
    Vertex a,b,c ; // vertices a, b and c
} ;

程序中有许多三角形实例，因此每个实例都保留了自己的顶点副本。 getArea()、getCentroid() 等成员函数都写在 Triangle 类中，并且由于每个 Triangle实例具有顶点 a、b 和 c 的副本，发现面积或质心不依赖于其他类。理应如此！

然后，出于其他原因，我想转向顶点数组/索引缓冲区样式表示。这意味着所有顶点都存储在位于 Scene 对象中的单个数组中，并且每个 Triangle 仅保留对 Scene 中顶点的引用，而不是顶点本身的副本。首先，我尝试切换为指针：（

class Scene
{
    std::vector<Vertex> masterVertexList ;
} ;

class Triangle
{
    Vertex *a,*b,*c ; // vertices a, b and c are pointers
    // into the Scene object's master vertex list
} ;

如果您想知道这样做的好处，我这样做的原因主要是与共享顶点的三角形有关。如果 *a 移动，则使用该顶点的所有三角形都会自动更新） 。

这将是一个非常好的解决方案！但它不能可靠地工作，因为 std::vector 使指针无效，并且我在类 Scene 中使用 std::vector 作为主顶点列表。

所以我必须使用整数：

class Triangle
{
    int a,b,c ; // integer index values
    // into the Scene object's master vertex list
} ;

但现在我遇到了这个新的耦合问题：为了找到自己的区域或质心，类 Triangle 需要访问 class Scene ，而之前它没有。看起来我已经检查了一些东西，但实际上并非如此。

万年历？

Answer 1

为什么不让 Scene 中的 vector 也只存储指针呢？

std::vector<Vertex *> masterVertexList;

这样，Triangle 就可以继续使用 Vertex *，而您所要做的就是确保在 Scene 中删除指针。 s 析构函数。

Answer 2

您可以将向量传递给其构造函数中的三角形，以便它可以保留对向量的引用。那么它就不需要访问或了解场景。

typedef std::vector<Vertex> VertexContainer;

class Scene
{
    VertexContainer  masterVertexList ;  
} ;  

class Triangle  
{  
    // A references to the vertices contained in Scene.
    // A triangle no longer needs to know anything about a scene
    VertexContainer&   vertexListRef;

    // index into vertexListRef of the triangles points.
    VertexContainer::size_type  a;
    VertexContainer::size_type  b;
    VertexContainer::size_type  c;  

    public:
        Triangle(VertexContainer&           masterVertexList,
                 VertexContainer::size_type x,
                 VertexContainer::size_type y,
                 VertexContainer::size_type z)
            :vertexListRef(masterVertexList)
            ,a(x),b(y),c(z)
        {}
};

Answer 3

在我看来，你的三角形确实取决于你的场景（因为它的顶点都是该特定场景的成员），所以让对象这样做并不可耻。事实上，我可能会给三角形一个强制性的场景*成员。

Answer 4

从非耦合到耦合的变化是您决定尽可能共享顶点的自然结果。以前，每个三角形“拥有”其顶点，并且场景（大概）拥有一堆或三角形。

允许三角形共享顶点会改变基本模型——当/如果一个顶点可能在两个或多个三角形之间共享时，没有一个三角形可以再拥有该顶点。虽然可能（例如，使用像shared_ptr这样的东西）有一个分布式的共享所有权方案，但你现在正在做的事情可能更简单：每个顶点仍然有一个所有者，但是所有者现在是场景而不是单个三角形。

由于三角形现在只是将某些顶点分组到“拥有”集合中的一种便捷方式，而不是拥有顶点本身，因此三角形和拥有其顶点的集合之间的耦合更紧密也就不足为奇了。如果您非常关心它，您仍然可以隐藏共享所有权，以至少保留以前松散耦合的外观。

总体思路相当简单：不是每个三角形都知道保存三角形顶点的场景，而是创建一个结合场景 ID 和顶点索引的顶点代理类，这样三角形就可以像操作顶点代理对象一样操作顶点代理对象。它以前会有顶点对象。您并没有完全消除更紧密的耦合，但是您将更紧密耦合的“知识”隔离到单个类，这仅负责维护松散耦合的外观。

这样做的明显缺点是顶点代理对象可能存储大量冗余数据。例如，任何特定三角形中的所有顶点代理都清楚地表示同一场景中的顶点。如果您为每个顶点代理显式存储场景 ID，则您将存储场景 ID 的三份副本，而不是之前的一份。有时这是值得的，但有时则不然。如果这是一个真正的问题，您可以尝试想出一种方法来避免显式存储场景 ID，但这可能会涉及一些与语言无关（甚至接近）的技巧。

Answer 5

如果您仅在顶点列表的末尾添加或删除，请改用deque。

Answer 6

我不认为这太糟糕了。 Triangle 失去了一些通用性，成为了 Scene 的外围类，但如果它不用作外部接口（并且与内部缓冲区的那种链接表明不是），那就只是自然的演变。

我的解决方案与你的类似，但加了更多的糖。

struct Triangle
{
    Triangle( ... ) { ... }
    Vertex *a(),*b(),*c() ; // trivia: this is valid syntax! Getters adjust…
private:
    size_t ax, bx, cx; // … offsets…
    Scene *client; // … into the Scene object's master vertex list.
} ;

这样，您就不必重新组织内存中的内容，而改编旧代码只需将 () 添加到 ->a 和 .a 等，这可以通过搜索和替换来完成，并且无论如何都改进了 OO 风格。

或者，取消构造函数和 private 并使其成为 POD。

Answer 7

假设您只有一个 Scene，您可以将其设为单例对象并通过静态方法访问顶点列表。

如果您有多个 Scene 对象，则每个 Triangle 恰好属于一个 Scene - 并且它应该“知道”它属于哪个场景。因此，您应该使用 Scene 引用初始化每个 Triangle，并将其存储为类成员。