在使用构建器模式时,我应该如何保留OOP的封装原则?我的意思是,构建器应该在对象和使用它的代码之间提供抽象层,这样它就可以被逐部分地构造,这需要为我们通常会传递到构造器中的对象的每个参数创建setter。这在某些情况下可能是不希望的,因为我不希望客户机能够修改值,我必须通过构建器。下面举例说明我的意思:
public class Cat
{
private string _race;
private string _name;
public Cat()
{
_race = "common";
_name = string.Empty;
}
public void setRace(string race) { _race = race; }
public void setName(string name) { _name = name; }
}
public class CatBuilder
{
private Cat _objectUnderConstruction;
public CatBuilder() { _objectUnderConstruction = new Cat(); }
public CatBuilder WithName(string name)
{
_objectUnderConstruction.setName(name);
return this;
}
public CatBuilder OfRace(string race)
{
_objectUnderConstruction.setRace(race);
return this;
}
}
这不是生产代码,我现在写它的时候考虑的是表示形式,所以不要对它的构造方式发火。
在上面的例子中,需要设置Cat's race,因为我们需要该信息来填充对象,所以我们需要传递给它。同时,我不希望任何人改变我的猫在它的一生中的种族(例如,它会改变从埃及到英国在中间处理),所以通常我会摆脱访问器方法,但我需要为构建器。这样,数据的封装就会受到损害(因为直接的get和set根本不能封装任何东西),我想避免它。
这个例子很简单,我可以在构造函数中传递html" target="_blank">参数,但是想象一下更大的类,那里有很多这样的字段,在这种情况下该怎么办?我应该在内部传递一些配置对象(这几乎像builder,但更简单,因此builder毫无意义)还是将builder本身传递给构造函数(这很奇怪,但我知道什么)?
我该怎么做?
如果构建器与类紧密耦合,则可以使
public class Cat
{
private string _race;
private string _name;
public Cat()
{
_race = "common";
_name = string.Empty;
}
private void setRace(string race) { _race = race; }
private void setName(string name) { _name = name; }
public class Builder
{
private Cat _objectUnderConstruction;
public CatBuilder() { _objectUnderConstruction = new Cat(); }
public CatBuilder WithName(string name)
{
_objectUnderConstruction.setName(name);
return this;
}
public CatBuilder OfRace(string race)
{
_objectUnderConstruction.setRace(race);
return this;
}
}
}
这样,您就可以在
我需要在没有静态嵌套类的情况下实现Builder模式。如果我有遗传,最好的方法是什么?让我们想象一下我有下面的课。 是创建一个Builder类来负责设置PassengerCar和Truck的值更好,还是我们需要另外三个类,CarBuilder,PassengerCarBuilder extends CarBuilder和TruckBuilder extends CarBuilder?
问题内容: 在我日常使用Java进行的工作中,我为流畅的接口使用了大量构建器,例如: 使用快捷方法Java,每个方法调用都会更改构建器实例并返回。一成不变的是,它涉及更多的类型输入,在修改之前先克隆构建器。构建方法最终会在构建器状态上进行繁重的工作。 在Scala中实现相同目标的一种好方法是什么? 如果我想,以确保被称为只有一次,随后只和可称为,一拉定向建设者,我怎么会去接近这个? 问题答案: S
由于无法解析最后一个链接调用,未定义方法,因此此调用将不会编译。所以这种方式要求所有调用都以特定的顺序链接起来,这是非常不切实际的,特别是对于一个深度层次结构树。 现在,在我寻找答案的过程中,我遇到了一个Java Builder类的子类,它建议使用奇怪的递归泛型模式。但是,由于我的层次结构不包含一个抽象类,所以这个解决方案对我不起作用。但是这种方法依赖于抽象和多态性来发挥作用,这就是为什么我不相信
本文向大家介绍设计模式构建器模式/Java 实现,包括了设计模式构建器模式/Java 实现的使用技巧和注意事项,需要的朋友参考一下 示例 通过Builder模式,您可以以易于阅读的方式创建具有许多可选变量的类的实例。 考虑以下代码: 如果所有参数都是必需的,那么一切都很好。如果有更多的变量和/或其中一些是可选的怎么办?您不想使用必需参数和可选参数的每种可能的组合来创建大量的构造函数,因为它变得难以
问题内容: 到目前为止,我使用了构建器模式的以下实现(与此处描述的实现相反): 这在我遇到的大多数情况下都很有效,在这种情况下,我需要使用各种必需/必需和可选参数来构建一个复杂的对象。但是,最近我一直在努力了解当所有参数都是必需的(或者至少绝大多数是强制性的)时,模式有什么好处。 解决此问题的一种方法是在逻辑上将传递给它们自己的类的参数分组,以减少传递给构建器构造函数的参数数量。 例如,代替: 分
问题内容: 我使用ektorp连接到CouchDB。 构建ektorp 实例的方法是使用构建器模式: 我对Spring比较陌生。请为我提供有关如何在上下文中配置以便通过进行创建的建议。 一种方法是使用。还有其他选择吗? 问题答案: 您可以尝试实现接口: 并添加到配置以下bean定义: 然后,您可以将此bean注入另一个bean,它将作为实例进行解析。
最近,我看到一些开发人员使用嵌套的生成器类来编写VO,如 现在,他们声称这使代码更具可读性。我的观点是,这有以下缺点: > 我不能简单地添加字段并期望我的IDE为我完成代码,因为现在我也需要更新这个内部类。 简单的POJOs携带与VO无关的代码。 如果我在这里遗漏了什么,我会寻求任何建议。请随意添加您的想法。 修改后的示例代码如下所示: