Jakiś czas temu (nawet nie wiedziałem, że to już tyle czasu minęło!) .NET zaoferował nam możliwość korzystania z inicjalizatorów obiektu, zamiast stosowania klasycznej inicjalizacji. Jak to zwykle bywa, sama idea była świetna, ale już praktyka pokazała, że nie do końca – tak samo jak w przypadku Tuple i var.
Dlaczego tak się stało? Inicjalizatory miały być „cukierkiem”, w prosty sposób, przy tworzeniu obiektu, mogliśmy ustawiać jego propertiesy:
Car car = new Car { Brand = "Ford", Model = "Mustang" };
Rzeczywiście, wygląda to dużo lepiej niż:
Car car = new Car(); car.Brand = "Ford"; car.Model = "Mustang";
Na pierwszy rzut oka nie widać problemów, które mogą wynikać z użycia inicjalizatora. Jednak co w przypadku, kiedy nasz obiekt ma 10 różnych właściwości i nagle dostajemy exception? Czy w tym przypadku prościej jest od razu zobaczyć, w której linii nasz kod się wysypał, czy tracić na to cenny czas, gdy kompilator informuje nas o błędzie w linii nr 13?
Przykład:
W momencie, gdy nasz obiekt jest dosyć duży (ma np. 10 właściwości) i mapujemy go na inny obiekt, zdarza się że przekażemy złą wartość/nie przekażemy wartości i w takiej chwili znalezienie linii, która jest za to odpowiedzialna zajmie dużo więcej czasu niż w przypadku zwykłej inicjalizacji. Jak widać, dla małych obiektów – inicjalizatory są całkiem w porządku, ale niestety przy obiektach większych, kompletnie nie sprawdzają się w praktyce.
Faktycznie debugowanie może sprawiać problemy. Ale moim zdaniem zasadnicza przewaga inicjatorów to nie zainicjowanie obiektu gdy wystąpi błąd podczas inicjacji obiektu
Zabraklo jeszcze tylko napomknac o konstruktorach 🙂
Przedstawione tu inicjalizatory maja swoje plusy tylko dla obiektow typu DTO bez logiki biznesowej. W innych przypadkach trzeba uzywac konstruktorow dzieki ktorym mozna pokierowac programiste i dac mu wskazowki jak poprawnie stworzyc obiekt.
Zgadza sie, dzięki za uzupełnienie 🙂