「被動」對象是否被認爲是一種良好的設計實踐？

我發現自己經常創建一個沒有公共方法且自成體系的對象。它通常處理在其私有方法中傳遞給其構造函數的參數事件，並且不會引發任何事件或公開任何方法。「被動」對象是否被認爲是一種良好的設計實踐？

我打電話這種類型的對象「被動」的對象 - 沒有定義的任何公共方法的對象。在構造函數中傳遞的參數的私有方法和事件中，所有交互發生在它們內部。

通常，它是一些工具類，像一個確保兩種形式將被粘在一起：

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

「被動」對象是否被認爲是一種良好的設計實踐？

回答

相關問題