继承模式

Question

我发现我的命名惯例相当麻烦.我似乎过多地重复使用了孩子的具体名字.在我的下面的例子中,我有一个Widget,它有一个连接,它有一个配置.这些对象中的每一个都具有Foo和Bar类型的专用类.

所以我的FooWidget有一个Foo-Connection,它有一个Foo-Config.对于Bar来说也一样.在C++中,我最终得到了九个不同的头文件.

• widget.h
• connection.h
• config.h中
• foo_widget.h
• foo_connection.h
• foo_config.h
• bar_widget.h
• bar_connection.h
• bar_config.h

我不能帮助,但看看这感觉它是不对的.我的直觉告诉我需要改变一些事情.这就像有一个设计模式可以利用.但我找不到更好的解决方案.

所以我想我的问题如下:是否有一种设计模式可以改善这种设计？

- 我正确地纠正了我的问题.请原谅,随着问题本身变得更加明确,我会更新.

Answer 1

首先，这样做并没有什么错。一般来说，许多人喜欢为每个标头放置一个类。如果您不喜欢查看这么多标题，您可以按目录或项目树过滤器等组织它们。

这都是风格问题。只要功能不受影响，最好的选择就是您所拥有的那种有趣感觉的功能，对于将来支持您的代码的人们来说也是如此。也许这个答案会让你不再有那种有趣的感觉，也可能不会。

其次，这很大程度上取决于每个类的使用。如果Foo和Bar类很小，可以将它们放在包含封装类的标头中。也许为了父类添加一个前向声明，并在标头底部完成声明。如果它们都是相关的（例如FooConnection是 的子类Foo），则会加分，因为这会缩短声明空间。

如果它们是相对较小的类，则在定义中声明Foo和类为其基类可能没有什么坏处。Bar然后就没有了FooConnection——它实际上是一个Connection::FooConnection. 在这种情况下，Connection它不仅定义了 的基础FooConnection，而且还拥有它的定义。这意味着每次您FooConnection在代码中使用 a 时，您都是在 a 的上下文中思考Connection。我自己很少这样做，主要是因为我不喜欢Connection::一直打字，而且还因为很少有情况我只在一个上下文中使用一个类。

如果封装的类是protected或private，那么它们仅由父类本身使用（以及friend类，也许还有子类，你有什么）。然后，由于建立了有限的上下文，并且如果类声明很小（<50 或 <100 行），您可以在其中FooConnection声明并仍然保持可读性。BarConnectionConnection

加分点：如果您最终在类内声明类，则可以利用命名空间分离。我不知道这些类的用途，但我猜测FooConnection连接本身不是连接，而是Foo属于Collection. 那么您可以为每个、和声明一个Foo和 一个类。BarWidgetConnectionConfig