Каковы преимущества использования частичного класса в отличие от абстрактного?


Я читал Программирование Microsoft ® Visual C# ® 2008: язык, чтобы лучше понять C# и что с ним можно сделать. Я столкнулся с частичными классами, которые я уже встречал от ASP.Net-класс странички.

Мне кажется, что вы можете делать то, что частичные классы делают с абстрактным классом и переопределенным классом. Очевидно, что одна команда будет контролировать интерфейс с помощью абстрактных методов, но вы все равно будете полагаться друг на друга. А если цель есть тогда сотрудничество-это не то, что решает система управления версиями и другие инструменты.

Я просто упускаю из виду частичный класс. Также мог бы кто-то обеспечить реальное использование мира.

8 7

8 ответов:

Частичные классы не имеют ничего общего с наследованием объектов. Разделяемые классы-это просто способ разбиения исходного кода, определяющего класс, на отдельные файлы (это делается, например, при создании новой формы в приложении Windows Forms - один файл является "вашим" кодом, другой-другим файлом).дизайнер.cs содержит код, которым управляет VS2008 для вас).

Хороший пример использования-это когда генерируется одна сторона частичного класса (например, ORM)

Самое замечательное в частичном классе то, что вы можете взять существующий класс и добавить к нему. Теперь это звучит очень похоже на наследование,но есть много вещей, которые наследование не может сделать, что частичные классы будут.

Вот одна мысль о классах Linq to SQL, созданных для вас. Они генерируются автоматически, что означает, что вы не должны изменять их. Без разделяемого класса вы не можете присоединить интерфейс. Можно создать новый класс и вывести его из класса Linq to sql, но это действительно ничего вам не даст, потому что вы не можете передать класс linq to sql в свой класс с интерфейсом.

Частичные классы должны быть ограничены использованием С автоматически генерируемым кодом, где другой код не может быть изменен. Использование его в качестве замены наследования или добавления функциональности не является лучшим решением.

Если у вас большой класс, это уже неправильно. Код должен быть преобразован в несколько "реальных" классов вместо нескольких файлов. Большие классы вообще означают, что класс делает слишком много вещей и нарушает SRP (принцип единой ответственности).

Парциальные классы теперь широко используются в ASP.Net разрешить два исходных файла пример на основе разметки.aspx и пример на основе кода.аспн.cs так, чтобы методы и переменные, определенные в каждом, были видны каждому. в примере.aspx

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

В Примере.аспн.cs

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

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

Двунаправленная природа этого не может быть воссоздана с помощью абстрактных классов.

Похоже, что ваш вопрос заключается в том, в чем разница между

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; построение экземпляров таких классов было бы трудным, но не невозможным.

Если бы производный тип мог расширить видимость базового типа, эти проблемы не были бы чрезмерными. проблематично; можно было бы рассматривать FooBase как "выброшенный" идентификатор, который появлялся бы ровно дважды: один раз в его объявлении и один раз в строке объявления для Foo, и считать, что каждый FooBase был бы Foo замаскированным. Тот факт, что FooBase не может использовать члены экземпляра Foo на this без преобразования типа, может быть утомительным, но также может способствовать хорошему разбиению кода. Поскольку расширить видимость базового типа невозможно, дизайн абстрактного класса выглядит следующим образом: мерзкий.

Назначение разделяемых классов состоит в том, чтобы позволить определению класса охватывать несколько файлов. Это позволит улучшить ремонтопригодность и разделение кода.

Мы используем частичные классы для разделения наших больших классов. Таким образом, проще проверить часть кода с помощью Sourcesafe. Это ограничивает случаи, когда четыре разработчика должны получить доступ к одному и тому же файлу.