Jakie są zalety korzystania z klasy częściowej w przeciwieństwie do abstrakcyjnej?

Question

Czytałem programowanie Microsoft® Visual C# ® 2008: język, aby lepiej zrozumieć C# i co można z nim zrobić. Natknąłem się na częściowe klasy, które już spotkałem z klasy strony ASP.Net.

Wydaje mi się, że możesz zrobić zajęcia częściowe z klasą abstrakcyjną i nadpisaną. Oczywiście jeden zespół będzie kontrolował interfejs za pomocą abstrakcyjnych metod, ale i tak będziecie polegać na sobie nawzajem. A jeśli celem jest współpraca, to nie to, co rozwiązuje kontrola źródła i inne narzędzia.

Po prostu brakuje mi częściowej klasy. Również ktoś może zapewnić rzeczywiste użytkowanie tego świata.

Answer 1

Częściowe klasy nie mają nic wspólnego z dziedziczeniem obiektów. Częściowe klasy są tylko sposobem podziału kodu źródłowego, który definiuje klasę na oddzielne pliki (jest to na przykład robione podczas tworzenia nowego formularza w aplikacji Windows Forms - jeden plik to "twój" kod, inny plik .designer.cs zawiera kod, który VS2008 zarządza dla ciebie).

Answer 2

Dobrym przykładem jest wykorzystanie kiedy jedna strona jest generowana częściowej klasy (takich jak ORM)

Answer 3

celu częściowego zajęć jest umożliwienie definicja klasę, by rozciągać na wielu plikach. Może to pozwolić na lepszą łatwość konserwacji i separację kodu.

Answer 4

Używamy klas częściowych do podziału naszych większych klas. W ten sposób łatwiej jest sprawdzić część kodu za pomocą Sourcesafe. Ogranicza to przypadki, w których czterech programistów musi uzyskać dostęp do tego samego pliku.

Answer 5

Wielką zaletą częściowej klasy jest to, że można wziąć istniejącą klasę i dodać do niej. Teraz brzmi to bardzo podobnie do dziedziczenia, ale jest wiele rzeczy, których dziedziczenie nie może zrobić, że klasy częściowe będą.

Oto jedna myśl o wygenerowanych klasach Linq do SQL. Są autogenerowane, co oznacza, że ​​nie powinieneś ich modyfikować. Bez częściowej klasy nie można dołączyć interfejsu. Można utworzyć nową klasę i wyprowadzić ją z klasy Linq do sql, ale to naprawdę nic nie da, ponieważ nie można upcast z linq do klasy sql do klasy za pomocą interfejsu.

Answer 6

Częściowe klasy są obecnie często używane w ASP.Net, aby umożliwić dwóm źródłowym plikom przykładowy plik .aspx oparty na oznaczeniach i oparty na kodzie przykład.aspx.cs, dzięki czemu metody i zmienne zdefiniowane w każdym z nich są widoczne dla każdego. w example.aspx

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

w example.aspx.cs

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

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

Dwukierunkowy charakter nie mogą zostać odtworzone z klas abstrakcyjnych.

Answer 7

Klasy częściowe powinny być ograniczone do używania z kodem generowanym automatycznie, gdzie drugiego kodu nie można zmienić. Używanie go jako substytutu dziedziczenia lub dodawania funkcjonalności nie jest najlepszą praktyką.

Jeśli masz dużą klasę, jest ona już błędna. Kod powinien być refaktoryzowany na wiele "prawdziwych" klas zamiast wielu plików. Ogółem duże klasy oznaczają, że klasa robi zbyt wiele rzeczy i narusza SRP (Zasada Odpowiedzialności Pojedynczej).

Answer 8

Brzmi jak Twoje pytanie jest jaka jest różnica między

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

i

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

Chociaż mogą one pojawić się nieco podobne, aw niektórych przypadkach ta ostatnia konstrukcja może być stosowany w miejsce pierwszy, są co najmniej dwa problemy z tym drugim stylem:

-1- Typ FooBase prawdopodobnie musiałby znać tożsamość konkretny typ, który miał z niego wywodzić, i zawsze używaj zmiennych tego typu, a nie typu FooBase. Stanowi to nieprzyjemnie ścisłe powiązanie między tymi dwoma typami.

-2- Jeśli typ Foo jest publiczny, wpisz FooBase również musi być publiczny. Nawet jeśli wszyscy konstruktorzy FooBase są internal, możliwe byłoby, że zewnętrzny kod definiuje klasy, które pochodzą od FooBase, ale nie Foo; konstruowanie przypadków takich klas byłoby trudne, ale nie niemożliwe.

Jeśli możliwe było rozszerzenie typu widocznego typu bazowego, problemy te nie byłyby zbyt problematyczne; można by uznać FooBase jako identyfikator "wyrzucania", który pojawiłby się dokładnie dwa razy: raz w swojej deklaracji i jeden raz w wierszu deklaracji dla Foo, a także, że każdy znak FooBase będzie w przebraniu Foo. Fakt, że FooBase nie może korzystać z członków instancji Foo pod numerem this bez typowania, może być irytujący, ale może również zachęcać do dobrego podziału kodu. Ponieważ nie jest możliwe rozszerzenie widoczności typu podstawowego, jednak abstrakcyjna klasa wydaje się kłująca.