F#: Преимущества преобразования верхнего уровня функционируют к членским методам?

Одна из практик, которую я использовал в своем программировании на F# - это использование кода в обоих местах.

Фактическую реализацию естественно поместить в модуль:

module Hand = 
  let getDecisions hand =
    let (/=/) card1 card2 = matchValue card1 = matchValue card2
  ...

и дать "ссылку" в функции-члене/свойстве:

type Hand
  member this.GetDecisions = Hand.getDecisions this

Эта практика также обычно используется в других библиотеках F#, например, реализация матрицы и вектора matrix.fs в powerpack.

На практике, не каждая функция должна быть помещена в оба места. Окончательное решение должно быть основано на знаниях домена.

Что касается верхнего уровня, то практика такова, что функции помещаются в модули, а некоторые из них при необходимости выносятся на верхний уровень. Например, в F# PowerPack, Matrix<'T> находится в пространстве имен Microsoft.FSharp.Math. Удобно сделать ярлык для конструктора матрицы на верхнем уровне, чтобы пользователь мог построить матрицу напрямую, не открывая пространство имен:

[<AutoOpen>]
module MatrixTopLevelOperators = 
    let matrix ll = Microsoft.FSharp.Math.Matrix.ofSeq ll

Это сложный вопрос, и оба подхода имеют свои преимущества и недостатки. В целом, я склонен использовать члены при написании более объектно-ориентированного кода в стиле C# и глобальные функции при написании более функционального кода. Однако я не уверен, что могу четко сформулировать, в чем разница.

Я бы предпочел использовать глобальные функции при написании:

• Функциональных типов данных, таких как деревья/списки и другие общеупотребительные структуры данных, которые хранят некоторый большой объем данных в вашей программе. Если ваш тип предоставляет некоторые операции, которые выражаются как функции высшего порядка (например, List.map), то, вероятно, это такой тип данных.

• Функциональность, не связанная с типом - бывают ситуации, когда некоторые операции не принадлежат строго одному конкретному типу. Например, когда у вас есть два представления некоторой структуры данных, и вы реализуете преобразование между ними (например, типизированный AST и нетипизированный AST в компиляторе). В этом случае функции - лучший выбор.

С другой стороны, я бы использовал члены при написании:

• Простых типов, таких как Card, которые могут иметь свойства (например, значение и цвет) и относительно простые методы (или не иметь их), выполняющие некоторые вычисления.

• Объектно-ориентированные - когда вам нужно использовать объектно-ориентированные концепции, такие как интерфейсы, тогда вам нужно будет написать функциональность в виде членов, поэтому может быть полезно подумать (заранее), будет ли это применимо к вашим типам.

Я бы также отметил, что совершенно нормально использовать члены для некоторых простых типов в вашем приложении (например, Card) и реализовать остальную часть приложения с помощью функций верхнего уровня. На самом деле, я думаю, что в вашей ситуации это был бы лучший подход.

Примечательно, что можно также создать тип, имеющий члены, вместе с модулем, который обеспечивает ту же функциональность, что и функции. Это позволяет пользователю библиотеки выбрать стиль, который он/она предпочитает, и это совершенно правильный подход (однако, вероятно, он имеет смысл для отдельных библиотек).

В качестве примечания, цепочка вызовов может быть достигнута с использованием как членов, так и функций:

// Using LINQ-like extension methods
list.Where(fun a -> a%3 = 0).Select(fun a -> a * a)
// Using F# list-processing functions
list |> List.filter (fun a -> a%3 = 0) |> List.map (fun a -> a * a)

Я обычно избегаю классов в первую очередь из-за того, как члены искалечивают вывод типов. В этом случае иногда удобно сделать имя модуля таким же, как имя типа - здесь пригодится приведенная ниже директива компилятора.

type Hand
// ...stuff...

[<CompilationRepresentation(CompilationRepresentationFlags.ModuleSuffix)>]
module Hand =
    let GetDecisions hand = //...