what object representation in builder pattern exactly means?

Question

I'm a newbie for design pattern.I feel I missing some essential pieces in understanding Builder Pattern. what the object representation exactly means in this definition?

THE BUILDER PATTERN: Separates the construction of a complex object from its representation so that the same construction process can create different representations.

Is it means the object's internal struct(instance variable and member function)? I has look for on Internet but still confuse it,any help is appreciated!

Answer 1

According to the GoF, the Builder pattern is a creational pattern, therefore, it solves a specific problem when you need to create object.

The need for the Builder pattern arises when you need to create a complex object with many dependencies and it is impossible or impracticable to obtain all this dependencies at the same time.

Let's take as example a car assembly line. Not all cars are equal, albite all of them have similar structure (such as a frame, wheels, steering wheel, brakes, lights), they may differ in their optionals, such as digital air conditioning, solar roof, parking camera and so on.

This assembly line should be flexible enough to be able to build cars with any configuration the customer wants with minimum setting.

Lets imagine that the assembler machine recieves the blueprint of the new car it must assemble and then follows that spec.

Bringing this to our object-oriented software engineering world, we might have:

interface ICar {
    public function getName();
    public function getColor();
    public function addComponent($component);
}

class CarImpl implements ICar {
    private $name, $color, $components = array();
    public function __construct($name, $color, array $components){
        $this->name = $name;
        $this->color = $color;
        $this->components = $components;
    }
    public function getName() { return $this->name; }
    public function getColor() { return $this->color; }
    public function addComponent($component) { $this->components[] = $component; }
}

class CarBuilder {
    private $buildClass = 'CarImpl';
    private $name, $color, $components = array();

    public function __construct($buildClass = null) {
        if ($buildClass !== null) {
            $this->buildClass = $buildClass;
        }
    }

    public function setName($name) {
        $this->name = $name;
    }

    public function setColor($color) {
        $this->color = $color;
    }

    public function addComponent($component) {
        $this->components[] = $component;
    }

    public function build() {
        return new ${this->buildClass}($this->name, $this->color, $this->components);
    }
}

// using...

$builder = new CarBuilder();
$builder->setName('Camaro');
$builder->setColor('Yellow');
$builder->addComponent('frame');
$builder->addComponent('bodywork');
$builder->addComponent('wheels');
$builder->addComponent('engine');
$builder->addComponent('black stripes');
$builder->addComponent('cybertronian core');

$myCar = $builder->build(); // yields Bumblebee!

So, answering your question:

Is it means the object's internal struct(instance variable and member function)?

Yes, it refers to internal structures. Normally, an instance variable, since in PHP it is not a good practice to change a class contract by adding methods to it.

While my example above might seem dumb, I deliberately made it that way for the sake of simplicity.

But as a mental exercise, think what would happen if some of the components had their own dependencies that cannot be obtained right the way. Then you would be able to delay the CarImpl object until you can fullfil all its component dependencies.

Answer 2

Looking for references in the index section of Design Patterns seems to provide no answers.

Fortunately, your terminology concern is resolved in this Wikibooks appendix, where it is noted

• The abstraction is only the visible part of your code outside. It is the contract between the provider and the client code. [...]

• The representation is the way a problem is resolved. It follows the contract of what is given as input and what is expected to be returned. [...]

I would be tempted to put this in plainer words by saying that abstractions are related to interfaces, while representations to actual implementations.

The [...] in the quotes are mine and indicate I have omitted less important portions.