我正在开发一个简单的票务管理系统。创建故障单时,我必须按顺序执行4-5操作。以下是我的代码
pubic ActionResult CreateTicket(Ticket ticket)
{
TicketRepository ts = new TicketRepository();
if(ts.CreateTicket(ticket))
{
INotification emailNotification = new Email();
emailNotification.SendTicketAlert();
IResponsible assignToUser = new AssignToUser();
assignToUser.assign();
DummyObj obj = new DummyObj();
obj.someDummyOperation();
}
}
你认为这是建筑师模式的情况吗?
答案 0 :(得分:0)
不是真的,因为构建器模式的一个要点是消除了实例化时具有许多配置选项的类所带来的尴尬:
class MyClass {
public MyClass(Object option1, Object option2, Object option3, ...Object option15){...};
}
这在构造实例时会立即导致尴尬:
MyClass myClass = new MyClass(o, null, null, o1, null, null, o2...);
反模式解决方案是创建许多构造函数来处理客户端所需的最可能的配置选项:
class MyClass {
public MyClass(Object option1){...};
public MyClass(Object option2, Object3){...};
public MyClass(Object option1, Object option2, Object option3){...};
.
.
.
}
如果你要实现构建器模式,你可以这样做:
var myClass = CreateMyClass().option1().option15().build();
最后一次调用返回一个类的实例。这是一个相当数量的阶段机制来构建,但在其他代码消耗的代码中可能是值得的。
除此之外,这种模式在具有命名参数的语言中不太需要,您可以在其中执行
之类的操作new MyClass(option15=o);
答案 1 :(得分:0)
Builder被归类为creational pattern。由于您没有创建复杂对象,因此不能将您的代码视为使用Builder。
如果你真的想使用一个模式,你应该看看Chain of responsibility模式,这似乎更适合你想要做的事情。