@zarazaa: tam nie ma leaku. Jedyna dynamiczna pamięc to wynik oraz to co utworzy Reset(). Wynik jest usuwany w mainie a pole "product" zostanie usunięte w destruktorze ~ConcreteBuildera. Inna sprawa, że nie powinno się tak programować, bo łatwo się przejechać https://dsp.krzaq.cc/post/176/ucze-sie-cxx-kiedy-uzywac-new-i-delete/

@VanQator: Dobra, już mam. Oczywiście, consty trzeba wyebać, i serio zwracać wskaźniki xD

@VanQator: ten interfejs Builder to jedno wielkie xd. Interfejsów używasz jak chcesz mieć wiele różnych implementacji używanych w ten sam sposób. Tutaj metody buildera zwracają jako wynik ConcreteBuilder, więc i tak nie używasz tego w inny sposób. Jeszcze nie widziałem, żeby ktoś robił abstract buildera. Ten wzorzec służy do "ładnego" utworzenia jakiegoś obiektu konkretnej klasy, tutaj interfejs nie ma sensu. Co do samego buildera to w C++ najczęściej zwraca sięPokaż całość

@Saly: Builder służy do tworzenia różnych obiektów tej samej klasy różniących się szczegółami, a powyższa implementacja buildera, to klasyczny tego przykład.

@VanQator: chodzi mi, że ten interfejs jest bez sensu. Mając taką sygnaturę: virtual ConcreteBuilder ProducePartC() const = 0; nie jesteś w stanie użyć tego interfejsu dla innego obiektu, niż ConcreteBuilder, bo pierwsze wywołanie sprawi, że będziemy operować już na ConcreteBuilderze a nie Buildera. Jak interfejs ma zastosowanie dla tylko jednej klasy to lepiej go usunąć.

@VanQator: nie wiem czemu ma służyć ten cudak i po co się to stosuje bo nie wgłębiałem się nigdy za bardzo w programowanie obiektowe za to wgłębiałem się w sam język programowania i wydaje mi się, że w GetProduct() masz memory leak. ja wiem ze to tylko przykład ale warto wyrobić jakieś nawyki ( ͡° ͜ʖ ͡°)