如何解决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#应用程序中使用该模式吗?
解决方法
我不确定工厂方法设计模式在函数式编程中有用到什么程度。
模式的目标是隐藏对象的创建,以便您可以仅使用对象的抽象表示来工作。
以功能方式使用F#时,大多数时候将使用具体的表示形式。例如,这使您能够在滑板类型上进行图案匹配。
当然,F#允许您将功能样式与面向对象样式混合在一起。出于某些目的,OO风格在F#中效果很好。在这种情况下,您的方法看起来很合理。
您的工厂方法可以采用具体类型(例如,区分联合)代替字符串。然后工厂的任务是从具体表示形式构建抽象表示形式:
// Abstract representation of the data
type ISkateBoard =
abstract Model : unit -> string
// Concrete representation of the data
type SkateBoard =
| Roskopp
| Peters
现在,工厂将只是simply2ѭ类型的函数。例如(使用F#对象表达式):
// Transform concrete representation to abstract representation
let factory concrete =
match concrete with
| Roskopp -> { new ISkateBoard with
member x.Model() = \"Rob Roskopp...\" }
| Peters -> { new ISkateBoard with
member x.Model() = \"Duane Peters...\" }
我认为这种方法的好处是您可以对类型的具体表示做一些工作(例如需要模式匹配的一些计算),但是您可以使用the4ѭ将具体类型转换为抽象类型。
这与函数式编程中的常规方法非常匹配-您经常使用一个数据的不同表示形式并在它们之间进行转换(取决于哪种表示形式更适合特定问题)。
,与Tomas所说的一样,使用具体类型可以使您清理输入内容并在开始使用工厂创建对象之前失败。
type SkateBoard =
| Roskopp
| Peters
with
static member FromString = function
| \"Roskopp\" -> Roskopp
| \"Peters\" -> Peters
| _ -> failwith \"no such skateboard model..\"
您会发现OO中的许多设计模式都只是在函数式编程中消失了。
用SkateBoardFactory
创建一个额外的函数来执行您的功能。
let SkateBoardFactory assemble model = assemble model
let SantaCruzFactory = SkateBoardFactory assemble
由于具有一流的功能,您只需分配ѭ8。
let SantaCruzFactory = assemble
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。