以下是我对构建器设计模式的理解。假设我们有一个Product类,如下所示。
public class Product
{
public string Name { get; set; }
public string Description { get; set; }
public int NumberOfProducts { get; set; }
public decimal Price { get; set; }
public bool IsDurable { get; set; }
}
构建器界面:
public interface IBuilder
{
void SetName(string value);
void SetPrice(decimal value);
void SetIsDurable(bool value);
void SetNumberOfProducts(int value);
void SetDescription(string value);
Product GetProduct();
}
具有setter方法并获取产品对象的具体生成器。
public class ConcreteBuilder : IBuilder
{
Product product = new Product();
public Product GetProduct()
{
return product;
}
public void SetDescription(string value)
{
product.Description = value;
}
public void SetIsDurable(bool value)
{
product.IsDurable = value;
}
public void SetName(string value)
{
product.Name = value;
}
public void SetNumberOfProducts(int value)
{
product.NumberOfProducts = value;
}
public void SetPrice(decimal value)
{
product.Price = value;
}
}
在实际情况下,应从用户输入中填充产品的属性,而不要像这样进行硬编码。在这种情况下,我们还需要发送产品以构造产品对象。
public Product ConstructProduct(IBuilder builder)
{
builder.SetDescription("P");
builder.SetIsDurable(false);
builder.SetName("My Name");
builder.SetPrice(10);
builder.SetNumberOfProducts(5);
return builder.GetProduct();
}
如下所示在客户端中使用构建器对象:
public class Client
{
public void AddProduct()
{
ConcreteBuilder builder = new ConcreteBuilder();
var builtProduct = new Director().ConstructProduct(builder);
Console.WriteLine(builtProduct.Description);
}
}
当在构造函数中要添加许多属性(以避免伸缩构造反模式)时,为什么不使用产品模型类本身,而不是像上面那样使用生成器模型?如果有任何可选属性,可以将它们设置为可为空。
public class Client
{
Product _prod;
public Client(Product prod)
{
_prod = prod;
}
public void AddProduct()
{
// Code to add product
Console.WriteLine(_prod.Description);
}
}
答案 0 :(得分:0)
创建类时,主要目的是降低程序的复杂性。您创建了一个隐藏复杂性的类,因此您无需考虑它。当然,您在上课时需要考虑一下。但是,编写完该课程后,您应该可以忘记细节,并在不了解其内部工作原理的情况下使用该类。
很明显,在您提到的问题中,使用构建器模式会增加复杂性,仅使用模型是正确的选择。因为创建Product
对象的过程非常简单。
在其他情况下,创建对象可能是一个复杂的操作,您可以使用构建器设计模式来管理这种复杂性。
以下是构建器模式在现实世界中的用法示例:https://dzone.com/articles/builder-pattern-usage-real