F# - 工厂方法设计模式
下面是我使用 F# 实现工厂方法设计模式的尝试,同时尝试使其更加实用(即不是直接的 OO 实现)。以下是我的想法:
type ISkateBoard = abstract Model : unit -> string
type SkateBoard =
| Roskopp
| Peters
interface ISkateBoard
with member this.Model() =
match this with
| Roskopp-> "Rob Roskopp..."
| Peters -> "Duane Peters..."
let assemble model : ISkateBoard =
match model with
| "Roskopp" -> Roskopp :> ISkateBoard
| "Peters" -> Peters :> ISkateBoard
| _ -> failwith "no such skateboard model.."
let SkateBoardFactory assemble model = assemble model
let SantaCruzFactory = SkateBoardFactory assemble
这是工厂方法设计模式的适当实现吗?该模式是否在现实世界的 F# 应用程序中使用?
Below is my attempt at implementing the factory method design pattern using F# whilst trying to make it a little more functional (i.e. not a straight OO implementation). Below is what I came up with:
type ISkateBoard = abstract Model : unit -> string
type SkateBoard =
| Roskopp
| Peters
interface ISkateBoard
with member this.Model() =
match this with
| Roskopp-> "Rob Roskopp..."
| Peters -> "Duane Peters..."
let assemble model : ISkateBoard =
match model with
| "Roskopp" -> Roskopp :> ISkateBoard
| "Peters" -> Peters :> ISkateBoard
| _ -> failwith "no such skateboard model.."
let SkateBoardFactory assemble model = assemble model
let SantaCruzFactory = SkateBoardFactory assemble
Is this an appropriate implementation of the factory method design pattern? Is the pattern used in real world F# applications?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我不确定工厂方法设计模式在函数式编程中的用处有多大。
该模式的目标是隐藏对象的创建,以便您可以仅使用对象的抽象表示。
您的工厂方法可以采用具体类型(例如可区分联合)作为参数,而不是字符串。那么工厂的任务就是从具体表示构建抽象表示:
现在,工厂只是一个
SkateBoard -> 类型的函数。 ISkateBoard
。例如(使用 F# 对象表达式):我认为这种方法的好处是您可以在类型的具体表示上做一些工作(例如需要模式匹配的一些计算),但是您可以使用
factory
将具体类型转换为抽象类型。这与函数式编程中的常用方法非常匹配 - 您经常使用一个数据的不同表示形式并在它们之间进行转换(取决于哪种表示形式更适合特定问题)。
I'm not sure to what extent is the factory method design pattern useful in functional programming.
The goal of the pattern is to hide the creation of objects, so that you can work with just an abstract representation of the object.
Your factory method could take a concrete type (e.g. discriminated union) as an argument, instead of string. Then the task of the factory is to build abstract representation from the concrete representation:
Now, a factory would be simply a function of type
SkateBoard -> ISkateBoard
. For example (using F# object expressions):I think that the benefit of this approach is that you can do some work on the concrete representation of the type (e.g. some calculation where you need pattern matching), but then you can use the
factory
to turn the concrete type into an abstract type.This matches quite well with the usual approach in functional programming - you often use differenet representations of one data and transform between them (depending on which representation is better for a particular problem).
正如 Tomas 所说,使用具体类型可以让您在开始使用工厂创建对象之前清理输入并失败。
你会发现很多面向对象的设计模式在函数式编程中消失了。
使用
SkateBoardFactory
您可以创建一个额外的函数来执行您的函数。由于一流的功能,您可以简单地分配
assemble
。Along with what Tomas said, using concrete types allows you to sanitize your input and fail before you start creating objects with your factory.
You will find a lot of design patterns from OO just go away in functional programming.
With
SkateBoardFactory
you create an extra function to execute your function.You can simply assign the
assemble
because of first class functions.