Wpis z mikrobloga

@UnderratedMoviesBot: Popatrz na to szerzej, teraz każdy korpo IT menadżer sra się o "code coverage" (bez zrozumienia jak się go wylicza i jak go analizować, po prostu więcej code coverage = lepiej), a takie konstrukcje bardzo podnoszą code coverage, więc ogólna jakość projektu w tabelkach rośnie, można sobie wypłacić premię :)
@molski: jest dużo opcji refactoru tego shitu. Co ciekawe te parametry są przekazywane w konstruktorze. Ta struktura nie ma żadnej logiki tylko trzyma dane jako consty i ma getter do każdego propertiesa, co jest bez sensu. Minimane rozwiązanie to wywalenie konstruktora, ustawienie atrybutów na public i przy tworzeniu obiektu ustawiać atrybuty korzystając z designated initializers a więc ustawiasz zamiast 50 nullopt tylko jeden czy ile tram potrzebujesz atrybutow który Cię interesują.
@molski: wywalić ustawianie elementów do zewnętrznej funkcji opartej o słownik/mapę.

Wtedy konstruktor bez argumentów i potem tylko sobie wołasz obj->SetParam(paramname, paramvalue)

To chyba najprostsze bez żadnych patternow, ale jakby się zastanowić to na pewno jakiś sensowny design pattern by się na to znalazł.
@MamCieNaHita: Ooooo, nie znałem tego. Powiem tak - w Pythonie masz np. named arguments, które rozwiązują Ci wszystkie te problemy.

Może w nowym c++ też to jest i nie mam pojęcia?

void func(int a = 0, int b = 0, int c = 0);

I wtedy wołasz to tak:
func(b=7);

Funkcja wywoła się z domyślnymi wartościami poza parametrem b.