我发现自己经常创建一个没有公共方法并且是自包含的对象。它通常处理在其私有方法中传递给其构造函数的参数事件,并且不会引发任何事件或公开任何公共方法。
我将此类对象称为“被动”对象 - 未定义任何公共方法的对象。所有交互都发生在私有方法和构造函数中传递的参数事件中。
通常它是一些实用程序类,就像确保两个表单将粘在一起的那样:
public class StickyForm : IDisposable
{
private readonly Form form;
private readonly Form parentForm;
public StickyForm(Form form, Form parentForm)
{
this.form = form;
this.form.StartPosition = FormStartPosition.Manual;
this.parentForm = parentForm;
this.parentForm.LocationChanged += new EventHandler(parent_LocationChanged);
this.parentForm.SizeChanged += new EventHandler(parent_SizeChanged);
SetLocation();
}
void parent_SizeChanged(object sender, EventArgs e)
{
SetLocation();
}
void parent_LocationChanged(object sender, EventArgs e)
{
SetLocation();
}
private void SetLocation()
{
//compute location of form based on parent form
}
public void Dispose()
{
this.parentForm.SizeChanged -= parent_SizeChanged;
this.parentForm.LocationChanged -= parent_LocationChanged;
}
}
但有时它也是某种控制器,提供两种视图之间的交互:
public class BrowseController
{
private IBrowserView view;
private IFolderBrowser folderBrowser;
public BrowseController(IFolderBrowser folderBrowser, IBrowserView view)
{
this.view = view;
this.folderBrowser = folderBrowser;
this.folderBrowser.NodeOpened += folderBrowser_NodeOpened;
}
private void folderBrowser_NodeOpened(object sender, Core.Util.TEventArgs<IPictureList> e)
{
this.Browse(e.Value);
}
public void Browse(IPictureList content)
{
//stripped some code
AddItemsToView(content);
}
private void AddItemsToView(IPictureList browser)
{
//call methods on view
}
}
这些“被动”物体是否被认为是一种很好的设计实践?
这类课程有更好的名字吗?
答案 0 :(得分:2)
对我来说似乎很精致。我不确定这个名字是被动的。那些课看起来非常活跃。他们对事件作出反应并做事。我认为如果你必须在它上面调用方法让它做东西,那么一个类就更被动了,但除非戳了戳,否则它通常不会做任何事情。
名称“控制器”怎么样? “控制器”是用于UI的类的更常用的名称,它引起视图和数据之间的交互,并且它们通常不需要公共方法。
我确信还有其他名字的想法。
答案 1 :(得分:1)
我没有看到任何错误。如果它产生干净,可读的代码,那就去吧!
答案 2 :(得分:1)
我不会调用对通知作出反应的对象并将其状态完全更为被动。
另一个想法是,如果对象只是调整其状态以反映外部世界的变化而不提供自己的更多,则可以将其“功能”切片并将其放入其他更活跃的“组件”中。这些对象可能没有足够的理由存在。
如果这个组织让你的代码结构更好,更清晰,更易于维护,那么就使用它,不要担心它。
答案 3 :(得分:1)
我认为有一个重要的标准可以满足这种设计:你能测试一下吗?您的设计似乎是可测试的,但您可能必须小心,因为我可以看到这导致一些相当不可测试的代码。
关于名称,我认为这可能是Mediator pattern的一个例子。
答案 4 :(得分:0)
从概念上讲,这似乎是战略模式的实施。虽然在这种特殊情况下,推理与策略模式不同,但它仍然会产生非常易读且质量很好的代码。去吧。
更新:更清楚地说明我的意思是考虑从StickyForm
派生的两个(或更多)类
public class VeryStickyForm : StickyForm
{
//some implementation here
//but interface is completely inherited from StickyForm
}
public class SomewhatStickyForm : StickyForm
{
//some implementation here
//but interface is completely inherited from StickyForm
}
您决定根据运行时状态动态使用哪一个......您实施策略。 正如我所说,您的解决方案在概念上类似于策略:您选择应用程序的一些行为方面,可以很好地抽象为策略,并将策略的实现移动到单独的类中,不知道应用程序的其余部分,以及应用程序不太了解政策的内容。即使你没有多态地使用它,与策略的相似之处也很明确。