设计策略、类关系答案

【问题标题】：Design strategy, class relationships设计策略、类关系
【发布时间】：2014-05-26 14:03:16
【问题描述】：

我有一个具有以下结构的应用程序：

（已删除图片，我无权发布图片。请参阅此处：http://s15.postimg.org/98qc3p7uz/Capture.png）

所以'App'持有Manager实例，Manager持有'Connection'的vector，它们各自持有Protocol，每个Protocol持有通信类。所有通信类都引用一个 HAL 类。

此时，通信类构造函数获取一个 HAL 实例作为单例，例如。 hal = HAL::GetInstance()。

为了使开发和测试更容易，我想删除这种依赖关系。依赖注入模式似乎很适合这个，因为它允许我使用假 HAL。

但是，我认为通信类不应该与 HAL 做任何事情，协议类和连接也是如此。

但是，主“App”类确实有一个引用，但我不确定是否将其传递给 Manager->Connections[x]->Protocol->Communication。

也许我可以将它抽象出来，让 Manager 引用 HAL，然后每个连接都可以有一个指向 Manager 的父指针，但这似乎只是为了提供 HAL 而变得混乱和过于复杂类对通信的引用。

有没有更好的方法来做到这一点？

【问题讨论】：

我最好的建议是：废弃所有的类，写出你需要的代码，仅此而已。经理是干什么的？您将在 Connections 对象中拥有多少个协议？哎呀，您将拥有多少个连接？为什么通信是一个对象？它有什么作用？最有可能的是，您可以消除 90% 的代码，并拥有一个更具可读性和可测试性的程序。想想你想让你的程序做什么，而不是如何抽象地建模整个世界。
“经理”创建连接。单个连接需要单个协议（因为它们可能正在与不同的设备通信），并且协议希望发送数据包而不担心如何发送它们，因此每个协议都需要一个通信对象。我猜通信和协议可以合二为一。
你的程序有多少个连接？有多少种不同的协议？除非您尝试构建整个该死的互联网，否则这个类、继承和 OOP 的迷宫有什么用途？
在 64 和 100 个连接之间以及一个连接可以使用的 3 种不同协议（一旦建立连接就不能更改）。但是，只有一个 HAL。

标签： c++ class oop

【解决方案1】：

您可以让管理器创建Connection、Protocol、Communication 和HAL 的实例。然后 Manager 将它们全部连接起来。非常简单的 C++ 示例：

Manager::createEverything()
{
    Connection connection;
    Protocol protocol;
    Communication communication;
    HAL hal;

    communication.setHal(hal);
    protocol.setCommunication(communication);
    connection.setProtocol(protocol);
}

你也可以使用依赖注入来创建不同的HAL-implementations。类设计可能如下所示：

以上内容很简单，但应该给你一个想法。更多想法：

使用Factory 创建不同类型的IHAL
使用Builder Pattern 完成整个创建和聚合操作

【讨论】：