Question

我的示例代码：

class CitiesListBuilder{
    private List<String> cities;

    public static CitiesListBuilder newBuilder(){
        return new CitiesListBuilder();
    }

    private CitiesListBuilder(){
        cities = new ArrayList<>();
    }

    public CitiesListBuilder addCity(String city) {
        cities.add(city);
        return this;
    }

    public CitiesListBuilder apply(Function<List<String>, List<String>> filter) {
        cities = cities.apply(filter);
        return this;
    }

    public List<String> build(){
        return cities;
    }
}

使用：

CitiesListBuilder.newBuilder
       .addCity("LA")
       .addCity("NY")
       .apply(NorthCitiesFilterFunction) 
       .build();

我理解我的代码可能是使用构建器模式的一个不好的示例，但对我来说它使代码更短更清晰（我自己的意见），并且我没有看到并发问题的任何问题。

但是对于你的意见，如果我应该/不应该做代码，会有什么争论？

谢谢。

Answer 1

我有点不愿意称之为＆＃34; Builder＆＃34;图案。这不是GoF Builder Pattern正在做的事情。因此，如果您要求使用GoF Builder模式，那么您编写的几乎所有内容都不会与Builder模式对齐，因为您编写的内容根本不相关。

但是，我们通常会将您正在做的事情称为＆＃34; Fluent Builder＆＃34; （或者Fluent Interface）代替。关于Fluent Builder的定义从来没有明确的定义，除了它提供了一个流畅的界面并帮助您创建一些东西。一个有趣的例子是，在Apache Commons Lang中，你会发现像EqualsBuilder，HashCodeBuilder和CompareToBuilder这样的东西，它们提供了流畅的界面，让你提供数据来得出最终的结果。鉴于对于＃34; Fluent Builder＆＃34;的含义没有明确的定义，我们无法评论它是否是＆＃34;反对＆＃34;模式。

Answer 2

它是否反对＆＃34;并不重要。建设者模式。

但对我而言，它使代码更短更清晰

重要的是什么。如果您为自己编写代码，那么它只是唯一重要的事情。如果您希望与他人合作，那么如果它也能让您的同行更清楚地了解代码，那将会有所帮助。

您的课程是一种可用于构建城市列表的工具。 CitiesListBuilder听起来就像一个好名字。如果它构建了一个名为CitiesList的类，那么它将更具建设性，但也许你不需要......

...爱好。

Answer 3

构建器模式的目的是为具有相同接口的多个构建器提供抽象，以便以相同的方式创建产品对象，即使它们的类型不同（产品对象可以实现相同的接口或具有共同的祖先）和参数。如果您只需要使用一种类型的构建器创建一种类型的对象，那么您只会过度复杂化。

Answer 4

这绝对不是规范建设者。您的类似乎使用字符串填充列表，过滤它们然后返回该列表。加上构建器应该总是使用'return this'，而不是。此外，您的构建器在开始时初始化，这也是不好的做法和令人困惑的

我的实现是针对构建器模式的吗？

4 个答案: