mirror of
https://github.com/rjNemo/design-patterns
synced 2026-06-06 02:26:40 +00:00
50 lines
1.7 KiB
Python
50 lines
1.7 KiB
Python
from Builder import Builder
|
|
from products import Product1
|
|
|
|
|
|
class ConcreteBuilder1(Builder):
|
|
"""
|
|
The Concrete Builder classes follow the Builder interface and provide
|
|
specific implementations of the building steps. Your program may have
|
|
several variations of Builders, implemented differently.
|
|
"""
|
|
|
|
def __init__(self) -> None:
|
|
"""
|
|
A fresh builder instance should contain a blank product object, which is
|
|
used in further assembly.
|
|
"""
|
|
self.reset()
|
|
|
|
def reset(self) -> None:
|
|
self._product = Product1()
|
|
|
|
@property
|
|
def product(self) -> Product1:
|
|
"""
|
|
Concrete Builders are supposed to provide their own methods for
|
|
retrieving results. That's because various types of builders may create
|
|
entirely different products that don't follow the same interface.
|
|
Therefore, such methods cannot be declared in the base Builder interface
|
|
(at least in a statically typed programming language).
|
|
|
|
Usually, after returning the end result to the client, a builder
|
|
instance is expected to be ready to start producing another product.
|
|
That's why it's a usual practice to call the reset method at the end of
|
|
the `getProduct` method body. However, this behavior is not mandatory,
|
|
and you can make your builders wait for an explicit reset call from the
|
|
client code before disposing of the previous result.
|
|
"""
|
|
product = self._product
|
|
self.reset()
|
|
|
|
return product
|
|
|
|
def produce_part_a(self) -> None:
|
|
self._product.add("PartA1")
|
|
|
|
def produce_part_b(self) -> None:
|
|
self._product.add("PartB1")
|
|
|
|
def produce_part_c(self) -> None:
|
|
self._product.add("PartC1")
|