【发布时间】:2021-03-15 17:28:45
【问题描述】:
我和我的同事对于这是否遵循策略模式存在分歧。
我们有一个反应组件List,它需要一个具有以下形状的“策略”道具:
interface ListStrategy {
renderItem: (index: number) => React.ReactNode
itemCount: number
}
我们有一些函数可以创建一个“策略”来以某种方式呈现列表。例如,我们有以下策略构造函数。
createGroupedListStrategy(...args: GroupedListStrategyArgs): ListStrategy
createFlatListStrategy(...args: FlatListStrategyArgs): ListStrategy
createTreeListStrategy(...args: TreeListStrategyArgs): ListStrategy
我发现了很多示例,其中策略的构造函数要么不期望参数,要么期望每个策略都使用相同的参数。但是每个上面的构造函数都期望不同的参数。 createGroupedListStrategy 期望作为选项的函数可以在策略内部使用,以将项目与其组匹配。 createTreeListStrategy 期望一个可用于访问项目子项的函数作为选项。
由于构造函数如此不同,我的同事开始怀疑这些策略是否在策略模式的定义所谈论的意义上可以互换。但我的观点是,一旦策略被实例化,它们就可以毫无问题地互换。
谁能解决这个问题?我真的很好奇。
【问题讨论】:
-
构造函数无所谓,一个策略重要的是它是否有一个统一的接口。通常,您可能拥有像
handler这样的属性,这是可能会有所不同的策略。然后代码会调用类似handler.doStuff(foo, bar)的东西。如果您所有的策略都有一个带有两个参数的duStuff方法,那么这就是您所需要的。构造函数是正交的。理想情况下,您希望从工厂生产它们,但最终的想法是,拥有策略的班级并不是制定策略的班级。因此,您将操作与类解耦。 -
是的,它仍然是策略模式。调用者如何构建策略并不重要,重要的是如何在上下文中使用所选策略。 (当然,正如@VLAZ 所说,这些实际上是代码中的不同区域)。
标签: javascript reactjs typescript oop strategy-pattern