请原谅我对设计模式的知识匮乏。
有时候,方法会有很多参数,引入一个“参数对象”是根据重构大师文章重构代码的正确方式。
想象一下这样一种情况:我们有一个处理某种类型文档的服务。
该文档由许多部分组成,其中一些是可选的。有时我们需要文档包含所有可能的细节。
但是,想象一种情况,某个组织不想要某些细节。
理想情况下,我希望有一个处理选项创建并包含组织名称方法的类。
有时候,方法会有很多参数,引入一个“参数对象”是根据重构大师文章重构代码的正确方式。
想象一下这样一种情况:我们有一个处理某种类型文档的服务。
public class FinancialStatementService : IFinancialStatementService
{
public Document Create(Options input)
{
// creating basic document content and adding optional data below:
if (input.HasAccountNo)
{
// include account number
}
if (input.HasPaymentDetails)
{
// include payment details
}
if (input.HasZeroBalances)
{
// include zero balances
}
if (input.HasTotal)
{
// include total
}
// and then return the document
}
}
public class Options
{
public DateRange DateRange { get; set; }
public bool HasAccountNo { get; set; }
public bool HasPaymentDetails { get; set; }
public bool HasZeroBalances { get; set; }
public bool HasTotal { get; set; }
}
该文档由许多部分组成,其中一些是可选的。有时我们需要文档包含所有可能的细节。
但是,想象一种情况,某个组织不想要某些细节。
理想情况下,我希望有一个处理选项创建并包含组织名称方法的类。
public class OptionsCreator
{
// tax officials want to see all possible details
public static Options GetTaxOfficeOptions(DateRange dateRange)
{
return new Options() { HasAccountNo = true, HasPaymentDetails = true, HasZeroBalances = true, HasTotal = true, DateRange = dateRange };
}
// in some other organization they DO NOT NEED zero balances & payment details
public static Options GetSomeOtherOgranizationOptions(DateRange dateRange)
{
return new Options() { HasAccountNo = true, HasTotal = true, DateRange = dateRange };
}
}
但我担心上面的例子是一种反模式。
我能想到的另一件事是建造者模式。
建造者模式是否是参数对象的最佳解决方案?