Wpis z mikrobloga

Czytałem sobie artykuł o EventSourcing - https://codeopinion.com/event-sourcing-example-explained-in-plain-english/
I wszystko git, zrozumiałem o co chodzi, ale męczy mnie jedna rzecz. Mianowicie jest tam taka metoda:

public IList GetUncommittedEvents()
{
return new List(_uncommittedEvents);
}

I nie rozumiem dlaczego zwracana jest nowa lista w sytuacji gdy w tej klasie gdzie jest ta metoda ta lista jest inicjalizowana:

private readonly IList _uncommittedEvents = new List();
Jest w tym jakiś sens czy to tylko pomyłka autora?

#programowanie #dotnet #csharp
  • 5
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@zielonka_san: 1. zmień pasek bo głupio się czyta jak różowy pisze zrozumiałem
2. To taki sposób żeby aplikacja alokowała więcej pamięci i GC miał co robić
3. A poważnie to udostępniając wewnętrzną listę ryzykujesz że ktoś Ci w niej nabroi
4. Zazwyczaj w takim wypadku lepiej zwrócić read-only collection która nie powinna mieć w środku osobnej tablicy tylko opakowywać oryginalną blokując jej edycje
  • Odpowiedz
@zielonka_san: takie kopie upraszczają kod. Jak ktoś zawoła GetUncommitedEvents to dostanie listę eventów w danej chwili i tyle. Nie musi się bać, że jakiś inny wątek będzie zapisywał do tej list (bo kto wie co ta klasa robi) albo jakiś kod zawoła GetUncommitedEvents w innym miejscu i tamto miejsce będzie modyfikowało tą listę w taki sposób, że to pierwotne miejsce się wysypie
  • Odpowiedz
@zielonka_san: idąc w ekstremalną stronę masz kolekcje niemutowalne np. https://docs.microsoft.com/en-us/dotnet/api/system.collections.immutable.immutablelist-1.add?view=net-6.0#system-collections-immutable-immutablelist-1-add(-0) (zauważ, że Add() tworzy kopię listy co jest wyrażone jako typ zwracany). Takie podejście jest dobre, bo nie trzeba robić tak zwanych defensivie copy, bo takiej niemutowalnej kolekcji nie da się zepsuć: jest bezpieczna by design a jakiekolwiek zmiany tworzą nową strukturę całkowicie nie wpływającą na te stare
  • Odpowiedz