Using Immutable Data Structures in C# and .NET - Spencer Schneidenbach

Поділитися
Вставка
  • Опубліковано 1 сер 2024
  • Immutable objects - aka objects whose properties and fields can't change after instantiation - are one of the fundamental pillars of functional programming. Yet, it also has other great uses in classically object-oriented languages such as C#. Immutability can help make your code cleaner, easier to reason about, and reduce runtime errors. But how can you do that without making it feel like you're fighting against the typically-mutable C# and the entire .NET Framework?
    In this session, Spencer will discuss immutability and how you can apply it in your day-to-day as a .NET/C# developer. We'll go over immutable objects, immutable collections, and how you can refactor your code to successfully apply immutability to your exisitng codebase. Spencer will also discuss the implications of introducing immutability to your code, both positive and negative.
    Check out more of our talks, courses, and conferences in the following links:
    ndcconferences.com/
    ndc-london.com/
  • Наука та технологія

КОМЕНТАРІ • 49

  • @piranha1337
    @piranha1337 4 роки тому +33

    This channel is a gold mine. Thanks to all participants that made this available to everyone for free!

  • @hanspetervollhorst1
    @hanspetervollhorst1 4 роки тому +4

    I needed this talk 15 Years ago

  • @SpencerSchneidenbach
    @SpencerSchneidenbach 4 роки тому +5

    I appreciate everyone's comments on this video - please let me know if you have any questions :) my twitter is twitter.com/schneidenbach

    • @GeorgeTsiros
      @GeorgeTsiros 2 роки тому

      What level is this considered?
      Be as blunt as you can.

  • @mervinmarias9283
    @mervinmarias9283 4 роки тому +11

    If I had this guy as a teacher would have passed accreditation years back already

  • @Mortizul
    @Mortizul 4 роки тому +3

    For mutating immutable types, use the "With" function. That'll give you a new instance of that type with the changed properties. #languageext

  • @richardhaslam399
    @richardhaslam399 4 роки тому +6

    Maybe you shouldn't be trying to change the world, but creating a new version with the changes? ;)

  • @shurale85
    @shurale85 4 роки тому +2

    What should I do when I have to create immutable object but not all fields can be initialized due to data missing at the creation time?what is the best practice to complete created object with data?

    • @eugene3685
      @eugene3685 4 роки тому

      It's probably depends when you are going to provide the rest values for an object. But here is a pattern that J. Skeet told:
      obj.Freeze(); //makes obj immutable

    • @mikey_r
      @mikey_r 4 роки тому

      Try using a design pattern such as event-sourcing.

    • @cartsp
      @cartsp 4 роки тому

      Make a new object when you have the missing values. If you have access to the "with" keyword its a lot easier

  • @GeorgeTsiros
    @GeorgeTsiros 2 роки тому

    25:41 What was wrong with public static Person PersonFrom(Employee e) => new Person(e.FirstName, e.LastName); ?!

  • @fadidib8516
    @fadidib8516 2 роки тому

    great talk. Factory of a Factory, to the Factory, Refactor the Factory, Factory lol.

  • @GeorgeTsiros
    @GeorgeTsiros 2 роки тому

    23:45 why are you asking ImmutableList who it is? You _say_ at 23:42 that they are _different instances_ . You check for that with ReferenceEquals. Object.ReferenceEquals(object, object) is for this purpose.

  • @ar_xiv
    @ar_xiv 2 роки тому

    I really don’t understand the benefit of a factory pattern over an init method in his example

    • @DryBones111
      @DryBones111 2 роки тому +1

      The usage of the service requires the additional knowledge of how to initialise it. If you hide access to the constructor and provide a factory to initialise the service, then you have one place that knows how to do it and hides the detail from consumers.

  • @killymxi
    @killymxi 4 роки тому +10

    What I hear:
    > Mutability first, mutability opt-in.
    Unvoiced "im-" part makes it a challenge to follow the speaker, unless I already know what he trying to say.

  • @GeorgeTsiros
    @GeorgeTsiros 2 роки тому

    public class Foo {
    public readonly int Lastname, Firstname;
    public Foo (string last, string first) {
    Lastname = last;
    Firstname = first;
    i do not understand why we should wait for c# version whatever or why we should use properties. Properties are syntactic sugar for methods. Nothing more, nothing less.

    • @GeorgeTsiros
      @GeorgeTsiros 2 роки тому

      don't ask me why i try to assign string values to int typed fields

  • @GeorgeTsiros
    @GeorgeTsiros 2 роки тому

    18:47 why linq??? Array.ConvertAll not good enough? Why has linq become the go-to solution for everything these days?

    • @DryBones111
      @DryBones111 2 роки тому

      Lazy evaluation. You can have another part of the application add a filter to it and when you finally call in the data, you're only processing the data that is requested.

    • @GeorgeTsiros
      @GeorgeTsiros 2 роки тому

      @@DryBones111 if it's not needed now, why is it declared now? What you say does sound reasonable at first, but I do not find them to be strong enough arguments. There are other constructs to do lazy eval.

    • @DryBones111
      @DryBones111 2 роки тому

      @@GeorgeTsiros It's partly to do with keeping things open to extension and closed to modification. Your method can simply define the mapping (single responsibility) and return an IEnumerable (keeping in line with immutability). What happens to the enumerable from there doesn't matter but you know the mapping is done. LINQ is implemented using pure functions and will give you the immutability in a performant way.
      LINQ is also the most common API for these kinds of transformations on collections in C# code now. There's no good reason not to use something immutable, performant, and declarative for the majority of use cases.

    • @GeorgeTsiros
      @GeorgeTsiros 2 роки тому

      @@DryBones111 that sounds more convincing

  • @GeorgeTsiros
    @GeorgeTsiros 2 роки тому

    20:27 do i _need_ to explain what is wrong with this?
    21:10 apparently i do! What the fuck is this? Repository.Init() should be *part of the constructor* because that is the sole purpose for _constructors with parameters_ to exist: Creating a _new_ object in a _well defined state_ .
    public Repo(Conf conf) {}
    That is what you want to achieve with the disaster at 21:10. You want to create a Repo with someConf. new Repo(someConf).

  • @XKS99
    @XKS99 4 роки тому +3

    What if someone on your team supports Brexit?

    • @geoffxander7970
      @geoffxander7970 4 роки тому +1

      The joke was neither tolerant nor inclusive and it needlessly injected politics into the conversation.

    • @IvanRandomDude
      @IvanRandomDude 3 роки тому +1

      Those people are probably not open about it. And I don't blame them, the environment nowadays is very intolerant.

    • @GeorgeTsiros
      @GeorgeTsiros 3 роки тому

      @@geoffxander7970 Good, because being tolerant or inclusive about crap like this worse than supporting brexit. "Injected politics into the conversation" as if your entire life is not permeated by politics.

  • @mnatiris
    @mnatiris 4 роки тому +1

    The projection example has terrible performance

    • @tryfinally
      @tryfinally 4 роки тому

      Won't matter much for many web backend-type uses. Sadly, I work in gamedev where every bit of performance genuinely counts and immutability often isn't an option.

    • @FilipCordas
      @FilipCordas 4 роки тому +1

      Mutability is usually has much better performance , linq by it self is not that fast and efficient. But most of this is just nonsense, no reason to have to have everything imitable. That query could have been improved by not creating a new instance but returning the old one if there is no need to change. What ends up happening you copy paste a bunch of code because you need the "builder pattern".

    • @feafarot
      @feafarot 4 роки тому

      @@FilipCordas The reason to go with immutability is to have a more stable and cleaner code (at a cost of performance ofc). But it could be useful when you don't need extreme performance and you have a large codebase.
      p.s. IMHO it's better to use functional language like F# for that matter thou (it has more performant immutability). (:

    • @FilipCordas
      @FilipCordas 4 роки тому

      @@feafarot F# is not that good or readable, it has nice things but overall it ends as unreasonable mess with everything in line unable to figure out what is the beginning or end. And cleaner is a subjective term. immutability is not less performant when used correctly to avoid locks in parallel execution, but this sort of religious attitude is just silly, especially when used incorrectly like with the projection in the example it's going to end up bad just like any mutable code.

    • @feafarot
      @feafarot 4 роки тому +2

      ​@@FilipCordas "it ends as unreasonable mess with everything in line" - Well that only means that code was written badly, spaghetti is never good. You can write F# code to be self-documented like in C#. "cleaner is a subjective term" - sure, from my experience, the more mutations in one place you have - harder to understand what's going on (imo).
      I agree that the example from the video with Select is weird (but honestly if there is like around 20 items to iterate over - that's nothing for most modern apps, in terms of performance).

  • @Mortizul
    @Mortizul 4 роки тому +8

    Pro tip, avoid political "jokes" to avoid alienating half of your audience.

    • @josephang9927
      @josephang9927 4 роки тому +2

      This. Not to mention that engineers are often among the most conservative professionals.

    • @geoffxander7970
      @geoffxander7970 4 роки тому +1

      I.e. be professional.

  • @dalsegno1251
    @dalsegno1251 4 роки тому +2

    Difficult speaker to follow with the constant mistakes and self-corrections. Perhaps practice your lecture more.