HP OOP 构建器模式使用

Question

我对在实践中使用 PHP 构建器模式感到困惑。在许多文档中，他们建议像这样使用 Builder。

require 'Pizza.php';
require 'PizzaBuiler.php';

$piza_builder=(new PizzaBuilder('medium'))
        ->cheeze(true)
        ->bacon(true)
        ->build();

$pizza=new Pizza($piza_builder);

Pizza class 使用 PizzaBuilder 作为构造函数参数并从中初始化 class 属性。

为什么不直接从 Builder 实例化对象？？？这么糟糕吗（反模式）。

require 'Pizza.php';
require 'PizzaBuiler.php';

$piza= Pizza::getBuilder("medium")
        ->cheeze(true)
        ->bacon(true)
        ->build();

两个实现之间的唯一区别是将 Builder class 中的 build() 函数修改为 return new Pizza Object 而不是 returning Builder 实例。

你能告诉我使用什么 clean builder 吗？？？

Answer 1

我认为构建器模式有一些变体，因为它是一种设计模式而不是规范。

建造者模式旨在解决复杂对象的构造问题。只要做它想做的就可以了。

Why not instantiate object directly from Builder?

当然可以。考虑 Pizza 是意大利菜的概念表示。 PizzaBuilder 是一个有助于构建 Pizza 的实用程序。 Pizza 足以独立存在而没有 PizzaBuilder。我认为在 Product 构造函数中接受 Builder 不是必须的。

此外，由于 Single-responsibility 原则，我不希望在 Pizza 中包含静态 PizzaBuilder。如上所述，披萨足以单独存在。 Pizza 与 PizzaBuilder 无关。 PizzaBuilder 需要 Pizza 的知识来构建 Pizza。我会将 Pizza 构造的任何逻辑留在 PizzaBuilder 中并将其与 Pizza.

分离

我会这样构造代码。

require 'Pizza.php';
require 'PizzaBuiler.php';

$pizza=(new PizzaBuilder('medium'))
        ->cheeze(true)
        ->bacon(true)
        ->build();

2022 年 4 月 21 日更新以解决评论

If i use Pizza constructor without builder a developer can not know about the existence of builder when he want to use Pizza object.

我认为构造函数不是用于宣传围绕它构建的实用程序的工具 class。这取决于 developer/user 对框架的了解程度，并在此基础上编写应用程序以实现其目的。

Can you also explain to me haw adding static builder method will broke the single responsibility principle

如果 PizzaBuilder 是独立的：

如果 PizzaBuilder 是 Pizza 的静态成员：

我们必须考虑 PizzaBuilder 和 getBuilder() 对 Pizza 意味着什么。他们是否在帮助 Pizza 取得成就？如果 Pizza 是意大利菜的概念表示（当然这只是我的解释。你可能有自己的，因为你最了解你的应用程序），getBuilder() 是否与 [=11] 的其余部分一致=]构造？

以后如果Pizza需要改变，可能的原因是什么？也许它有更多的成分要添加。也许 PizzaBuilder 不再符合业务需求。有一天，如果我们需要一种新的算法来精确控制水粉比例。我们用复杂的算法开发了一个新的 PrecisePizzaBuilder。然后我们将 PrecisePizzaBuilder 替换为 PizzaBuilder。更改 Pizza 有两个原因。这可能暗示我们结合了两个不同的东西。

毕竟我觉得没有直接的对错。我的回答在某种程度上涉及我自己对你的申请的理解。我可能会提供有偏见的意见，因为我讨厌披萨（不是真的，我喜欢它）。我可能理解错了你的申请。然而，最重要的是你给每个模块一个目的，并在整个应用程序生命周期中保持它。预见未来哪些部分会发生变化，以及你今天可以做些什么来让你未来的生活更轻松。然后你就会知道你需要做出什么决定。这就是 OOP、SOLID 原则和设计模式的全部内容。使代码灵活和可维护。

HP OOP 构建器模式使用

HP OOP builder pattern use

php

design-patterns

php-7

solid-principles

builder-pattern