Question

我总是对谁应该了解对方感到困惑。

例如：

Circle.Draw(&canvas)或Canvas.Draw(&circle)

或Draw(&canvas, &circle)

EmployeeVector.Save(&file)或File.Save(&employee_vector)

甚至还是

  void operator() (Employee e) { Save( e.Serialize();}
  for_each(employees.begin(), employees.end(),File)

我认为在我拥有各种适配器的地方，我最终会“抽象”，所以没有人知道任何人。

Answer 1

取决于谁拥有专业知识。

如果你唯一可以绘制的是圈子，那么当然你可以把它放在Canvas中并且在你的路上。如果Canvas有一个绘制泛型Shape的方法，那么它将落在Shape的各个子类上以绘制自己。例如，圆圈肯定知道如何在画布上绘制自己。我怀疑画布本身知道如何画圆，除非你硬编码功能，这有点杀死了多态的整个想法。

出于同样的原因，矢量可能知道如何将自己保存到文件中，但我怀疑文件知道如何处理矢量。但是向量可以包含各种各样的东西，因此它应该将大部分工作委托给它的实际元素。所以for_each想法可能是最好的。

Answer 2

与大多数设计问题一样，答案是，这取决于。： - ）

知道如何画自己的东西有意义吗？可能。同样可能的是，其他东西知道如何绘制它。如果对象是图形实体，它可能应该知道如何绘制自己。

至于保存之类的东西，它又取决于......知道如何将自己序列化为像流一样的抽象，这也是一件好事，但有时，最好不要将实体与这些微不足道的事情联系起来像序列化....

Answer 3

对于您正在创建的课程，您通常会让他们自己参与工作。 Circle会将自己绘制到{{1}}上，Canvas也是如此。这样，如果它们都是Rectangle的子类，它们可以通过Shape接口绘制自己。保存也是一样的。这是可扩展的 - 在设计Shape类时，您不需要猜测所有可能的形状。

对于“依赖”的情况，对我来说，它通常涉及某些库已经定义的类的实用方法。例如，保存/加载常用的STL数据结构，如map，set，vector等;通过Canvas实用程序类和File方法。

谁应该了解对方？

3 个答案: