如何为多个F#可区分联合类型复用静态成员与特性？

你的需求完全合理——重复编写相同的特性和静态成员确实不够优雅，既增加了维护成本也显得冗余。下面提供几种逐步优化的方案，从简单易实现的到更高级的元编程方式，你可以根据自己的场景选择：

方案1：提取通用反射逻辑（最推荐） #

首先把重复的反射逻辑抽成一个独立的私有函数，然后每个类型的静态成员只需要一行代码调用这个函数即可。这样既保留了每个类型的特性声明，又完全消除了重复的反射实现。

open System
open System.Reflection
open Microsoft.FSharp.Reflection
open System.Runtime.Serialization

// 把重复的反射逻辑抽离成通用函数
let private getKnownTypes (targetType: Type) =
    targetType.GetNestedTypes(BindingFlags.Public ||| BindingFlags.NonPublic)
    |> Array.filter FSharpType.IsUnion

// 每个可区分联合只需要简短的静态成员
[<KnownType("GetKnownTypes")>]
type Name = Name of string | NoName with
    static member GetKnownTypes() = getKnownTypes typeof<Name>

[<KnownType("GetKnownTypes")>]
type Coordinate = Coordinate of float * float | NoCoordinate with
    static member GetKnownTypes() = getKnownTypes typeof<Coordinate>

这个方案的优点是改动极小，不需要修改原有类型的结构，代码可读性强，维护成本低，适合绝大多数场景。

方案2：利用KnownTypeAttribute的外部方法重载（更简洁但有兼容性限制） #

如果你想完全去掉每个类型的静态成员，可以利用.NET的KnownTypeAttribute重载版本——它允许你指定一个外部类型，调用该类型的静态方法。不过需要注意方法签名必须符合框架要求（无参数或接受StreamingContext参数，返回Type[]）。

我们可以写一个通用的静态辅助类，结合泛型来适配不同类型：

open System
open System.Reflection
open Microsoft.FSharp.Reflection
open System.Runtime.Serialization

type KnownTypeHelpers =
    // 通用泛型方法，用于获取指定类型的KnownTypes
    static member GetKnownTypes<'T>() =
        typeof<'T>.GetNestedTypes(BindingFlags.Public ||| BindingFlags.NonPublic)
        |> Array.filter FSharpType.IsUnion

// 每个可区分联合只需指定特性，无需写静态成员
[<KnownType("GetKnownTypes", typeof<KnownTypeHelpers>)>]
type Name = Name of string | NoName

[<KnownType("GetKnownTypes", typeof<KnownTypeHelpers>)>]
type Coordinate = Coordinate of float * float | NoCoordinate

不过这里有个小坑：部分序列化框架（比如WCF）在调用外部泛型方法时，可能无法正确解析泛型参数。如果你的项目依赖这类框架，方案1会更稳妥。

方案3：元编程/代码生成（适合大量类型场景） #

如果你有几十个甚至上百个这类可区分联合，可以用F#的元编程工具（比如代码引用、Type Provider）自动生成带有特性和静态成员的类型。

举个简化的代码生成思路：

open System
open Microsoft.FSharp.Quotations
open Microsoft.FSharp.Reflection
open System.Runtime.Serialization

let generateKnownUnion (typeName: string) (cases: (string * Type list) list) =
    // 这里可以用F#代码引用或Roslyn动态生成类型代码
    // 核心逻辑是自动添加[<KnownType>]特性和对应的GetKnownTypes静态成员
    ()

这种方式学习成本较高，维护也需要额外精力，只适合类型数量极多的场景。

总结 #

对于大多数项目，方案1是最优选择——它用最小的改动解决了代码重复问题，兼顾可读性和可维护性。如果追求极致简洁且序列化框架支持外部泛型方法调用，可以尝试方案2。

内容的提问来源于stack exchange，提问作者S. Haug