C++的一些设计问题答案

【问题标题】：Some design issues with C++C++的一些设计问题
【发布时间】：2011-08-05 12:35:43
【问题描述】：

我在这里有以下两难境地：我有几个类，比如说 A、B、C 和 D。A 有一个公共接口，并且与 B 有一个 has-a 关系（就像 A 有一个类型的成员变量B）A的方法之一是返回这个B对象，B只是一个暴露一些方法的类，C是另一个暴露其他方法的类，D是一个单例对象。 D 的公共接口具有对 C 类对象的引用（如果您喜欢更多的指针）。

所以，很明显，当我想在这一步绘制关系图时，我会在 A 和 B 之间建立一个关系，而 C 会放在图上，而与其他两个之间没有可见的关系。所以，这是基于头文件（.h），其中包含 A、B、C 类的声明。我现在对 D 有点困惑。

另一端：

A 和 B 的实现（在 .cpp 文件中）都严重依赖于从类 C 创建的对象（不，C 不是标准的东西，例如列表、字符串、队列，而是我的应用程序中另一个有意义的类)。
A 和 B 的实现都使用带有本地 C 对象的 D 单例。

这是我的问题：

我应该在类图上放置 A、B、C 和 D 之间的什么关系，不包括我已经确定的关系（A 有 - 一个 B）？我对单例 D 与 C 类的关系特别感兴趣。
对于这种情况，普遍接受的方法是什么（当接口没有对象之间的关系时，因为没有关系，但在实现中它们被大量使用）？
如果我根据 Java 而不是 C++ 提出相同的问题，会不会有区别（因为在 java 中，与类相关的所有内容都在一个文件中，因此更容易查看类方法实际使用的内容，而在 C++ 中，您通常只看到标题）。

非常感谢您的指导。

【问题讨论】：

如果您还没有使用前 2 段中的描述绘制您所知道的内容。然后，当您拥有它时，将其添加到您的问题中，这将有助于我们理解这些关系，即使图表不完整。重要的是先画出你所知道的。
混淆源于试图将单例融入原本易于管理的设计中。他们不为任何人所拥有，为任何人所接受，他们在关系图上跺着脚，将其简化为意大利面条。大约 99% 的时间应该避免全局对象；当你确实需要一个时，它几乎肯定也不应该是一个单例，除非你有一些非常奇怪的要求。
关于单身问题：jalf.dk/blog/2010/03/… -- 希望对您有所帮助:)

标签： c++ uml diagram

【解决方案1】：

您应该明确阅读本书Large-Scale C++ Software Design。

它通过引入两种新关系uses-in-the-interface和uses-in-the-implementation特别处理接口和实现之间的依赖关系建模，而不仅仅是传统的“has-a”。

然后，将设计原则应用于此类建模（如隔离、绝缘、封装等）。不过，这确实是一本技术含量很高的书。所以要做好准备！

【讨论】：

【解决方案2】：

您提供的大部分信息应该在以下课程中可以识别图（plantuml 输入）。我希望这能回答第一个问题。

@startuml
class A
A o--> B
A : + method()
A : + B& getB()
A : - B m_B
A --> "getC" D 

class B
B : + method()
B --> "getC" D 

class C
C : + method()

class D <<Singleton>>
D --> "0..n" C
D : + C* getC( int index )
D : - list<C> m_containerOfC

@enduml

关于第二个问题：我认为绘制 UML 图（我想是为了设计）的重点主要是抽象，因此忽略了细节。编写完程序后，再试图用 UML 表达一个完整的 C++ 程序是没有意义的。您可以购买（尝试）为您执行此操作的程序，但我认为这些图表没有用。

第三个问题的答案是，在设计阶段，Java 和 C++ 实现的 UML 应该是相等的，或者至少在很大一部分上是相等的。设计是关于选择和连接设计模式等，这些与语言无关。当您开始详细说明图表以表示更多实现细节（例如，使用的容器类型等）时，选择的实现语言就会发挥作用。但是，在那个阶段，您应该问问自己，您的图表是否让您对自己的设计有足够的信心，然后开始编写代码。

【讨论】：