谁应该知道对方？

我总是会与谁应该知道另一个人混淆。谁应该知道对方？

例如：

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)

我想我最终会“抽象”太多，因为我拥有各种各样的适配器，所以没有人知道任何人。

来源

2011-11-23 Joe McGrath

取决于谁有专业知识。

如果你唯一可以画的是圆圈，那么当然你可以把它放在Canvas的位置上。如果Canvas有一个方法来绘制通用的Shape s，那么它就落在Shape的各个子类中绘制自己。例如，一个圆圈肯定知道如何在画布上绘制自己。我怀疑一个画布本身就知道如何绘制一个圆，除非你对函数进行了硬编码，这有点杀死了多态的整个想法。

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

来源

2011-11-23 04:18:39

如果画布改变了怎么办？比你不得不更改圈子代码而不是只是画布代码。 –

取决于您是否使用画布的抽象 –

@Joe无论如何您都必须更改代码。如果更改画布，则必须修改'Canvas'中的一组方法，或者修改每个形状类中的方法。无论哪种方式，修改“Circle”类中与圆有关的代码比在“Canvas”类中修改代码更有意义。另外，为什么画布会改变？它的接口可能不得不保持更改以避免打破呼叫者。 –

像大多数设计问题一样，答案是，这取决于。 :-)

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

对于像保存这样的事情，它又取决于......它可能对事物知道如何将自己序列化为像流的抽象这样的事物有好处，但是有时候，最好不要将实体耦合到这样的琐事像序列化这样的事情......

来源

2011-11-23 04:20:49

对于你正在创建的类，你通常会让它们自己完成工作。一个Circle将吸引到Canvas，所以将Rectangle。这样，如果他们都是Shape的子类，他们可以通过一个Shape界面来绘制自己。保存也是一样。这是可扩展的 - 您在设计Canvas类时不需要猜测所有可能的形状。

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

来源

2011-11-23 04:41:03 devil

谁应该知道对方？

回答

相关问题