F # Enregistrements avec membres vs classes

La modélisation de domaine peut être effectuée avec les enregistrements ET les classes. Je pense que le moment d'utiliser l'un ou l'autre est avant tout une question de préférence et d'environnement. Personnellement, je n'utilise généralement pas de cours, mais je connais des personnes qui les utilisent assez fréquemment. Les classes reposent davantage sur la mutation et sont plus performantes au détriment de la facilité d'utilisation. Personnellement, je pense que si vous voulez écrire un style orienté objet, utilisez des classes et si vous écrivez un style fonctionnel, utilisez des enregistrements. Enregistre la correspondance et la déconstruction des modèles plus facilement. Une partie de cette distinction est culturelle, ce n'est pas parce que vous pouvez faire quelque chose d'une manière particulière que d'autres personnes pourront vous comprendre facilement. Le code est écrit pour être lu, à la fois par vous-même et par les autres. Lorsque vous choisissez des enregistrements ou des classes, il communique l'intention sur le style et l'utilisation de ces types. Enfin, je ne sais pas qu'une classe peut être convertie en un enregistrement dans F # et si c'est le cas, je le recommanderais quand même. En effet, l'utilisation d'enregistrements en tant que classes et de classes en tant qu'enregistrements entre en conflit avec les normes culturelles autour de ces constructions. Je pense personnellement que votre exemple de membre convient à la fois aux enregistrements et aux classes. J'aime normalement utiliser des modules avec le même nom pour les fonctions associées à un type donné, car cela peut rendre les choses moins déroutantes lorsque la fonction consomme autre chose que le type d'enregistrement. Cependant, je ne pense pas que quelqu'un de bien élevé rechigne à l'un ou l'autre de vos exemples de code.

type Album(
    Id: int, 
    Name: string, 
    DateReleased: string, 
    Genre: int ) as me =
    let mutable genre = Genre  
    //readonly property
    member val Id = Id
    //autoproperty with get and set
    member val Name = Name with get, set
    member val DateReleased = DateReleased with get, set
    //property with explicit get and set
    member this.Genre 
        with get () = genre
        and set (value) = genre <- value

voir Quand dois-je utiliser let, member val et member this?

Pour compliquer un peu les choses, il n'y a pas que les champs d'enregistrement F # et les propriétés CLI en tant que conteneurs de données. Les deux sont les mêmes sous le capot: les accesseurs aux champs d'enregistrement F # immuables sont implémentés comme des récupérateurs de propriété CLI.

Si votre cas d'utilisation le permet, vous pouvez également utiliser des champs CLI, avec des définitions F # mutable val . D'autre part, la définition similaire, en lecture seule val est également exposée par un getter de propriété.

type Album =
    // CLI property getter
    val Id : int
    // mutable CLI field
    [<DefaultValue>]
    val mutable Name : string
    // non-primary constructor with sequence construction (before)
    new (id: int, name : string) as me =
         { Id = id } then me.Name <- name

Il y a des inconvénients:

• absence de constructeur principal,
• la lourdeur de l'expression de constructeur supplémentaire,
• assurer l'initialisation par défaut du type de champ, avec DefaultValueAttribute

Et cela peut être considéré comme unidiomatique.

Vous pouvez également envisager d'avoir un module avec le même nom que le type d'enregistrement comme ceci:

type Album = {
    Id: int
    Name: string
    DateReleased: DateTime
    Genre: Genre
}
module Album =
    let printMessage album =
        printfn "Hello from %s" album.Name

let first = {
    Id = 1
    Name = "Hello World!"
    Genre = KPop
    DateReleased = DateTime(1991, 8, 12)
}
Album.printMessage first