处理依赖关系

时间:2015-03-10 04:07:09

标签: design-patterns dependencies

将所需的依赖项传递给需要它们的方法而不是将所有依赖项传递给对象构造函数是否被认为是一种好习惯?可以说我有一个需要绘制的对象。将渲染器传递给该对象的draw()方法或者我应该首先将渲染器传递给该对象的构造函数是一个好主意吗?

3 个答案:

答案 0 :(得分:0)

你指的是flyweight pattern,我相信当你的应用程序需要创建大量几乎相似的对象时,应该使用它。

主要使用两个术语:Intrinsic StateExtrinsic state

内在状态内在状态是可以在类成员之间共享的状态。

外在状态 - 外在状态是一种变化,不能在阶级成员之间共享。

将外部参数捕获为方法参数而不是将其作为实例成员的模式称为Flyweight pattern

有关flyweight的更多详情,请访问此文章here

何时考虑使用Flyweight模式。

1。需要创建大量对象,并且需要降低其内存成本。

<强> 2 即可。你的班级设计中有外在的州成员

答案 1 :(得分:0)

最好在需要绘制的对象和渲染器对象之间反转依赖关系,该渲染器对象可能包含方法Draw,其中参数表示需要绘制的对象。

如果我们从示例中抽象出来,那么在方法中提供特定于操作的参数就非常合法。

答案 2 :(得分:0)

您可以使用一个规则 - 如果类实例没有依赖关系则无用,,即依赖关系是&#34;必须有&#34; / mandatory,应将它们传递给构造函数

这个想法是在调用构造函数之后对象应该完全(尽可能)初始化。在完成所有构造函数之后,初始化。

因此应该是使用setter设置的可选依赖项。

相关问题