“被动”对象是否被认为是一种良好的设计实践？

我发现自己经常创建一个没有公共方法且自成体系的对象。它通常处理在其私有方法中传递给其构造函数的参数事件，并且不会引发任何事件或公开任何方法。“被动”对象是否被认为是一种良好的设计实践？

我打电话这种类型的对象“被动”的对象 - 没有定义的任何公共方法的对象。在构造函数中传递的参数的私有方法和事件中，所有交互发生在它们内部。

通常，它是一些工具类，像一个确保两种形式将被粘在一起：

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 
    } 
}

这样的“被动”物体是否被认为是良好的设计实践？

是否有这种类的一个更好的名字？

来源

2009-11-13 Marek

似乎对我来说很好的设计。我不确定这个名字是否被动。这些课程确实非常活跃。他们对事件做出反应并做些事情。我认为如果你需要调用其中的方法来实现它，那么类会更加被动，但通常情况下，除非被戳穿，否则它将不会执行任何操作。

“控制器”名称如何？ “控制器”是UI中使用的类中更常用的名称，它导致视图和数据之间的交互，并且它们通常不需要公共方法。

我确定还有其他的名字。

来源

2009-11-13 09:54:16

我看不出有什么问题。如果它产生干净可读的代码，那就去吧！

来源

2009-11-13 09:39:29 Thomas

我不认为这是对通知做出反应的对象和更新自己的状态完全是被动的。其他

一个想法，如果对象简单地调整自己的状态，以反映外部世界的变化，而不提供很多自己的，你可以切片他们的“功能”，并把它放到其他更积极的“组件”。这些对象可能没有足够的理由存在。

如果该组织不过是你的代码结构更好，更清晰，更易于维护，然后用它，不要担心。

来源

2009-11-13 09:40:11

从概念上讲，这似乎是战略模式的实施。虽然在这种特殊情况下，推理与战略模式不同，但它仍然会产生非常可读且很好的粒度代码。去吧。

UPDATE：要更清楚一点我是什么意思考虑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 
}

衍生的两个（或更多）类和你决定要动态地使用哪一个取决于运行时的状态......你实现一个策略。正如我所说的，您的解决方案在概念上与策略相似：您可以选择应用程序的某些行为方面，将其很好地抽象为策略，并将策略的实施移至单独的类中，但不知道其他应用程序，以及你的应用程序对这项政策的胆量并不了解。即使你不多次使用它，与策略的相似之处也很明显。

来源

2009-11-13 19:24:12 BostonLogan

对不起，但我没有看到这种方法的战略模式的任何迹象。你能详细说明一下吗？ – Marek 2009-11-16 07:04:57

Marek @：请参阅我的原始文章更新 – BostonLogan 2009-11-16 13:05:04

这绝对不是一种策略 - 1.只有一种形式的粘性是可能的2.算法在运行时不会被切换。鉴于你的方法，我们可以调用你可以（可能）子类的一切策略:) – Marek 2009-12-01 08:57:30

我认为有一个重要标准可以满足这个设计：你可以测试它吗？你的设计似乎是可测试的，但你可能必须小心，因为我可以看到这导致了一些相当不可测试的代码。

关于名称，我认为这可能是Mediator pattern的一个例子。

来源

2009-11-16 13:13:10

“被动”对象是否被认为是一种良好的设计实践？

回答

相关问题