HP OOP构建器模式使用

Question

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

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

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

$pizza=new Pizza($piza_builder);

披萨类使用pizzabuilder作为构造函数参数和Init类属性。

为什么不直接从构建器实例化对象？？？这是不好的（反原本）。

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

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

两个失败者之间的唯一区别是修改构建器类中的build（）函数以返回新的披萨对象，而不是返回构建器实例。

您能建议我使用什么干净的建筑商使用吗？？？

Answer 1

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

构建器模式旨在解决复杂物体构建的问题。只要它执行打算做的事情，就可以了。

为什么不直接从构建器实例化对象？

一定。考虑pizza是意大利菜肴的概念表示。 Pizzabuilder是实用程序来构建pizza。 pizza足够好，可以在没有pizzabuilder的情况下独立存在。我认为在产品构造函数中接受构建器并不是必需的。

此外，由于单一责任原则，我不想在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();

更新21-APR-2022以解决评论

如果我使用没有建筑商的披萨构造函数，开发人员在想使用披萨对象时就无法知道建造者的存在。

我认为构造函数不是围绕该课程构建的广告公用事业的工具。这取决于开发人员/用户如何了解该框架，并以他们为实现其目的进行编程。

您还可以向我解释haw添加静态建筑商方法将破坏单个责任原则

如果pizzabuilder是独立的，

：

如果pizzabuilder是静态成员pizza：

我们必须考虑pizzabuilder和getBuilder（）表示 pizza。他们是否在帮助pizza实现目标？如果pizza是意大利菜肴的概念表示（当然，这只是我的解释。您可能有自己的解释，因为您最了解您的应用程序），是getBuilder（）与其他pizza构造相干？

将来，如果pizza需要更改，那可能是什么原因？也许它有更多的成分可添加。也许Pizzabuilder不再适合业务需求。有一天，如果我们需要一种新算法来精确控制水和面粉的比率。我们使用复杂的算法开发了一种新的Precisepizzabuilder。然后，我们用pizzabuilder替换precisepizzabuilder。更改pizza的原因有两个。这可能暗示我们将两件不同的东西造成。

毕竟，我认为没有直接的对与错。在某种程度上，我的回答涉及我对您的应用程序的理解。我可能会提供偏见的意见，因为我讨厌披萨（不是真的，我喜欢它）。我可能会理解您的应用程序错误。但是，最重要的是，您为每个模块提供了一个目的，并在整个应用程序寿命中保留它。预见，将来哪一部分将会改变，以及您今天可以做些什么，以使您的未来生活更轻松。然后，您将知道需要做出什么决定。这是OOP，坚实的原理和设计模式。使代码灵活且可维护。