Builder Pattern - Rozważania

Witam,

Zabrałem się za analizę wzorca kreacyjnego: Builder. Mimo tego że jest to jeden z podstawowych wzorców projektowych implementacji jego jest tyle co osób piszących. Który waszym zdaniem jest tym właściwym "Builderem"? Jeżeli ktoś ma ciekawsze przkłady chętnie zobaczę.

Na początek WIK jako punkt referencyjny:
https://en.wikipedia.org/wiki/Builder_pattern#C#

Oraz kilka znalezionych później
https://www.dofactory.com/net/builder-design-pattern
https://code-maze.com/builder-design-pattern/
https://cpppatterns.com/patterns/builder.html

Nie chodzi po prostu o fabrykę, tylko taką która pozwala chainować wywołania metod tak aby można było przypisać obiektowi odpowiednie cechy/wartości? Jeśli nie to proszę mnie poprawić, w przeciwnym razie nad czym tu rozważać? :)

Rozważać można chyba to, że builder z książki GoF to nie jest to samo, co wzorzec builder w powszechnym mniemaniu.

Nie ma właściwego, wszystko zależy od problemu jaki masz, ja np. wykorzystuje sobie buildera jak mam np. przekazać kilka argumentów przez konstruktor wtedy przekazuje sobie buildera.

Dzięki za uwagi.

Z podanych przykładów zaciekawiło mnie:
Gdzie ustawiamy parametry produkowanego produktu: Wiki proponuje w Director, Natomiast pozostałe strony w samym builder. Czy jest to tylko szczegół implementacyj/przykładu? Czy tak własnie powinno być.

imo builder to najczesciej antipattern bo walczy z objawami a nie przyczynami problemu. jesli konstruktor wymaga kilkunastu parametrow z czego polowa to opcjonalne to zazwyczaj oznacza ze cos jest mocno skopane, klasa ma niezbyt dobrze zdefiniowana odpowiedzialnosc i (zazwyczaj) jej stan jest mocno mutowalny przez nie wiadomo co i kiedy.
dwa scenariusze gdzie (chyba) builder jest dedykowanym patternem:

1. POJO/POCO/kontener z wieloma propertisami - wole zrobic normalny konstruktor z obowiazkowymi argumentami + fluent interface, tj metody ktore zwracaja immutable obiekt o zmienionym stanie
2. skomplikowany serwis o xx parametrach - wole zaprojektowac (albo stopniowo refaktorowac) to tak ze kazdy z parametrow jest obowiazkowy, ale jest na tyle abstrakcyjny ze mozna zamiast legitnego (t.j. majacego sens biznesowy) wstrzyknac cos neutralnego, co zreszta przydaje sie przy testowaniu