2010-06-29 20 views
10

我在想,如果一個類只會在另一個類中實例化,那麼就可以使用它嵌套在該類中。我認爲這會幫助我們設計出好的東西。當我看着我的項目時,我幾乎從未見過這樣的嵌套結構。但如果我嘗試嵌套類,所以這次我的腦海裏出現了另一個問題。例如何處以及如何使用嵌套類?

我有Board類,移動類如ShortCastle,LongCastle,EnPassant,Promote和Pieces,如典當,女王,騎士等。所以很顯然,Board類將實例化Piece類,並且Piece類將實例化Move類。對於一個好的設計,推動移動類應該是由Pawn嵌套,因爲只有棋子才能提升自己。短和長的城堡應該是King的嵌套,因爲只有King可以有這種類型的移動。

試圖把所有Piece類放到Board類中看起來不是很好的設計,因爲8-9類將會在Board類內部,它會真的討厭一個Board類文件太大而難以閱讀。我更喜歡每個在另一個文件中的單個類。好,我們可以創建部分董事會類但仍然不討厭8-9部分董事會類文件將舉行每一類課?不讓它們嵌套更好嗎?關於Pieces相同創建另一個部分Piece文件僅用於另一個Move類類?如果嵌套類只佔用很小的空間,所以它不會有任何問題,但如果它需要很多方法?

回答

11

我覺得你太慷慨,嵌套類。 查看this嵌套類型的設計指南。

如果下面不要使用嵌套類型爲真:

  • 類型必須由 客戶端代碼實例化。如果某個類型具有公共構造函數 ,則可能不應該嵌套 。 準則背後的基本原理是,如果嵌套類型 可以實例化,則表示 該類型在其自己的庫中有一個位置。您可以創建 它,使用它,並使用外部類型銷燬它,而不使用 。因此, 不應嵌套。內部類型 不應在外部類型的 之外廣泛重用,而不與外部類型具有 關係。
  • 該類型的引用通常在客戶端代碼中聲明爲 。

這些作品可能屬於董事會(作爲一個成員作爲集合?),但可以共存而不用它。你可能會f.e.希望重新使用沒有棋子的棋盤(主題等),並且還可以在沒有棋盤(位置等)的情況下重複使用棋子

2

父類的私人成員可以通過Nexted類的方法訪問。

Nexted類允許在沒有寬範圍的情況下降低複雜性。

0

如果您真的認爲嵌套類對您的設計有意義(請參閱Tim Schmelter的警告),但感覺文件大小太大,使用部分類很好,可以將嵌套類定義拆分爲自己的文件。或者,如果嵌套類自己足夠小,但您擁有大量嵌套類,則將所有嵌套類放入一個部分文件中。

父母。CS:

public partial class Parent 
{ 
    void SomeMethod() 
    { 
     Nested1 n1 = new Nested1(); 
     Nested2 n2 = new Nested2(); 
    } 
} 

Nested.cs:

public partial class Parent 
{ 
    private class Nested1 
    { 

    } 
    private class Nested2 
    { 

    } 
} 
1

對於一個好的設計,促進移動類應該是嵌套典當的,因爲只有典當行能促進自身。

我不完全同意。只因爲你可以巢類並不意味着你應該。問問你自己從嵌套這些類中獲得的好處。

+0

你用這個設計限制了錯誤的可能性。沒有其他的小塊不能創建這樣的動作,甚至是錯誤的。這種設計不會讓它。我錯了嗎? – Freshblood 2010-06-30 06:31:15

+0

深度嵌套類限制了它們的作用域(這在某些場景中可能是一個有用的架構約束),但是在項目早期就會遇到很多複雜性。我建議做「最簡單的工作」,然後在需要時重構爲更復雜的設計。然後,如果你想約束某些類可以從哪裏實例化,你可以將你的解決方案分解成不同的程序集(通過創建「類庫」項目)。 祝你好運! =) – 2010-07-06 17:03:23

0

嵌套類有它們的地方,但可能會混淆與工作。我發現了一個網頁,展示瞭如何使用一些.Net類來獲取Facebook的牆壁帖子的JSON輸出http://www.virtualsecrets.com/graph-api-json-facebook-handler.html這裏有趣的是,類嵌套在類的內部,在其他類的內部 - 所以它可以完成,只是一個有點複雜。 :)

+0

據我所知,這篇文章不是關於嵌套類,它只是嵌套對象。它完全不同。 – Freshblood 2012-06-20 12:30:24