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

8

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

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

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

Ваш Ответ

8   ответов
4

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

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

1

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 без Typecast может быть утомительно, но также может способствовать хорошему разделению кода. Однако, поскольку невозможно расширить видимость базового типа, дизайн абстрактного класса кажется странным.

1

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

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

в примере .aspx.cs

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

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

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

0

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

Я считаю это полезным при создании пользовательских элементов управления. Тогда у вас часто есть много методов и свойств, которые можно переопределить в одном классе, поэтому мы разбиваем его на логические группы (например, «control.Input.cs», «control.Draw.cs», «control.Properties», quot ;, так далее.).
Хотя я знаю о частичных классах, я фактически никогда не использовал их сам (кроме автоматически сгенерированных). Существуют ли внутригрупповые правила относительно того, какой метод входит в какой файл? Есть ли соглашение об именах? Я всегда был немного обеспокоен увеличением времени «найти определенную часть кода» при широком использовании частичных классов.
0

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

4

ого класса (например, ORM).

ИМО это один из плохих способов использования частичных классов. Если сгенерированный класс был абстрактным, вы могли бы переопределить поведение, проверку правильности для сеттеров и т. Д. С внутренними классами вы застряли в методах / свойствах, которые генерирует генерируемая сторона.
ИМО, это единственное хорошее использование частичных классов. Необходимость разделить один класс на несколько файлов - это запах.
19

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

Ой, извините. Я был слишком быстр на клавиатуре. Итак, в конечном итоге код разработчика и ваш код окажутся в одном файле? Теперь я вижу смысл, если это так. Но тогда я, вероятно, никогда не буду использовать это, если я не пытаюсь сделать что-то подобное. uriDium
Я знаю, что это не имеет ничего общего с наследованием, НО вы можете делать то же самое, потому что это своего рода побочный эффект наследования, когда вы можете разделить код на отдельные файлы. Вероятно, не так красиво или чисто, как предлагает частичный класс. Я просто пытаюсь найти им применение. uriDium
Они делают что-то совершенно другое для наследования. Примером использования является Visual Studio. Построитель форм генерирует частичный файл класса с кодом, который устанавливает элементы управления. Пользовательский код находится в отдельном файле. При компиляции эти файлы объединяются в один класс. Поистине убийственным приложением классов Partial является создание классов, которые состоят частично, но не полностью из сгенерированного кода. Вы можете сделать что-то подобное с (например) O / R Mapper.
Да, компилятор видит эти отдельные файлы как одно определение класса (я думаю, вы могли бы представить, что он объединяет их в один файл в памяти перед компиляцией). Абстрактный класс, тем не менее, похож на «шаблон». для других классов его определение завершено, а реализация - нет. Однако абстрактный класс также может быть реализован как частичный класс, если вы хотите распределить определение класса по нескольким файлам.
2

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

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

Похожие вопросы