使用分部類而不是抽象類有什麼好處？

我一直在閱讀ProgrammingMicrosoft®Visual C＃®2008：The Language來更好地理解C＃以及可以做些什麼。我遇到了從ASP.Net的Page類已經遇到的部分類。使用分部類而不是抽象類有什麼好處？

對我來說，你似乎可以做一些抽象類和重寫類的部分類。很顯然，一個團隊將通過抽象方法來控制界面，但無論如何你都會依賴對方。如果目標是協作，那麼不是什麼源代碼控制和其他工具可以解決的問題。

我只是缺少一個部分類的觀點。也有人可以提供真實世界的使用。

來源

2009-06-29 uriDium

部分類與對象繼承無關。部分類只是將定義類的源代碼拆分爲單獨文件的一種方式（例如，當您在Windows窗體應用程序中創建新窗體時會執行此操作 - 一個文件是「您的」代碼，另一個文件是.designer.cs包含VS2008爲您管理的代碼）。

來源

2009-06-29 11:40:34

我知道它有沒有關係繼承，但你可以做同樣的事情，因爲它是一種繼承，你可以拆分代碼成單獨文件的副作用。可能不如部分課程提供的那樣好或乾淨。我只是想爲他們找到一個用處。 – uriDium 2009-06-29 11:45:39

哎呀，對不起。我在鍵盤上太快了。所以最終設計師的代碼和你的代碼將最終在同一個文件中？現在我看到了使用，如果是這樣的話。但是，除非我試圖做類似的事情，否則我可能永遠不會使用它。 – uriDium 2009-06-29 11:47:00

他們做了與繼承完全不同的事情。一個使用的例子是Visual Studio。表單構建器使用設置控件的代碼生成部分類文件。用戶代碼位於單獨的文件中。編譯時，這些文件合併成一個類。部分類的真正殺手級應用程序是生成部分但不是完全由生成的代碼組成的類。你可以做一些類似的（例如）一個O/R映射器。 – ConcernedOfTunbridgeWells 2009-06-29 11:48:43

一個很好的使用示例是當產生部分類的一側（例如一個ORM）部分類的

來源

2009-06-29 11:40:44

目的是讓一個類的定義，以在多個文件跨越。這可以實現更好的可維護性和代碼分離。

來源

2009-06-29 11:41:48

我們使用部分類來分割我們的大類。這樣，通過Sourcesafe查看一部分代碼就變得更加容易了。這限制了四個開發人員需要訪問同一文件的情況。

來源

2009-06-29 11:44:51 Carra

關於部分類的好處是您可以使用現有的類並添加它。現在這聽起來很像繼承，但有很多東西是繼承不能做的，部分類將會。

下面是關於爲您生成的Linq to SQL類的一些想法。它們是自動生成的，意味着你不應該修改它們。如果沒有部分類，則無法附加接口。你可以創建一個新類並從Linq to sql類派生出來，但是這實際上並沒有給你帶來什麼，因爲你不能用接口將linq轉換爲sql類。

來源

2009-06-29 11:46:06 kemiller2002

部分類現在在ASP.Net中被大量使用，允許兩個源文件基於標記的example.aspx和基於代碼的example.aspx.cs，以使每個中定義的方法和變量都可見。在example.aspx

<custom:exampleControl id="exampleCntr" property="<%#getProperty()%>" />

在example.aspx.cs

private object GetProperty(){ // called from aspx 
    return DateTime.Now; 
} 

private void DoStuff(){ 
    ExampleControl c = exampleCntr; //exampleCntr is defined in aspx. 
}

這樣做的雙向性質不能與抽象類中重新創建。

來源

2009-06-29 12:39:36

部分類應限制爲使用自動生成的代碼，其中其他代碼不可修改。使用它作爲繼承或添加功能的替代品並不是最佳實踐。

如果你有一個大班，它已經錯了。代碼應該被重構爲多個「真實」類而不是多個文件。一般而言，大班表示課堂做得太多，違反了SRP（單一責任原則）。

來源

2011-04-07 16:03:06 vasya10

這聽起來像你的問題是有什麼區別

partial class Foo 
{ 
    PART ONE 
} 
partial class Foo 
{ 
    PART TWO 
}

和

astract class FooBase 
{ 
    PART ONE 
} 
partial class Foo : FooBase 
{ 
    PART TWO 
}

之間雖然他們可能看起來有些相似，並在某些情況下，後者的結構可以代替使用前者，至少有兩個問題與後者的風格：

-1-類型FooBase很可能必須知道的身份應該從中派生出的具體類型，並且始終使用該類型的變量，而不是FooBase類型的變量。這代表了這兩種類型之間令人不舒服的緊密聯繫。

-2-如果類型Foo是公開的，則類型FooBase也必須公開。即使FooBase所有構造都internal，這將是可能的外碼來定義從FooBase派生類但不Foo;構建這樣的類的實例將是困難的，但並非不可能。

如果有可能的派生型，以擴大基本類型的可見性，這些問題不會過於有問題;在其聲明一次，一次在報關行的Foo，圖，每一個FooBase是一種變相的Foo：一個會認爲FooBase因爲這將恰好出現兩次「暴殄天物」標識。這FooBase不能使用在thisFoo實例成員沒有強制類型轉換，這一事實可能是令人側目，但也可能鼓勵代碼的好分區。但是，由於無法擴展基本類型的可見性，因此抽象類設計似乎很棘手。

來源

2013-06-16 20:59:39 supercat

使用分部類而不是抽象類有什麼好處？

回答

相關問題